Zero-Downtime Deployments with Docker Compose – No Kubernetes Required

>What happens if a container in the VM goes down or the app inside of it crashes, how do you recover?

Docker will restart container automatically. You don't have to do anything. Docker-compose will restart after VM restart. You don't have to do anything. If a VM goes down - I do have a HA (another VM at another provider) and DNS load balancing.

>Now you need some self-recovery mechanism via systemD or whatever, which will grow in complexity and fickleness over time. Congrats, you are now doing your own version of kubernetes.

While I don't like systemd, it does this automatically, while, it's not really used here.

> What happens when you need to upgrade/restart your VM? Ok, make a standby VM as backup that will mostly sit idle, or require a full-app redeploy any time you need to do anything to the first VM. Now you need to design a blue/green mechanism between them, and probably some networking layer work. Congrats, you are now doing your own version of kubernetes.

This has been pretty much answered already but, upgrades does not affect containers (unless docker engine upgrade). Restarts - docker will handle these automatically - nothing to do here.

> What happens, if running in cloud, you have a regional outage or degradation? Stand up another VM in another region and manage the networking layer between them. Or, if running locally, your ISP has an outage because of a backhoe or something. Ok, we'll rent rack space in another data center as backup. Own all the mechanisms between cutting between those two now. Congrats, you are now doing your own version of kubernetes.

This actually handles way better w/o managed kubernetes, as it's usually a single region and your cluster and workloads would simply be completely down, while mine would work, because of provider redundancy.

> What happens if your app gets huge volume during peak times, and very little volume during non-peak, and you find yourself overprovisioning to the point your CFO/CTO freaks out about the bill? Well, we'll make our own dynamic scaling mechanism. Congrats, you are now doing your own version of kubernetes.

Kubernetes with autoscaling wins hands down here, but, it's not automatic, nor hassle free. You are also assuming overprovisiong which is usually not the case for traffic spikes.

> What happens when your app traffic gets so large you start running into OS limitations, like file descriptor limits? Start trying some of the aforementioned solutions. Congrats, you are now doing your own version of kubernetes.

This also affects k8s, exactly the same way.

> What happens if you need service discovery, monitoring, or ensure network isolation between various services? Different VM's + your own hacked together service mesh, or wire something in the VM. Congrats, you are now doing your own version of kubernetes.

I do have service discovery and network isolation built into docker, thanks.

> What happens when you need to guarantee secret isolation between containers? Congrats, you are now doing your own version of kubernetes.

Believe it or not, it's the default with docker.

> Let's say you don't actually need any of this or think you never will. Fine! That's valid. But what you don't want, is to suddenly hit some scale and any of these things (I could list way more but I feel I am belaboring the point), migrating off these setups can become a year+ project, if not way longer. I know because I have had to do this twice now. I cannot possibly understate how painful it is.

All my workloads are containerized and I can just move them to a k8s cluster whenever I want, if needed.

2) the risk of the VM + container spiraling into complexity is perceived. as way more than going more complex at the start.

The risk of your k8s ecosystem spiraling into operators madness and argoapps over helmfiles all while trying to accommodate for ci/cd and costs offing the chart is - IMHO - way higher.