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

121–130 of 134 posts

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

#121

Post by jen20 »

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 is abjectly untrue with regards to the origins of the term - though it is the current state of the world, and your assertion about job reqs for "DevOps Engineers" is spot on.

"DevOps" as a term was coined by Patrick Debois and Kris Buytaert to succinctly refer to the concept of operations teams and development teams collaborating in a more appropriate manner than the "throw stuff over a wall" which is still common in many enterprises. It was unrelated to tooling.

We must not let vendors co-opt terms in such a way as this.

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

#122

Post by jschwartzi »

bluGill wrote: post #32
jschwartzi wrote: post #28

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.

The devil is in the details of the details.

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

#123

Post by potta_coffee »

chrisweekly wrote: post #57
potta_coffee wrote: post #48

Earlier quoted context omitted.

As a developer, I'm not happy about it either. I'm now expected to write code, as fast as possible, and then handle all the ops / sysadmin tasks too, which I don't enjoy and am not really equipped to handle.

But wait, aren't you "full-stack"? That means you also know all the minutia of UI animation rendering performance optimizations across the mobile landscape, right?

I can "get by", but that doesn't mean I'm able to do an excellent job on every aspect. It's definitely a long chain of compromises.

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

#124

Post by justanotherc »

legulere wrote: post #80
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?

Abstractions usually only work within a boundary. If you understand the underlying implementation you know its limitations. Abstractions help you to not think about the implementation all the time and to have your own code work in a coherent way.

> If you understand the underlying implementation you know its limitations

Maybe in some cases, but then I could probably make a case for that being a poorly built abstraction.

All you really need to understand about an abstraction is the required inputs, and the expected output. Having knowledge about what's going on in the black box inside doesn't really serve a functional purpose IMO. This is the very purpose of abstractions. If we sat and reflect on all the abstractions we utilize every day, we would realize we can't possible have intimate knowledge of how they all work. We just don't have enough space in our brains.

I have no idea how my OS runs under the hood. I don't care as long as the inputs I provide yield the expected output. Same goes for how my phone connects me on a call, or how my car manages air/fuel ratio in order to control engine power.

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

#125

Post by jdmichal »

ZoomZoomZoom wrote: post #89
CBLT wrote: post #29

Earlier quoted context omitted.

> To this day, I've heard CGroups being mentioned only once. See https://www.kernel.org/doc/Documentation/cgroup-v2.txt > "cgroup" stands for "control group" and is never capitalized. The singular form is used to designate the whole feature and also as a qualifier as in "cgroup controllers". When explicitly referring to multiple individual control groups, the plural form "cgroups" is used. To this day, I've heard cgr…

>Does it really feel that much better to be one level above others? Yes? Because levels are finite and quantifiable.

I mean, maybe technically, but not practically. Knowing how your computer works requires knowledge of semiconductors, p- and n-type doping, quantum physics, etc.

So yes, maybe you can enumerate the levels, but at some point they become not useful to discuss. The same way that discussing NPN gates is not really useful to discussing containers and VMs.

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

#126

Post by jdmichal »

moomin wrote: post #55
cmckn wrote: post #23

Earlier quoted context omitted.

Agreed. The post feels a bit pedantic; I don't know any dev doing "cool things" with the underlying namespaces/cgroups. They're just using Docker. De-mystifying containers has value, but so does the abstraction.

Plenty of them using those features, if they’re using Kubernetes, Docker Swarm or especially Istio. They might not know they are, but that’s besides the point.

> They might not know they are, but that’s besides the point.

I actually thought that was exactly the point here...

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

#127

Post by tyingq »

cle wrote: post #76
hadsed wrote: post #75

Earlier quoted context omitted.

so what's the gap here with docker? what incorrect assumptions would i make from assuming this as a model for containers, if anyone knows

The gap is that it's skipping half of what makes Docker powerful, and what isn't really discussed in this conversation at all either. Distribution. E.g. see this line of code: https://github.com/p8952/bocker/blob/master/bocker#L25 "But I thought bocker implements Docker?" It doesn't, it only attempts to implement the "Docker daemon" part, and piggy-backs on Docker registries for image distribution. This is a huge par…

