Hacker News Reader

Comment by salawat | Hacker News Reader

I have never been able to realize the alleged ergonomic gains of containers. Ever. It always adds more friction to actually getting something initially stood up, prototyped, and deployed.

I'm guessing it may be one of these things where it only starts to make sense after something has matured enough to warrant being replicated en-masse in a data-center environment.

Then again, I tend to live in a world where I'm testing the ever-loving crap out of everything; and all that instrumentation has to go somewhere!

View on HN

I can’t live without it.

The power of docker compose for the development process is unparalleled. Being able to declare my entire local environment in a single file in a consistent way, create and destroy it with a simple command, and share it with my co-workers eliminates so many issues.

Then being able to package my application in way that is repeatable and predictable is great. Then that same artifact is run across multiple environments spanning data centers around the world and on other developers’ machines via their compose files if needed.

We test the crap out of all of this as well. Docker helps there to generate ephemeral environments to run the bulk of the integration tests against every time we push to git.

Its just so damn powerful compared to what we had before…

Agreed, and the fact that I can launch and develop my web app from seven years ago, no matter how much my environment has changed, is a lifesaver.

There's a lot of code I've written that's not deployable any more because the versions of the dependencies it was using don't exist on my OS any more, and are too old to install.

As long as you have saved the container image and contents of all mapped volumes somewhere. Which is not much different from snapshotting a VM.

Snapshotting a VM is a pain in the ass. It takes forever and the tooling sucks. The concept of snapshotting is also completely wrong. Snapshots are tied to a VM with the specific VM being front and center, you know, the thing that is disposable with containers.

Also, from my misadventures with Ubuntu VMs I always ran into the problem of them breaking over time.

Repeatable, not reproduicible...

Those sound the same to me. Are you drawing a distinction between a repeatable/reproducible process vs result? Like if you run the same command to fetch a dependency, you wind up with different results if the dependency maintainer releases a new update and you aren’t pinning the dependency?

Reproducible in that context means that repeating will produce exactly the same output every time.

To use the apt analogy further up in the thread, `sudo apt install git` is repeatable in your dockerfile, but often not reproducible. Later on you will get a different build. Across say 500 packages and 1,000,000 containers (or say 1000 container images if you are deploying images) over even a week this becomes extremely... varied...

On smaller scales, this is perfectly fine. How often does Git actually release breaking changes of features that you actually need to use inside your Dockerfile? How often does Debian pull in such a version into their stable OS? And why didn't you just version-pin Git like Hadolint told you to do?

Exact reproducibility is nice for two scenarios: 1) academic research, and 2) very large-scale applications and deployments. For regular people writing boring small web apps, choosing a stable base image and pinning dependencies is good enough.

Consider also that your preferred programming language will also very likely not provide particularly reproducible package builds.

Although you can.

This just means you don't.

Try using `sudo apt install git=1:2.39.2-1ubuntu1`

That pins it to a particular version so that it should be reproducible.

Would that work, though?

I've never looked seriously into it, but my feeling is that distros will delete old versions as newer ones are uploaded: When I run "apt-cache policy git" in my Ubuntu, I only see a couple versions available to install, often other packages show only a single one (so, the latest).

I know that Debian has Snapshot for older packages but you are still at the will of other people and people are fickle, and Nix should allow you to use specific versions to build your base images from to pin to.

However, much in the same way that if you actually take your build system seriously you'll store your application dependencies in a local proxy, you can run a mirror or proxy to hold these historical packages too.

Take a look at something like apt cacher, however it is a proxy cache so you can reproduce builds using the exact same package versions but if upstream delete old packages, and you want to roll back to one you haven't previously downloaded, then you are out of luck.

Yes. This can be a problem in scientific research involving numerical code or random number generation, where results can vary even due to small inconsequential-seeming changes, leading to your results not being reproducible scientifically because they're not reproducible computationally.

It's reproducible enough for most purposes most of the time. When is the last time your Python web app serving cat pictures went down because of a subtle change in the Debian Bookworm container?

...Funny you bring that up.

