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

41–50 of 99 posts

Re: Containers Don't Solve Everything

#41

Post by throwaway894345 »

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 aren’t the final destination, but they’ve enabled polyglot orchestration i.e., an app developer can target Kubernetes without needing to manage the minutia of operating a bunch of Linux hosts. It seems like almost every company that isn’t using containers for SaaS software development ends up badly reinventing Kubernetes and sinking a ton of time and money into maintaining it, and as a “human person”, I’m glad that I can focus my efforts on higher-level problems. When a technology inevitably matures to replace containers, I’ll look into it, but for now containers are the best way to build and manage heterogeneous distributed systems.

Re: Containers Don't Solve Everything

#43

Post by tyingq »

5e92cb50239222b wrote: post #36
tyingq wrote: post #33

Earlier quoted context omitted.

Java running in a container is somewhat amusing because of this. So you have a several solutions to the problem of agnostic packaging (java/jar/ear/war/etc) running inside another whole solution for agnostic packaging.

I don't think there's another way to ship custom certificate authorities without using containers? It's something you absolutely have to do around here if you want to interact with government APIs of any kind. I relatively rarely work with Java and am probably mistaken.

I'm not saying containers aren't needed. Just that we keep trying to solve packaging and end up with more layers that have to duplicate large swaths of functionality. So we get java->containers->container orchestration, for example. The containers overlap some built-in java functionality, and so does the orchestration piece.

Re: Containers Don't Solve Everything

#44

Post by throwaway894345 »

stingraycharles wrote: post #28
the_duke wrote: post #22

Earlier quoted context omitted.

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

Agreed. The core concept is that we should automate away as much of the ops workload as possible so (1) devs don’t need to learn the whole ops skill set and (2) no one is doing things that computers could do automatically. Containers and orchestration technologies are a form of automating away a lot of ops work (if you need to package an application you don’t need to solve for SSH, package management, log exfiltration, monitoring, or any of a dozen other things).

Re: Containers Don't Solve Everything

#45

Post by curt15 »

5e92cb50239222b wrote: post #30
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…

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

Does Arch support installing multiple versions of libraries?

Re: Containers Don't Solve Everything

#46

Post by Zababa »

Since the author mentionned it, is the 12 factor app still a best practice? Was it a best practice? I saw the website a few times and all of it makes sense for me, but I haven't seen much discussion about it.

Re: Containers Don't Solve Everything

#47

Post by dekhn »

the one problem containers solved for me better than anything I ever used in previous UNIX/LINUX is heirarchical resource tracking. I work with many codes that fork from their main binary and do their work in subprocesses. If your resource manager isn't scraping /proc to invert the process tree, it needs a way to assign resources to process trees such that the entire tree sum cannot exceed the resource limitation.

Re: Containers Don't Solve Everything

#48

Post by moonchrome »

bob1029 wrote: post #31
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…

> getting devs to actually care if their software runs on platforms more than a year old. This is why we don't play games with siloing responsibilities on the tech stack. Every single developer on the team is responsible for making the entire product work on whatever machine it is intended to work on. No one gets to play "not my job", so they are encouraged to select robust solutions lest they be paged to resolve the…

So you don't support M1 Macs ?

Re: Containers Don't Solve Everything

#49

Post by johnchristopher »

raesene9 wrote: post #37
johnchristopher wrote: post #26

Earlier quoted context omitted.

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

https://docs.docker.com/compose/cli-command/ ^ There's an rc of a compose command built into the standard docker CLI.

Haha, nice :D.

Thanks. Now I wish the company I work for would drop their plan to bring me back in office next week and just settle instead for a day or two of mandatory presence in the office per month (crossing fingers while you do your magic).

Re: Containers Don't Solve Everything

#50

Post by swagasaurus-rex »

OfflineSergio wrote: post #4

What solves everything?

Containerization built in to the OS, with strict privacy controls on what containers can access inside of other containers.

All applications run in its own container, unless they are granted granular permissions to do otherwise.

The code and assets for a program belong in its own quarantined section, not spread out over the filesystem or littered around /etc/, /var/

Built in networking for these containers.

Post reply on HN