61–70 of 134 posts
Earlier quoted context omitted.
Because frequently the devil is in the details.
But only some of the details. I still need to ignore most of the details even while I need control of the ones that matter. This is easier said than done.
Earlier quoted context omitted.
Sounds like you’re going to be depressed when you learn how the entire Internet plane, all software engineering outside of “SV”, all IT, all government, and basically everything except your GitHub CI/CD adventure works, then. Sorry.
This isn't an accurate statement. I work on behalf of a federal government agency, and no one has write access in development, let alone production. Everything is required to run thru our ci/cd pipeline. Times are changing.
I ask because I think there’s something better. I don’t know what it is yet, but I want to find out. I’m worried about wastage in DevOps methodologies, a system where nobody is incentivized to care about the right things, going on to spook the policymakers on doing software before we find out if the DevOps and Cloud worlds, both, are objectively the best way to do software for their purposes. I strongly, strongly feel like the craft is on the wrong path, and persuasive successes in industry are getting to the right ears before we know if the discipline to efficiently handle agile infrastructure with today’s tooling is even possible. I’m not convinced DevOps will organically find the right calculus to spur the kind of systems research that took us to not only where we are, but that which will take us where we need to go.
Speaking of, I’m lazily glancing at Agile here as well but I’m not prepared for a coherent argument there, beyond pointing out that we now have better tooling for managing specifications, particularly formal and mathematical ones, than the waterfall development experiences that prompted agile thinking. We need more systems research, tinkering, rethinking POSIX, all of it.
Earlier quoted context omitted.
Call them SREs and cross-train SWEs into it. It’s not a toothless distinction even though it seems like one. You absolutely, positively will hire better staff with better deliverables if you frame the work as “a software engineer focused on operational integration,” which SRE understands more. SREs like to build platforms for exactly the same reasons you’re touching. You sound like you’re halfway there already. I str…
In my understanding SRE is more related to "keep the lights on and systems running", it might be just a different understanding of the nomenclature. E.g: In my current case the software teams own their ops, my team doesn't ops for them. We give them a platform of centralized logging, monitoring and etc. so that they can easily ops their services but is not my phone that rings and I am not on call. I am on call if som…
SREs at Google own production in a very deep sense. They are decision makers on things like when teams can deploy, how frequently, what dependencies they can use, and possibly most significantly, who gets SRE support and who has to handle their own on call rotation. They also build monitoring and reliability services and tools.
Google also employs traditional Ops people, but not as many as you might suspect. When SREs look at traditional Ops work, they see a threat to reliability and a target for automation. The mantra is that the "E" isn't for show, and that SREs are software engineers who specialize on the topic of running highly reliable services. One of the things the SRE book stresses is making sure that SRE teams aren't so bogged down in oncall responsibilities that they don't have time to work on automating their oncall responsibilities.
Earlier quoted context omitted.
In my understanding SRE is more related to "keep the lights on and systems running", it might be just a different understanding of the nomenclature. E.g: In my current case the software teams own their ops, my team doesn't ops for them. We give them a platform of centralized logging, monitoring and etc. so that they can easily ops their services but is not my phone that rings and I am not on call. I am on call if som…
> In my understanding SRE is more related to "keep the lights on and systems running", it might be just a different understanding of the nomenclature. SREs at Google own production in a very deep sense. They are decision makers on things like when teams can deploy, how frequently, what dependencies they can use, and possibly most significantly, who gets SRE support and who has to handle their own on call rotation. Th…
Might be my own bias towards the SRE word.
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…
People love to bring this up, but if Linux did have first-class containers, how would the developer's experience be different?
For instance, you could run your package manager across all containers to see if they have packages with known CVEs. Or manage the filesystems of all containers on the system (the usefulness of this is only clear with filesystems like ZFS and btrfs). This is effectively what you can do with Solaris Zones.
These kinds of improvements to usability aren't as sexy now that everyone is really excited about Kubernetes (where you blow away containers at whim) but it is useful for the more traditional container usecases that Zones and Jails. LXC (and LXD) is probably the one Linux container runtime that is closest to that original container model.
There's also a very big security argument -- it is (speaking as a maintainer of runc) very hard to construct a secure container on Linux. There are dozens of different facilities you need to individually configure in the right order, with hundreds of individual knobs that some users might want to disable or quirks you need to work around. It's basically impossible to implement a sane and secure container runtime without having read and understood the kernel code which implements the interfaces you're using. If containers were an in-kernel primitive then all of the security design would rest in one single codebase, and all of the policies would be defined by one entity (the kernel).
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…
> A sizable fraction will be concerned about 'container overhead' (and "scalability issues") when asked to move workloads to containers. They are usually not able to explain what the overhead would be, and what could potentially be causing it. For what it's worth, one of the biggest "containerization" recommendations is to not run your database (example: Postgres) in a container, correct? Due to I/O performance decre…
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…
> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…
> A sizable fraction will be concerned about 'container overhead' (and "scalability issues") when asked to move workloads to containers. They are usually not able to explain what the overhead would be, and what could potentially be causing it. For what it's worth, one of the biggest "containerization" recommendations is to not run your database (example: Postgres) in a container, correct? Due to I/O performance decre…
I ran some casual tests using and found out there is a performance hit in using db binaries inside a Docker container due to Docker networking (different for different types of networking).
Earlier quoted context omitted.
I think it is widespread because containers are (seemingly) marketed as being some kind of magic. The impression I get is that the benefit to containers is that you don't have to think about them. This may be more a product of Docker but I think containers and Docker have become synonymous. I'm not sure this is a fair comparison but that is my impression. I could be in a bubble too.
I’d like to think so too. It’s hard to actually understand how Docker works by reading their documentation. Everything looks so simple.. and it magically runs on macOS and Windows too. No wonder people think it’s some sort of a VM.