Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Containers vs. Zones vs. Jails vs. VMs (2017)

blog.jessfraz.com

Post reply on HN
Print view View original

31–40 of 134 posts

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#31

Post by MuffinFlavored »

outworlder wrote: post #4

> 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 decrease?

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#32

Post by bluGill »

jschwartzi wrote: post #28
justanotherc wrote: post #19

Earlier quoted context omitted.

You talk as if that's a bad thing. As a developer I don't want to wade into the details of systems I'm using, I want to spend my time writing code that solves the business problems I'm tasked with solving. If there is a system that allows me to do that by abstracting away the details I don't care about, why wouldn't I use that system?

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.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#33

Post by nunez »

outworlder wrote: post #4

> 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…

This is extremely widespread amongst the really large companies I've consulted for (with equally large development teams to boot). "Containers are VMs, but smaller and/or faster" is an extremely common school of thought. I would like to think that this viewpoint is dying somewhat, especially now that many large organizations have at least experimented with orchestrators like Kubernetes or ECS.

I can't blame them, however.

If you're a dev at a company where such misunderstandings are pervasive, and you're interested in trying to get your app running in this "Docker thing that you've heard of", you will, probably:

- need to seek out a Linux dev server because you probably don't have admin rights on your machine, and getting Docker installed onto your machine in a way that doesn't suck is more trouble than its worth,

- have engineering management that are being told that containers are like VMs, but smaller, likely from magazines or sales/pre-sales consultants,

- Have to wait days/weeks to get SSH credentials to a dev server that has RHEL 7 on it, hoping that it has Docker (a thing you've heard of at this point, but don't really know much about it otherwise),

- Have to wait even more time to get Docker installed for you on the dev server by a sysadmin that dislikes Docker because "it's insecure" or something, and

- be constantly reminded that your job is shipping features before anything else, usually at the cost of learning new things that make those features more stable

The point here is that environments like this are barely conducive for getting engineering done, let alone learning about new things. Moreover, the people that will do anything to scratch that itch usually find themselves out of companies like that eventually. It's a circle of suck for everyone involved.

So when I introduce containers (which Docker is, by far, the most common runtime, so I introduce it as "Docker" to avoid confusion) to someone who doesn't know what cgroups or namespaces are, or someone who responds with something about containers being VMs or whatever, I happily meet them where they are at and do my best to show them otherwise.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#34

Post by aprdm »

dielectrikboog wrote: post #24
aprdm wrote: post #22

Earlier quoted context omitted.

This is a great post but I want to say that I feel there's space for both. IMO a DevOps Engineer would sit between the sysadmin/network folks and the developers who wants to be users of a system. In my current gig we've moved from the DevOps department to the Platform department as it aligns more with what we are trying to provide. A Platform for developers. That said we essentially can speak sysadmin and can speak d…

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 some component of the platform itself fails.

At least my perception of SRE is that they're on call for products.

That said I would frame the work we do as “a software engineer focused on operational integration“.

That does sound like a good book and I will add to my to read list.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#35

Post by twic »

dielectrikboog wrote: post #14
jagged-chisel wrote: post #12

Earlier quoted context omitted.

An experienced software engineer (yeah, developer) has experience engineering software. It’s been less than 10yrs since the advent of containerized deployments, and the space has been fraught with change nearly on par with the front end JavaScript ecosystem. Might as well just stick to writing code. OK, that’s the perception of my own peers, but I assume it scales. DevOps is a recent advent, too, and sounds to me lik…

SRE was born of putting software engineers to work building operational software and automation tailored to an organization and application. In contrast, no matter what anyone says, DevOps was objectively born of replacing the operations discipline and career track with a poorly-understood tool economy and ongoing opex to a cloud provider. As you say, typical JavaScript engineers can’t be bothered to understand netwo…

> no matter what anyone says, DevOps was objectively born of replacing the operations discipline and career track with a poorly-understood tool economy and ongoing opex to a cloud provider

This isn't the origin of DevOps.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#36

Post by wmf »

MuffinFlavored wrote: post #31
outworlder wrote: post #4

> 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…

No. Docker volumes aka bind mounts have little or no overhead. You don't want to run a database in an ephemeral "cattle" container without some kind of HA because you'd lose data.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#37

Post by ben509 »

justanotherc wrote: post #19
pojzon wrote: post #5

Earlier quoted context omitted.

This is widespread unfortunately. Developers changed to „users” and no longer pursue the details of solutions. Im not gonna say its the dominant behaviour in the field right now, but I see it more and more often on various experience levels.

You talk as if that's a bad thing. As a developer I don't want to wade into the details of systems I'm using, I want to spend my time writing code that solves the business problems I'm tasked with solving. If there is a system that allows me to do that by abstracting away the details I don't care about, why wouldn't I use that system?

I do want to wade into the details, so I'd put it more that I need to try many things, and by necessity I have to be a user before I can become an expert.

I know a good deal about how Docker works from having hammered at it. I'm not remotely an expert in it yet, but as I go I'm learning more details about cgroups and namespaces, and this is stuff I've been able to fit in while solving problems.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#38

Post by aprdm »

MuffinFlavored wrote: post #31
outworlder wrote: post #4

> 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 think it is more because containers should be stateless and you cannot make a database stateless.

We do run databases that do 100k`s ops/s in containers but we don't run them in kubernetes. We just mount the VM hard drive in it.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#39

Post by aprdm »

dielectrikboog wrote: post #17
delusional wrote: post #15

Earlier quoted context omitted.

Has sysadmin not evolved? if I found some sysadmin logging into a production system and editing the config file in nano today, I'd be downright depressed.

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.

Even within SF. Having talked with a bunch of folks from Amazon and Netflix they're far from having most of their workflows running in containers... imagine is the same for google.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#40

Post by icedchai »

dielectrikboog wrote: post #30
icedchai wrote: post #27

Earlier quoted context omitted.

You still need to do capacity planning, change management, monitoring, etc. within your cloud environment. Those AWS instances and the software their running doesn't manage itself. For some subset of "cloud", such as PaaS providers like Heroku, etc., you are absolutely correct. For another subset of "cloud", you still need sysadmin / ops skills to manage it.

Yeah, you do. It’s a shame pretty much every single cloud-native shop in existence, you know, doesn’t bother, and pushes out the people arguing for bothering. I’ve been at this nearly two decades, and I have yet to find engineers even running an Excel notebook of inventory , much less capacity planning. You know, because describe-instances and monitoring and Ansible and Chef and blah blah. My role right now is tellin…

I won't argue that running your own infrastructure is a better deal for many types of applications, especially if you can plan everything out, forecast usage, etc. There is absolutely a lot of waste in cloud spending. I've found tons of it myself. Cloud "cost optimization" is definitely a good business.

What "cloud" really buys you is flexibility. I also don't really miss the days of buying my own servers, lugging them into a data center, waiting for drops to be provisioned, going there late at night when there's a failure, or talking remote hands through stuff.

Post reply on HN