I'm not a passionate container person, but let me try: the basic upside is isolation/containment. For a moderately complicated application, there'll generally

I'm not a passionate container person, but let me try: the basic upside is isolation/containment. For a moderately complicated application, there'll generally be several backend processes. A database, perhaps a message queue, several application processes. To install and run the application, you would need to eg. install one or more package repositories, install a bunch of packages, edit various configuration files, create various users, and then arrange for everything to start (and stop) in the right order. That's kinda painful to set up, and even worse to tear down. There are/were two popular solutions: automation, and containers. Automation addresses the grunt work: you script the process of installing and configuring (and later removing) all the bits of this application. Where automation falls short is that it doesn't have the isolation/containment: applications still exist in the same namespaces, and can collide. A container can package all of this stuff into a single blob, and you can run it by giving it a simple port mapping, and a simple storage mount, and ... it just works. It doesn't matter if you have a different application with a different version of the database server running on the same host. Or a different version of, eg. Python. You don't have to mess with unique users or groups, and it's trivial to map the externally visible ports where it suits you. That was the first-phase pitch. And it made sense to people whose life was spent dealing with the complexities of making things work together. Things then got less clear cut. So far, this was just a per-machine thing. The obvious next step was to scale "containers" out to get their benefits, but using a whole fleet of hosts, not just one. Welcome to orchestration. The benefits are still the same: you spin up a bunch of containers, and they are all self-contained, isolated, it-just-works bundles. The orchestration framework deals with how many of each of them you need, putting them in the right places, and hooking things up together. It's *way* less work than doing it by hand, and especially when you do dynamic scaling or failover or config changes. But ... then containers and orchestration frameworks became kinda the expected way to do things, even when it wasn't really necessary. A simple, self-contained app doesn't need a container, and many things don't need full-blown Kubernetes. Containers are good, but only if they address a problem you have. So far as software distribution goes: if your installation instructions are more than a couple of lines, then you might as well put together a Dockerfile, and make your customers' lives easy. And be quietly thankful that we're not distributing VMware images any more :-)