I'd argue that bocker makes that more clear. It takes away any idea that the magic is in the containers. To the degree that it is, Linux provides that...not Docker.

It helps focus on what Docker does provide, as you mention.

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

#128

Post by gonzo41 »

dielectrikboog wrote: post #114
gonzo41 wrote: post #94

Earlier quoted context omitted.

Imagine a Graph, the x-axis is time or adoption of a set of technologies. Right now the hump in the bell curve is CI/CD and devops. It's safe to be in a large group. If something better comes along then it'll start happening and in 15 years I expect the whole of government to adopt it when you are bemoaning the pitfalls of any new approach.

I know what a hype curve is, and I made two substantive points to differentiate this situation from a hype curve. I’m not “bemoaning the pitfalls,” I’ll repeat that I’m concerned this approach, which is gaining traction and getting solidified and entrenched, will spook the decisionmakers on being willing to accept your 15-year solution when it comes along. If you’re going to be as patronizing as you are, please at le…

CI/CD is a good enough framework at the moment. The goal is to build things and ship product to customers. It does that well and thats why it's winning.

The fact that a jenkinsfile starts with groovy and can include N number of different languages is just the nature of the beast. There is always fragmentation in software integration, and devops is integration on steroids.

Any other methods, formal or otherwise, need to provide X value at a cost of Y that makes adoption worth it. Currently if you don't use CI/CD then the value and cost propositions of adopting CI/CD actually start to make a lot of sense if you are mature enough to accurately do cost accounting on your IT management processes.

Yes, it's true, Jenkinsfiles, Cloudformation Json and Yaml all suck to work with. And configuration management is tricky. But I know that we'll all think the same thing about any other system or approach we adopt because it'll end up being work.

CI/CD may be a trade off but it allows us to focus on business problems rather than technical ones.

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

#129

Post by MuffinFlavored »

wmf wrote: post #36
MuffinFlavored wrote: post #31

Earlier quoted context omitted.

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

    docker run --rm \
      --name postgresql \
      -e POSTGRES_PASSWORD=postgres \
      -d \
      -p 5432:5432 \
      --cpuset-cpus="0-1" \
      --cpus 2.0 \
      -m=1024m \
      --mount type=bind,source=$HOME/docker/volumes/postgres,target=/var/lib/postgresql/data \
      postgres:12.2
native results on a digitalocean VM:

    $ pgbench -c 100 -j 2 -T 60 postgres
    starting vacuum...end.
    transaction type: 
    scaling factor: 1
    query mode: simple
    number of clients: 100
    number of threads: 2
    duration: 60 s
    number of transactions actually processed: 17660
    latency average = 342.761 ms
    tps = 291.748482 (including connections establishing)
    tps = 291.791293 (excluding connections establishing)
in a docker container:

    starting vacuum...end.
    transaction type: 
    scaling factor: 1
    query mode: simple
    number of clients: 100
    number of threads: 2
    duration: 60 s
    number of transactions actually processed: 13014
    latency average = 466.928 ms
    tps = 214.165822 (including connections establishing)
    tps = 214.199201 (excluding connections establishing)
214tps in docker, 291tps outside of docker

26% decrease, with a bind mount on ubuntu 18.04

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

#130

Post by MuffinFlavored »

navaati wrote: post #112
takeda wrote: post #77

Earlier quoted context omitted.

I would be more concerned about writes going through additional fs layers and about abrupt termination of a container. You generally are trusting a database to keep your data safe, so those things will contribute to data loss. Remember the freakout about PostgreSQL not handling sync() correctly on Linux due to ambiguity in the man page? Having a networked filesystem + additional abstractions (like layers) etc only re…

Except you never do that (having your DB directory be in the container rootfs). Nobody does, because then (beside the performance/reliability impact you mention) if the container goes (docker rm) the data goes. You're always gonna use a Volume for this kind of cases, be it K8s volume or Docker volume, and these, as neighbour message mentions, are just bind mounts (or actual mounts in certain cases), so no layers, no…

check out my response here: https://news.ycombinator.com/item?id=22809524

looks like docker with a bind mount has a 26% decrease in performance versus native

Post reply on HN