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

71–80 of 99 posts

Re: Containers Don't Solve Everything

#71

Post by javier10e6 »

raesene9 wrote: post #38
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 solve the problem of clashing library versions needed by different applications running on a single host (and I know there are other ways to solve this). This is really not a new problem :) I remeber dealing with shared libary versioning issues from no long after I started in IT in the 90's and it's been a problem since. Solving that problem seems like a win to me.

Containers add a substantial level of indirection for us, developers. Now we have to grow a seventh arm to juggle to manage/fold into our workflow. For production? Hands down the right solution. For development, I wish, only wish, We could live without.

Re: Containers Don't Solve Everything

#72

Post by zekrioca »

swagasaurus-rex wrote: post #50
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.

That's exactly how ChromeOS works.

Re: Containers Don't Solve Everything

#73

Post by tracker1 »

moonchrome wrote: post #48
bob1029 wrote: post #31

Earlier quoted context omitted.

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

Looks like .Net 6 (formerly Core), due for full release in a couple months supports M1 Macs[1] as a build target just fine. So does MAUI[2]

1. https://github.com/dotnet/runtime/issues/43313

2. https://docs.microsoft.com/en-us/dotnet/maui/get-started/ins...

Re: Containers Don't Solve Everything

#74

Post by KingMachiavelli »

Containers don't solve anything more than virtual machines. Containers are 'better' than virtual machines because they have less overhead and are 100% open source.

Containers and VMs let you divide and solve problems in isolation in a convenient manner. You still have the same problems inside each container.

Firstly, Docker & k8s made using containers easy. Minimal distros like alpine simplify containers to a set of one or more executable. You could implement the same thing with a system of systemd services & namespaces.

But now that everything was a container, you need a way to manage what & where containers are running and how they communicate with each other.

It looks like 90% of the stuff different container tools and gadgets try to solve is the issues they created. You can no longer install a LAMP stack via 'apt install mysql apache php7.4' so instead you need a tool that sets up 3 containers with the necessary network & filesystem connections. It certainly better because it is all decoratively defined but it is still the same problem.

This is why I mostly stayed out of containers until recently. The complexity of containers really only helps if you need to replicate certain server/application. You will still need to template all of your configuration files even if you use Docker, etc.

What is changing everything IMO is NixOS because it solves the same issues without jumping all the way to Docker or k8s. Dependencies are isolated like containers but the system itself whether it is a host/standalone or a container can be defined in the same manner. This means that going from n=1 to n>1 is super easy and migrating from a multi-application server (i.e a pet server) to a containerized environment (i.e to a 'cattle' server/container) is straightforward. It's still more complex and a bit rough compared to Docker & k8s but using the same configuration system everywhere makes it worthwhile.

Re: Containers Don't Solve Everything

#75

Post by tracker1 »

javier10e6 wrote: post #71
raesene9 wrote: post #38

Earlier quoted context omitted.

Containers solve the problem of clashing library versions needed by different applications running on a single host (and I know there are other ways to solve this). This is really not a new problem :) I remeber dealing with shared libary versioning issues from no long after I started in IT in the 90's and it's been a problem since. Solving that problem seems like a win to me.

Containers add a substantial level of indirection for us, developers. Now we have to grow a seventh arm to juggle to manage/fold into our workflow. For production? Hands down the right solution. For development, I wish, only wish, We could live without.

It's made the entire process MUCH easier for me... `docker-compose up -d deps` and I have all my background services running local... `... api` and the api is also running and I can concentrate on the UI.. `... ui` and it's all running. I can then run tests against the whole thing.

Also, setup all the containers to include unit test results in the runtime container... this gets extracted/merged in CI/CD. Beyond this, I can stand-up the entire application and run through full integration and UI test suites in the CI/CD pipeline. Same commands locally... it all is much smoother than prior experiences.

I will NEVER run a database install on my developer desktop again. Database deployes on the main application I work with, and unit tests all finish in about 5 seconds or less (not including initial download). I'm also able to run db admin apps right with the DB.

Persist volumes, run/test upgrades and from-scratch. It all goes really smoothly overall. Wouldn't ever want to go back to mile-long dependency instructions step by step to getting a development environment running ever again. WSL2 + Docker Desktop are pretty damned great.

Re: Containers Don't Solve Everything

#76

Post by [deleted] »

csande17 wrote: post #61
jzoch wrote: post #35

Earlier quoted context omitted.

What solution wouldn't require its own specification + quirks? Whether its a Dockerfile or nix package I don't see the difference besides people tend to be familiar with only 1 of the many options. Im not comparing whether Dockerfiles or buildpacks or nix packages are more ergonomic than one another but i do think your comment is...misguided. From what I have heard Nix is pretty wonderful to use and simplifies the pr…

You're right that Docker is similar to Nix, at least in the sense they both seem to be trying to work around problems with the Linux packaging and library ecosystem by piling more of their own complexity on top. I suspect the comment you replied to wants to see the actual underlying problem solved. To use an example from another community, no amount of performance improvements to NPM will ever make it a good idea to…

[deleted]

Re: Containers Don't Solve Everything

#77

Post by tracker1 »

throwaway894345 wrote: post #41
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…

For that matter, pushing for SRE roles that manage orchestrating the K8s environment and as a developer you can focus on a local docker-compose, and spend more time in testing (unit and integration). The Developer is responsible for Dockerfile, and the CI/CD build and test portions of the process.

Considering the level of options from Kubernetes, heml, istio, etc can get complex, the developer can focus on the boundary requirements... expected environment variables and peer systems/services.

Re: Containers Don't Solve Everything

#78

Post by rtkaratekid »

swagasaurus-rex wrote: post #50
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.

Couldn’t you essentially make a Linux distribution that has these by default?

Re: Containers Don't Solve Everything

#79

Post by forgotmypw17 »

ebiester wrote: post #59
forgotmypw17 wrote: post #51

My container is POSIX :)

What is your strategy that works for every packaging system and every version of every library you depend on? Nothing says love like realizing that you are segfaulting due to a library version you didn't test against subtly changing its behavior.

I use almost no libraries and stick to languages which have prioritized stability for 20+ years.

This amounts to using Perl, bash, and POSIX.

On the client side, of course, it is HTML and JS, which I use a very limited subset of to improve compatibility.

Re: Containers Don't Solve Everything

#80

Post by titzer »

koeng wrote: post #60
titzer wrote: post #58

Earlier quoted context omitted.

> They're just the symptom of the disease that is future shock. Yes, absolutely, and I hope you mean that in the capital-F "Future Shock", Alvin Toffler sense, because there is a lot he wrote that hasn't even been carried over and digested. Software is an endlessly disorienting sea of change, getting faster and thus worse as time progresses, and it's frankly madness at this point. It seems absolutely no one is commit…

How about Golang in this case? AFAIK there haven't been any breaking changes yet.

It is definitely a breath of fresh air in that regard.
Post reply on HN