I was cobbling together build scripts for a mail system for Raspi/Armbian the last couple weeks. Very similar packaging stuff, but the number of little subtle differences in install/postinstall/prerm/postrm scripts took a generous level of spackling over to get just right.

Hell, once I get everything nailed down, I'm writing test frameworks for my bloody build scripts if you can believe it.

So...uh... Last week?

Fair enough, but I don't think that's a typical experience.

> It's reproducible enough for most purposes most of the time.

The freedom given in ability to limit your thinking space by reproducibility should not be under stated.

Same with static types. Sometimes it really helps to limit yourself, other times it's setting up unnecessary obstacles with no benefit. Sometimes you want Idris 2 or Rust, and sometimes you want Ruby or Clojure.

Are you using bazel as your build system? If not, for almost all languages, your build system itself is probably not reproducible. Gcc uses random numbers. Lots of compilers add timestamps to builds (javac does).

For almost all non-Google use cases, repeatable is generally good enough.

For me, it solved A LOT of cases where users said "your software install fails", "the software doesn't run", or similar claims. They tend to be complicated to troubleshoot: people try setting up new software in an already customized development environments, and all sorts of mistakes are done.

It was refreshing being able to say: this works perfectly from a base Ubuntu 20.04 container, launching this and that commands to install and run the software. Anything that diverges from there, you're on uncharted territory and/or is a problem in your system, not a defect in the software.

Containers aren't about you. They're about the person you're trying to hand things to.

I got stuck creating VMs for testers for a distributed workflow (several services, several tools), and keeping those VMs up to date and working was a PITA, but far less painful than dealing with them filing bug reports based on thinking they were doing X when they were doing Y.

I ended up creating a workflow that felt like layers, so when Docker came along I didn't need a salespitch. I could just do what I'd done with a script instead of a runbook. Where do I sign up?

Exactly.

Containers are packaging for executables.

Another decade or two and perhaps the Unix community will finally reinvent the .exe or .app

It's more than just creating a distributable, though. It's also a dev fixed environment and a cross-compiler when paired with qemu, and a test suite all rolled into one. It's hugely powerful for how simple it is.

That's just.......wrong.

MacOS makes static linking quite difficult.

And Windows is infamous for "DLL Hell."

Windows 9X/2000/NT was long time ago, nowadays that it more a GNU/Linux problem than Windows one.

It's more like chroot, with a special namespace for processes.

They did, many times. they're called flatpaks/snaps/self executing zip files.

Even windows reinvented the exe with msi's, and python has dists and wheels, and *nix/bsd has jails and vms have existed forever, and java has the jvm with jars and previously, applets.

Of course, none of those are actually as user friendly nor cross platform compatible as docker. Heck even docker isn't perfect and will leak abstractions once you start hitting syscalls (network, filesystem, etc), or if you're like 99.9...% of developers who don't host their own artifactory and cryptographically tag every step in their dockerfile

Show me an .exe that can self deploy an elk stack across windows, Darwin, and Linux with minimal system environment issues

> They did, many times. they're called flatpaks/snaps/self executing zip files.

Honestly, getting some desktop software in the form of one of those is wonderfully refreshing. Just take an AppImage file or whatever, make it executable and run it.

Sometimes you don't care about the benefits of shared libraries and want something to just run regardless of what's going on with your distro, for which these technologies are great. Ideally, in addition to the proper package manager approach for those that value different things at different times.

But for shipping things like WebApps, OCI containers and Docker/Podman is amazing.

I was a huge fan of portable apps back in the day. Plug in a usb stick, and boom, I could use firefox on my school computer instead of ie6

Containers are packaging for executables with their OS.

There is a long, bloody history of packaging executables with only their direct dependencies.

Guess what? That's what I do. Still seems more like an anti-pattern, because the "easier and more thoughtless" I make the entire process, the more my testers don't pay attention to those details, or figure out how to make new tooling, making me the central point of load bearing failure.

Docker doesn't fix that. In fact, sometimes it makes it even harder for my testers to keep track of what is happening where. A shockingly high number aren't even able to visualize the logical boundaries between physically cohabiting, but logically partitioned systems.

It's too many damned layers.

