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

Containers Don't Solve Everything

blog.deref.io

Post reply on HN
Print view View original

21–30 of 99 posts

Re: Containers Don't Solve Everything

#21

Post by rualca »

encryptluks2 wrote: post #9
superkuh wrote: post #3

It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…

I don't think dependencies is the only benefit of containers. I personally like the isolation they provide and generally prefer running services in containers, even if they are using the same dependencies as my OS. I run Linux too, so I don't have to worry about any virtualization framework overhead.

> I personally like the isolation they provide and generally prefer running services in containers, even if they are using the same dependencies as my OS.

I would also not downplay the importance of Docker's support for software-defined networks and it's ability to arbitrarily configure networking at the container level.

I firmly believe that networking doesn't pop up so often while discussing Docker because Docker solves that problem so fantastically well that a complex problem simply ceases to exist and completely abandons everyone's mental model.

Re: Containers Don't Solve Everything

#22

Post by the_duke »

colechristensen wrote: post #16
superkuh wrote: post #3

It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…

Containers halfway solved some big existing problems that most people don't seem to see very well. Packaging is hard, and both debian-based and rpm-based (and really most other's I've seen) are pretty awful. (except BSDs, which I've had a lovely time with) They're slow, they're stateful, writing them involves eldritch magic and a lot of boilerplate, and they're just frequently broken. Unless you're installing an enti…

> Containers halfway solved some big existing problems that most people don't seem to see very well

A big reason for that in the past much fewer developers were confronted with this problem domain.

In larger companies packaging and deployment was often the responsibility of ops, with some input from and interaction with development. That of course also meant much longer lead times, arguments about upgrading versions of libraries or other executable dependencies, divergence of production and development/test environments, and the associated unfamiliarity with the production environment for developers and hence often more difficult debugging.

Ever since Docker (+ Kubernetes and various cloud specific container solutions) became so popular, a lot of devs now at least partially deal with this on a regular basis.

Which is mostly a good thing, due to the negatives above.

Re: Containers Don't Solve Everything

#23

Post by AnIdiotOnTheNet »

MaxGabriel wrote: post #15
zbuf wrote: post #11

Earlier quoted context omitted.

This is well put. Containers side-stepped the deficiencies of Linux distributions, which had become so based on 'singleton' concepts; one init system, one version of that library etc. A shame because there's an inherent hierarchy; everything from the filesystem, UIDs, $LD_LIBRARY_PATH that could really allow things to co-exist without kludge of overlay filesystems. Just it was never practical to eg. install an RPM in…

This sounds like a lot of stuff that Nix solves, the multiple versions of libraries coexisting part at least

Nix strikes me as the Linux community looking at an overly complicated problem of their own making and deciding that the solution is to add even more complexity.

Don't get me wrong, from what I hear Nix actually does deliver on the promise for the most part, it's just that you have to learn a new language to use it effectively and of course it has its own quirks.

Re: Containers Don't Solve Everything

#24

Post by cfors »

Yes containers don't solve for dealing with the mess of third party saas that every company is built around.

But that's why anytime you integrate with one of these tools you should be aware that there is a cost for maintaining that integration.

Re: Containers Don't Solve Everything

#25

Post by nimbius »

the one thing containers addressed was their use as a countermeasure to rising costs from greedy VPS providers, and as an agile framework to quickly evacuate from a toxic provider (cost, politics, performance, etc...)

providers in turn responded by shilling their 'in house' containerization products and things like Lambda for lock-in.

Re: Containers Don't Solve Everything

#26

Post by johnchristopher »

kendru wrote: post #2

Author here. I have been developing Docker applications for years now, and while the experience is better than it used to be, it's still not great. I work for Deref, which is working on developer tooling that is more amenable to modern development workflows. We'd love to hear what pains you have with the current state of development environments.

I am not a 10x engineer or a linux wizard.

I wish someone would rewrite docker-compose in a single go or rust binary so that I don't have to deal with the python3 crypto package being out of date or something when simply configuring docker/docker-compose for another user (usually me on a different machine or new account).

Re: Containers Don't Solve Everything

#27

Post by encryptluks2 »

kendru wrote: post #14
encryptluks2 wrote: post #8

This looks more like an advertisement than a useful blog post. Also: > Consider also that Docker relies on Linux kernel-specific features to implement containers, so users of macOS, Windows, FreeBSD, and other operating systems still need a virtualization layer. First, FreeBSD has its own native form of containers and Windows has its own native implementation. Docker != containers. I really don't see how Docker (or c…

