If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?
This is the very first time I ever heard such nonsense. In all companies I've been, Docker is a renowned problem solver, not only for production deplyments but also for local testing environments and deployments.
It even shines as a stand-alone barebones clustering solution with Docker swarm mode.
I find it quite amusing that projects that try to position themselves as Docker alternatives end up basing their presentation on how their project can be used just like Docker, down to Docker's choice of command line interface.
The complexity of Docker is not that big for a Go deployment though, especially if you have all the other bits for orchestrating your Docker containers (for the rest of your stack) already in place. You mostly just copy the binary into a slim image and you are done.
You don't need docker for that, just 'tar czf my-layer.tar.gz my-dir'. If you want a manifest file, you can get the digest using `sha256sum my-layer.tar.gz`.
Docker does this quite well, and solves a bunch of other problems you're likely to have regardless. One really simple example is "how do you copy it to the server?" Do you have ssh keys for your server on development machines? How do you handle the "Oh I'll just remote in and fix this one X"?
It's also _crazily_ easy to get started with, and handle middling amounts of scale. If you're on AWS, Elastic Beanstalk is plug and play. If you're not, DigitalOcean App platform will host it for you, with automated deployments from git for $5/month with basically no configuration needed from you.
Publishing your docker image to some open or private store still needs to happen. Then the host needs to be updated. This is not really that much simpler than "scp your binaries to the server". And has many more moving parts that can fail.
Now, there are better ways to distribute go projects than scp, for example heroku style or by just abusing its builtin git support.
Of course, if you're doing somethign in Python/Ruby/Node.js then it's useful because these language do not provide a reliable method to compile source code into an independent program/application.
But that does not make it "awesome" or anything. It's just a band-aid. It's an extra layer to hide fundamental design problems.
With Go, the root problem is solved: the language has a compiler that reliably produces statically linked binary executable programs.
Dependencies is not really a problem with Docker, nor the thing it is designed to solve. If dependencies was the problem people cared about, everyone would just go with the single statically linked executable/fat JAR and no one would ever be bothered with Docker.
Docker is primarily about containerization, but it's also about ease of packaging and deployment. It's also a deployment format that provides horizontal scaling for free.
Also, the one-database-per-service architecture pattern is quite common, as well as ephemeral databases and local caching, and keep in mind that SQLite also supports in-memory databases.
> It's also a deployment format that provides horizontal scaling for free.
Um. Docker does not provide horizontal scaling at all, for that you need orchestration. And those tools are anything but free if your time has any value.
Maybe it will be some day, but these orchestration and deployment tools built on Docker have enormous hidden costs.
IME, Docker takes an enormous amount of focus away from the customer problem and moves it to the how to get this mess working problem.
Now may be the right time in a given business to make that shift in focus, but to claim that it will be "free" is just misleading (IME).
This is the opposite in my experience: Docker lets me focus on the business problem by making deployment easier.
At least, that's been my experience when maintaining a mess of other people's Docker crap.
It does. Please take the time to learn about Docker and it's Docker swarm feature.
Docker swarm mode is pretty good and terribly easy to get up and running in no time.
I have a few small personal projects hosted on Herzner on a couple of Docker swarm mode deployments with 100% uptime in the past two years, and all it took to get that infra up and running is installing Docker on a bare Linux node.
The only downside I'm aware is that inter-node traffic speeds can be relatively low.
Swarm pros:
- Easy to setup
- Easy to run
- Relatively easy to debug
Swarm cons:
- Many problems persist for years. Some because of lack of resources, others because the problem is simply too hard.
- The community and automation around swarm is small
- Problems solved by third party tools, apps, etc. in kubernetes require in-house workarounds or solutions (e.g. there was an API to perform autoscaling, but we had to write the python app that will read data from prometheus and scale-in/out the deployment)
What I found it with Swarm is that it was extremely resilient. At some point the swarm cluster was running on AWS for ~2 years with minimal maintenance. That would have been impossible even for a managed EKS cluster for example. There are simply too many things that can go wrong.