And developers do awful things with docker containers to the point I end up having to rip apart multiple projects Dockerfiles to rebuild those, but with different values to work around the fact that oh .. look at that, this one spins up a postgres database that wants to bind to ports we're already using. Looks like I get to go dig into the base image to change that port and rebuild...

Again, not saying it doesn't work. As someone who put in the work to become a generalist though, I put in an asinine amount of time working around other peoples things that quote "make things easier".

Maybe for the person writing it. Certainly not for someone learning from it or having to analyze it.

Being able to run self contained postgres with a single command is an easy ergonomic win. You don't necessarily need to be an engineer or write code for containers to be useful.

How you inform your backup system where to get backups ? How you set pg_hba and other configs? Few other "how?" and you're doing what you'd be doing on VM anyway

> How you inform your backup system where to get backups ? How you set pg_hba and other configs?

Simple answer: with configuration. In Docker Compose or Kubernetes. Less often in Mesos. Maybe I want to run it on a fleet of VMs, maybe on bare metal.

> and you're doing what you'd be doing on VM anyway

Right. But with containers I can have different apps using different dependency versions. Some things use nginx, some use some other web server. Some things run with node 12, some with node 16, some things use MySQL, some other things need Postgres. This is so easy with containers.

So my issue is that now I have PostgreSQL running... inside a container? So I need to figure out where the data for it is stored and figure out how to ensure it is being backed up.

And like, that's just minimum: I generally care deeply about the filesystem that PostgreSQL is running on and I will want to ensure the transaction log is on a different disk than the data files... and I now have to configure all of this stuff multiple times.

At some point I am going to have to edit the configuration file for PostgreSQL... is it inside of the container? Did I have to manually map it from the outside of the container?

The way you access PostgreSQL locally--maybe if you find yourself ready to add a copy of pgbouncer, but also just to run the admin tools--is via unix domain sockets. Are those correctly mapped outside of the container, and where did I put them?

I honestly don't get it for something like PostgreSQL. I even use containers, but I can only see downsides for this particular use case. You know how easy it is to run PostgreSQL in some reasonable default confirmation? It is effectively 0 commands as you just install it and your distribution generally already has it running.

> So my issue is that now I have PostgreSQL running... inside a container? So I need to figure out where the data for it is stored and figure out how to ensure it is being backed up.

And how is that different from running directly on the OS?

the OS will have an understood abstraction behind the filesystem structure, whereas container-systems often create an entirely new abstraction that they view as the best way.

this makes sense when you're trying to be deployable universally, but it increases the amount of onboarding that someone needs to receive before they're proficient with the container system; onboarding they may have not actually needed to get the software working and well understood, simply 'docker overhead'.

from personal experience : i'm a long time old linux person, the insistence on going 'all in' on Docker (or whatever) just to run a python script that has two or three common shared dependencies gains me nothing but the hassle of now having to maintain and understand a container system.

if you're shipping truly fragile software that is dependent on version 1.29382828 rather than version 1.29382827 then I understand the benefits gained, but just to containerize something very simple in order to follow industry trends is obnoxious, increasingly common, and seemingly has soured a lot of people on a good idea.

p.s. : I can also understand the idea of containerizing very simple things as parts of a larger mechanism; I just don't get it with the promise that it'll reduce end-user complexity, it isn't that simple.

About "truly fragile software", it seems to be the norm now, thanks to the ease docker provides to hide this

Database in container solves a few problems for me:

1. I can start it and stop it automatically with Compose. That's a big increase in ergonomics.

2. I don't have to write my own scripts to set up and tear down the database in the dev environment. The Postgres image + Compose does all that for me.

3. Contributors who don't know much about Unix or database admin stuff (data analysts learning Python & data scientists contributing to the code) don't have to install or mess with anything. It works on everyone's machine the same way.

Volume and port mapping are basically trivial concepts anyway. There's been zero downside for me in using it, even though I personally have the skills and knowledge to not "need" it. Why would I go without it? It saves me time and effort that could be significantly better used elsewhere.

I am honestly shocked by the amount of comments here that mention volume mounts as some gotcha. No it isn't. It is as trivial as it gets.

I like your point of view. I started working with software more than 20 years ago and did my fair share of VMs, bare metal, ESXi 3.5, and so on.

