> The second thing I’ve done is avoid containers. VMs work fine for many types of applications. That’s especially true if provisioning and configuration is most

> The second thing I’ve done is avoid containers. VMs work fine for many types of applications. That’s especially true if provisioning and configuration is mostly automated. A product like Google Cloud Run looks interesting for a few low-volume backend services that I operate. Containers are a good fit there because it simplifies operations rather than increases complexity. The core infrastructure will remain VMs for the foreseeable future. VMs (even self-updating ones) can be built easily using templates with tools like Packer. And without containers, a lot of things can be done very simply, often more easily, using modern versions of systemd. You get ad-hoc namespacing, ro storage, resource (CPU/network/memory/I/O) limiting, CPU pinning, private networking, logging and much more by the power of a single line more in the .service file. Throw a tight selinux configuration on top of it and you got a pretty good per-service, secure "container" on your system. Additionally, you get smart .service dependency handling, service auto-restarts, notified restarts if you care to implement it, scheduled tasks, and so on in a multiprocess environment that makes you just sad thinking back to having to resort to stuff like supervisord.