I am familiar with FreeBSD jails (and IMO, they are actually superior to Linux containers in most respects). My point is not so much that other systems don't have the tech to make containers work - or that OS vendors are not capable of adding containers to their kernels - but that having container technology is not the same as having a smooth devex for containerized applications.

The fact is Linux containers are probably hotter than anything else. Almost every enterprise are using them to some larger extent, and Kubernetes has become the platform of choice.

Is vanilla Kubernetes easy for new developers? No, but there is an entire ecosystem offering tools and platforms to make development using containers a seamless as possible. Microsoft saw this, so they really had no choice but to adopt the container terminology and partner with Docker to try to stay relevant.

My guess is without containers, Microsoft would have never even built WSL. If you want smooth developer experience with containers then that is what solutions like GitLab offer. Even Microsoft's GitLab is essentially built around running various actions inside containers.

I personally welcome the change. I can spin up a local Kubernetes cluster and test an entire cluster of applications locally if I want, or integrate it into Skaffold or whatever else and test live in the cloud. It really is a lot better than what we had before. I think the solutions though really come down to documentation and resources to help train new employees and acclimate them.

Re: Containers Don't Solve Everything

#28

Post by stingraycharles »

the_duke wrote: post #22
colechristensen wrote: post #16

Earlier quoted context omitted.

Containers halfway solved some big existing problems that most people don't seem to see very well. Packaging is hard, and both debian-based and rpm-based (and really most other's I've seen) are pretty awful. (except BSDs, which I've had a lovely time with) They're slow, they're stateful, writing them involves eldritch magic and a lot of boilerplate, and they're just frequently broken. Unless you're installing an enti…

> Containers halfway solved some big existing problems that most people don't seem to see very well A big reason for that in the past much fewer developers were confronted with this problem domain. In larger companies packaging and deployment was often the responsibility of ops, with some input from and interaction with development. That of course also meant much longer lead times, arguments about upgrading versions…

> Ever since Docker (+ Kubernetes and various cloud specific container solutions) became so popular, a lot of devs now at least partially deal with this on a regular basis.

But that’s in line with the whole premise of DevOps, right? That the strict separation between dev and ops is a bad thing, and it’s good that devs get involved with ops and vice versa.

I don’t think this has to do with containers per se, but they do help a lot with that goal.

Re: Containers Don't Solve Everything

#29

Post by mikepurvis »

ryanmarsh wrote: post #10
kendru wrote: post #2

Author here. I have been developing Docker applications for years now, and while the experience is better than it used to be, it's still not great. I work for Deref, which is working on developer tooling that is more amenable to modern development workflows. We'd love to hear what pains you have with the current state of development environments.

How do "modern development workflows" differ?

Not sure about the GP, but for me, it's a pretty big difference jumping from tools like docker to ones like buildah, microk8s— I feel like k8s really makes good on many of the original promises of the "container revolution" in terms of automatic provisioning/scaling/image lifecycle management, declaratively defining relationships between containers, adding a much needed upper layer of abstraction in terms of the pod, etc.

I know docker has made it part of the way there over the years with Compose and so on, but it's all felt pretty ad-hoc, whereas k8s feels like a cohesive system designed against a clear vision (which makes sense, since it was designed as borg 2.0)— no one else working in this space had the benefit of having already built a giant system for it and used it at scale for years beforehand.

Re: Containers Don't Solve Everything

#30

Post by 5e92cb50239222b »

colechristensen wrote: post #16
superkuh wrote: post #3

It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…

Containers halfway solved some big existing problems that most people don't seem to see very well. Packaging is hard, and both debian-based and rpm-based (and really most other's I've seen) are pretty awful. (except BSDs, which I've had a lovely time with) They're slow, they're stateful, writing them involves eldritch magic and a lot of boilerplate, and they're just frequently broken. Unless you're installing an enti…

(Almost) nobody is using Arch Linux on servers, but I find its package system to be very good (not surprising since it was mostly copied from BSD ports).

A few random examples (not the best you could find, just something I've used recently):

- re-packaging pre-built binaries:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=visua...

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nomad...

- building C from source

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=tinc-...

- building Go from source

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=yay

- patching and building a kernel

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux...

Post reply on HN