However, we live in the world where the choice we have for new hires is: a) teach them all of those OS fundamentals, b) give them Docker.

This doesn’t mean we shouldn’t strive to teach said new developers all those underlying concepts, but when we talk about training juniors and have them contribute relatively quickly, it’s a much smaller surface area to bite through.

Docker doesn't solve having to know OS fundamentals as both the inside and the outside of the container have an OS, and now you additionally have to know how to communicate between the former and the latter.

> This doesn’t mean we shouldn’t strive to teach said new developers all those underlying concepts

That's what I said.

Furthermore, let's be pragmatic. The operations team needs to know, yes. We want new hires to contribute and feel productive. They'll naturally learn while working on software. A junior person can contribute almost immediately with a limited surface knowledge.

Less friction: no need to understand systemd/upstart/rc what have you, /etc, /opt, /usr, mount, umount, differences between various distros, build-essentials, Development Tools, apt, dpkg, rpm, dnf, ssh keys, ...

The right time will come but give them an easy way in. Containers provide exactly that.

All they need to know: it's somewhat isolated so under normal circumstances whatever you do in the container doesn't affect the host, how to expose ports, basics of getting your dependencies in, volumes, basic understanding of container networks - for things to talk to each other they need to be in the same network. Enough to start.

Every problem you mention here is solved by working primarily from your compose file/deployment manifest and having that be your source of truth.

- Where is the data stored? Your compose file will tell you.

- Is the configuration file in that container or mapped? File tells you. (If you didn't map it, it's container-local)

- How do you get to it with admin tools? If you mapped those sockets outside, file tells you.

Problem: too many config files.

Solution: config file for the config files.

I literally don't have to do any of that if I just install PostgreSQL the normal way as the confirmation file is in the same place the documentation for PostgreSQL says it is in, the daemon is probably already running, and all of the tools know how to find the local domain socket. Why am I having to configure all of this stuff manually in some new "compose file"? Oh, right: because I am now using a container.

It's really hard for me to not make some incredibly dismissive "okay, boomer" comment here, but you are not giving me much to work with and this really reads as obstinate resistance to learning new things. Are containers different? Without a doubt. The benefits are, however, impossible to ignore.

The amount of work you are complaining about is, objectively, trivial. It's no harder than learning how to deploy on another distro or operating system, except in this case, your new knowledge is OS-agnostic.

I agree. All he is doing is making people uncomfortable for using containers. The only real major downside with containers is that the building process is quite expensive so you should get familiar with docker run -it --rm <id> bash or the same thing with docker exec. Oh and also that your container might not come with diagnostic tools.

All my automated integration tests use a real Postgres database in a known state. I don’t mock or stub or use an in-memory database pretending to be Postgres. It’s nice.

Yup. And you can make sure to run your tests in the exact same Postgres version you are running in production. No need to go help your teammate whose machine is for some reason behaving different, due to some weird configuration file somewhere that they forgot they changed it 6 months ago.

> So I need to figure out where the data for it is stored and figure out how to ensure it is being backed up.

As a user, this is why I love Docker. The configuration is explicit and contained, and it's well documented which directories and ports are in play.

I don't need to remember to tweak that one config file in /etc/ which I can never remember where is. Either it's a flag or it's a file in a directory I map explicitly. And where does _this_ program store its data? Don't need to remember, data dir is mapped explicitly.

That said I haven't tried to use PostgreSQL myself directly, just tools that uses it like Gitea.

Yes this is the hidden beauty of docker... "I don't need to remember". Someone can reverse engineer exactly how I have a goofy custom postgres setup instantly, just by looking at my original Dockerfile I committed a year ago. No hunting around on the OS!

As someone else said, docker isn't about you, it's about everyone else. The extra complexity up front is so worth it for the rest of the team.

> So my issue is that now I have PostgreSQL running... inside a container? So I need to figure out where the data for it is stored and figure out how to ensure it is being backed up.

You bind a mount to where the data is onto the external system. That way only the important data is exposed. It's very clean, although it requires you understand docker a bit to know to do this. But for things like postgres and similar sprawling software that basically assume they're a cornerstone of your entire application and spread out as though this was the case, it's actually a very neat way of using them a bit without having them take over your machine.

