Containerization isn't really that hard. At its most basic level, a Dockerfile is just a list of commands needed to build/run your program. I'd personally much rather have that as a sort of self-documenting build process than dig into "how does Visual Studio build things? Why is my local dev build process (F5 in Visual Studio) so different from our release build process (msbuild commands or whatever)?" Or worse, "why does our release process involve Joe hitting F5 on his machine?"
Deploying a container isn't that hard - I agree that k8s and such is likely overkill for most startups. A basic "docker run" bash script or something in that vein is not terribly difficult to write, maintain, and hook up to CI/CD. Even so, with growing cloud support from GCP/AWS/Azure etc, the leap from "We built an isolated container for local dev" to "Now we run that container in prod via k8s" is shrinking.
As you pointed out, there are other ways to do this, but at least right now Docker is fairly widely used and it's not limited to certain toolchains/languages. Using something just because it's popular seems like a bad idea on the surface, but if two tools are both reasonably sufficient, I'm definitely leaning towards the more widely used one - it means it's more likely new hire will be familiar with it on some level, there's more blog posts with best practices, etc.
> Imagine being able to unzip a build of your software to a blank windows/linux server and expect that it work flawlessly 100% of the time, regardless of any prior/lack of configuration or other supporting dependencies on that machine
I mean, that's basically _why_ Docker exists.
> I mean, that's basically _why_ Docker exists.
It is, but Docker isn't it. At the least, Docker won't run side-by-side with Virtual Box on Windows, so "regardless of prior configuration" is not met. In general, Docker adds an extra dependency on top of a blank system: Now you need to get Docker set up and running first, and then you can deploy your app. The alternative in question is about controlling the build to such an extent that you can reliably deploy the artefacts onto any system without having some runtime environment prepared.
For example, at my last job, before we switched to Docker, a client dev that wanted to run a local backend had to install postures, apply initial schema, and then download and run the app. Not only was this a bunch of steps the client devs weren't familiar with, it led to backend devs being reticent about using the most appropriate tool for new features (e.g. shoving service discovery awkwardly into SQL instead of into something like etcd - and before anyone says "well that's fine" or "just do xyz instead," realize that's just an example of several). It was annoying to client devs to have to add new tools all the time, and annoying to backend devs to have to constantly troubleshoot misinstallation / misconfiguration.
When we switched to Docker, the client devs could run the backend without having to manage anything. Install docker (once), then run a very basic script that basically just ran "docker-compose pull; docker-compose up".
I don't generally want to be able to deploy to arbitrary environments. I want something that is easy to build, builds consistently, and lets all my fellow devs run whatever host they need to be maximally effective.
On Windows, it's true, if you need Virtual Box specifically then you can't use "Docker for Windows". You could either move the VB stuff into Hyper-V, or run Docker directly on a VB VM (a little less turnkey, but not particularly difficult).
YES YES YES
I am certain at this point they're doing it only to show off and to have something complicated enough to talk about the train new hires on.
One big argument for Docker is no dependencies, but Go and C# already can create fat native binaries that have no dependency on anything else (no .net framework or even VM, all native, same thing in Go). I believe Rust too offers the same thing. There is no excuse with all those different languages all supporting that.
There absolutely are complicated apps that justify Docker and k8s, but the vast majority in the real world do not fall into that, and most certainly that includes small ad-hoc internal services.
Using Nix, you can build a self-contained deployment for just about any language/rutime you can imagine, and the target machine doesn't need to run Nix.
Build the damn app one time using SQLite on a single box. Then, figure out if the market even gives a shit about it. Building out a multi-cloud application architecture for your first prototype is a massive mistake. You don't need containerization tech if you can clone your application, hit F5 in visual studio, and the whole stack starts up automagically. You will probably find the performance of a single, powerful machine to be more than enough for your expected user base. SQLite can handle a fuckload of 'concurrent' writers if you know what you are doing.
There are now framework features available in some areas that help to obviate the need for containerization. If you are a .NET shop, look into self-contained deployments:
https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ...
We have been using this deployment approach for ~3 years now and we have yet to have a single situation where a required dependency was missing or broken in production. And, we deploy to a very wide range of customer environments with all sorts of horrible IT practices applied to them.
Imagine being able to unzip a build of your software to a blank windows/linux server and expect that it work flawlessly 100% of the time, regardless of any prior/lack of configuration or other supporting dependencies on that machine.