This is something that can be useful for a developer too. Like my search engine software assumes it owns the hardware it runs on. It assumes you've set up specific hard drives for the index and the crawl data. But sometimes you just wanna fiddle with it in development, and then it can live in a pretend world inside docker where it owns the entire "machine", and in reality it's actually just bound to some dir ~/junk/search-data.

Although I guess an important point is that using docker requires you to understand the system better than not using docker, since you both need to understand the software you run inside the container, as well as docker. It's sometimes used as though you don't need to understand what the container does. This is a footgun that would make C++ blush.

> Being able to run self contained postgres with a single command is an easy ergonomic win. You don't necessarily need to be an engineer or write code for containers to be useful.

Postgres is a poor example; it's far far easier to do `apt-get install postgresql` than to run it from a container.

The latter needs a container set up with correct ports, plus it needs to be pointed at the correct data directory before it is as usable as the former.

Is this some kind of joke? Those things are absolutely trivial and once you wrote them in your bash script or compose file you can forget about these things.

It solves the "we can't possibly package the software for all versions of libc out there" and the "there are all those programs that must run at the same time, it's hard to correctly install them all" problems. People push it to solve the "this program needs executable A version 1, that program needs executable A version 2, both programs must run at the same time" one, that should never be a big issue anyway.

But then, we have none of those problems at work and people still believe it's a panacea. I don't know what people believe they gain by it.

Dependency management is one thing Docker handles, and I don't really think it does a great job of that. To me containers solve the challenge of getting a development environment that closely matches production. It standardizes how deployments are performed, how testing environments are set up. Before this we had complex, immutable ansible scripts, READMEs, install scripts that had to be babysat, snowflake servers that no-one knew how they were configured. It's also an extremely widely used technology, so if you use it in your stack you can expect many people you hire to know how to use it from day one versus everyone learning a bespoke set of custom scripts.

This was already trivially solvable by establishing a new sysroot, which in all fairness is 90% of the core benefit of containers in my view. The rest of the container features are bloat for most of my use cases.

It also solves the "we have limited developer-hours available and just want to deploy some stuff" problem. Docker is amazing for teams with limited resources. If you can deploy one image, you can deploy any image.

That's my point. I hear a lot of what you say, but I don't understand it.

In general, without some kind of qualification, deploying an image is way worse than a flat binary, or a tar from some interpreted language.

I don't know what you are talking about. My production setup is dumber than you would think. A bunch of bash scripts in a git repository. You just do git pull and then run a single bash script. ./app build builds the entire thing. If you want to run it then do ./app start.

Yes you do need to configure some environment variables like in almost any other form of deployment.

Messing around with tar files or flat binaries doesn't work for me. I tried that. I build a python app into an executable with Nuitka but it generates a folder anyway. Ok throw it in a tar file. Nope, doesn't run because the glibc version is too new on the developer machine. Nice try. I have to build it on the target machine. Amazing.

I feel the same about your post. I have no idea how deploying a flat binary or Python tarball is better than a container image. The entire system is effectively a dependency. Docker (or equivalent) lets me ship the entire system. Moreover I can take quite literally an image of that one system and deploy it to any number of machines identically, without any rebuilding. And I can host it interchangeably on any number of cloud providers with only small changes in configuration. The benefits go on and on. I would only ever bother with a "plain" deployment in the future if I had complete control over my deployment environment (+ the in-house expertise and time budget to manage it) and the performance overhead of the container was unacceptable.

You answered your own question. When you join a large project and there's a perfect dev environment available in 3 minutes with `make init`, it makes sense. If you're the solo dev, it doesn't make sense to spend 5 hours figuring out the docker build system.

In my experience it never ends up being this simple. At least not with a combo of make and docker.

I have yet to be handed a containerized dev env that "just works".

One company came close, they had someone dedicated to maintaining the dev tooling including the containers. It still didn't "just work" but they handled the troubleshooting, and the fix made it into the repo for the container so it wasn't just an unwritten adhoc fix I needed to remember. Close enough.

I totally get the concept, I wish it worked so seamlessly that the promise was realized. But since I usually work with tooling I am familiar with, there is no point for me personally. I can stand up a local env faster than I can troubleshoot a broken container. Since I am not interested in the infrastructure and just want to get to work, that is what I do.

Every time I see this, I peek at the init target and it's always doing something weird like writing to my SSH config or something. I have learned to never trust installers written by colleagues.

Well there is one unarguable one, although with consequences.

Instead of keeping some old machine with old dependencies because project is on life support and doing update to latest version of language/tools is unviable, you can just keep a docker container for it while machine it is running on is up to date.

It doesn't solve the problem of application, but it is no longer ops problem that app is old.

You can also do that partially, like keep old PHP version running with just fcgi socket exposd in a container, while rest of the app lives on "normal" VM (or other container, if that's what you want).

That's what got me on the Docker kick. Old unsupported programs that are tightly coupled to a kernel version, a Windows thing, some combination of Java / JDK shenanigans, an old SoundBlaster DLL, "The Python Carnival", or, really, what-have-you. Honestly, every big ERP demo ever should be done via container, because - and I swear I am not making this up - I have sat in months-long meetings with dozens and dozens of staff, both mine and theirs, trying to get Big ERP X up and running on-prem under whatever weird-ass policies the customer has on all their environments.

Granted, a lot of THAT benefits from the fact that the container actually has to be a documented flavor of good solid *NIX, unlike the "Windows Image X" which is usually just a big "whatever" of old iron, management fad spoor, and seven different kinds of antivirus software. Hell, last time I did this, IT couldn't even find me any kind of description of what the "official" windows image actually was. So no fault of Windows there, it's just that, as the big bus everyone rides in, it gets all the goop from everyone wrenching on it.

> seven different kinds of antivirus software

The last time I counted up all the different persistent, security-related agents running on my corporate Windows box, it was actually 14.

I guess we live in entirely different worlds, because, for me, containers have been a godsend. Standing up the average application is a matter of reading a compose file and modifying it according to instructions, or using it to construct a proper manifest for something like k8s for full production.

For toy/evaluation use, it's hard to beat "tweak compose file, docker-compose up". You now have a golden source of truth for how the entire application and all of its moving parts were set up.

Going back to deploying applications on bare metal feels positively medieval by comparison. From the admin side, configuration drift is effectively not a thing anymore. That's huge.

It feels like admins just offloaded the job of deploying apps back to developers. And as a developer I woudn’t even mind, if not for the f-ing slowdown of, well, the pace of development. All external teams that I worked with and who were using containers for development were like “oh you need that trivial endpoint or a bugfix? No problem, we’ll do it in few hours and it will autodeploy tomorrow”. And I didn’t ask why, because I know. As if we weren’t snail-paced money burners already.

Provided all that, I don’t get why “devops” is even a high-paying job at most places except few really web scale ones. They are basically former sysadmins who reject anything except plugging colored squares into square sockets.

I'm on the other end of the spectrum. I don't want to deal with written instructions. A shell program will do but a container is the best. Give me an environment with all dependencies, software, and some decent configuration method. A config file over a volume will do, env vars are better. Dockerfile tells me everything I need to know about the environment the app requires.

I can run that container in CI, in tests (with stuff like testcontainers), on my laptop, in production, on Kubernetes, in Mesos, Lambda, whatever.

Instrumentation usually ends up in Prometheus and Jaeger.

To me, containers are like OOP. Nice ideas on paper but a pain the ass in practice. but again, like OOP, a lot of people do great things with them but I don't think they can't do the same things with VMs.

My theory is eventually things will come full circle and there will entire app ecosystems running in a unikernel executable which is running on physical hardware and the hardware itself is segmented. I can imagine companies like netflix and cloudflare having racks of servers with 1TB ram with no disk, booting a unikernel from the network for maximum throughput and latency and then everyone in tech follows along.

I think you don't understand the problem.

What people want is the ability to do all these things with a single command that they put inside a bash script.

Have you tried setting up a python project with native dependencies on a different version of OS than original developer?

If you cannot even set up your dependencies, a container might look like a solution, but I can assure you, it isn't.

It is the best solution. In my particular situation, at last.

Another solution would find a senior developer who can manage his dependencies properly, but I can't afford him. However, I can pay a junior ML developer wage and just throw what he develops in a docker image instead of wasting time and money on doing things the hard way for a prototype.

As engineers, we're supposed to be rational people, but unfortunately, we tend to forget that time and money are often happen to be the most important constraints we have to work around.

No, i haven't. (not OP but) The last decade or more 90% of people i collaborated with were on the same operating system. Which moves the docker development setup solidly into "nice to have" category for me, especially when working on small teams <10.

Things easily break even between minor releases of the same system.

I have an app that needs a media server, a webrtc STUN/TURN server, a PostgreSQL database, a JVM based web server, a worker that may or may not run on the same host and a way to run liquibase for migrations and certbot for letsencrypt certificates.

The whole app can be started with a single command and it works on most Linux distributions. I can't imagine wasting the time of users or newbie developers demanding that they install all these things separately and with no easy way to clean it up if they want to undo everything.

Instead of composing libraries into an executable you can use containers to compose services into an application [0]. As noted in the sibling comment, this still can have a high utility for just a single workstation/service. Also as you noted, scaling to a datacenter is already partly automated. The entire environment is captured in code and reproducible/portable. But you need to be familiar with the tools and ecosystem to make use of them.

[0] We don’t have concise terms for the types of distributed, complex systems which have become standard.

> Instead of composing libraries into an executable you can use containers to compose services into an application

This is the most concise and exact definition I've heard lately.

My only problem with the consequences of this approach is that the amount of overhead for performing the same operations is astonishing.

Messages pass on a network instead of stsying in RAM, CPU context switches every other ms to handle IO for what could have been a simple function call, etc.

It's amazing when it's needed, but seeing this approach becoming the standard for a big part of the industry almost turns it into an environmental problem. How much energy is wasted juggling bits around?

It doesn't have to be a library replacement. It could be that your app uses a DB server and a message queue for async tasks. Containers allow you to easily run those servers locally for dev if you don't care about performance and maybe in prod you'll have a dedicated server for them, or use some DB as a service offering.

Yeah, agreed: in that case spinning a container is evidently an operational advantage.

However, I was specifically answering to the different case highlighted by the parent comment: how a potentially cohesive application is cut along some of its internal APIs, and some functionality is allocated to different processes living in different containers.

It is an extreme point in the continuum "single thread" -> "multi thread" -> "multiple processes" -> "fully distributed". In that continuum scalability increases, while efficiency progressively decreases.

Cornering oneself to a specific point in the design space is problematic, and for some cases has direct implications on how many resources are wasted.

A very didactic experience is, for example, running a simple local application under a microarchitecture profiler, such as Intel Vtune. It is not uncommon seeing that even straightforward C/C++ programs use a core resources less than 10%.

What I am reflecting about is that the choice of fragmenting that program among tens of systems (maybe in a scripting langiage) should be conscious, and done after encountering performance or scalability bottlenecks.

How much of the resulting total system workload would be useful work?

The quantity of potentially wasted resources is astonishing if you think about it.

They make sense if you're using Python, because Python dependency management is awful. For anything else they're not really worth it IME.

Not at all. They make cross compiling fairly trivial, and give teams a way of managing cross compiled dependencies. This was vital a few years ago for things like torch and even opencv, where deploying on anything other than x86 meant you were probably on your own, and you almost certainly wanted control over the compiler flags.

That's just one example, though. It also lets you standardize the dev environment (work directly out of the build container directly, or use your host OS and run unit tests in a local build), and it allows for easy, standardized testing within the same environment.

> Not at all. They make cross compiling fairly trivial, and give teams a way of managing cross compiled dependencies.

How so? A container is the same architecture as the host, how does that help with cross compiling?

You combine qemu with docker. You can then run arm containers and compile your code locally for deployment to an arm board.

Qemu is the part that's making that possible though. What's docker adding?

The ability to kickstart the whole process with a few commands, possibly just a single bash script.

So what Vagrant already did?

Reply on news.ycombinator.com