Kubernetes and containers is an awesome approach to unify deployment process across the company. It allows you to build CI/CD process and automate/unify many things across your stack.
One thing though that I feel like in most cases using it, especially for small companies without separamte DevOps team, can overcomplicate the technology stack and Docker Swarm will be more simple approach without overspending limited resources on what you don't need yet.
If you want to self-host then Kubernetes is like Email, you can do it yourself but most likey it will consume too much resources to maintain and keep it up to date, so you end up choosing service provider for it.
Those are great reasons on why you would want to run Docker for local development, but why would you want to run Docker in production? My old boss takes the side of "I do not want to run Docker in production" and argues it is too much code/too much headache to be responsible for.
I think once you have the rapid development and deployment process that a kubernetes cluster allows you’ll never want to go back.
It takes seconds for me to go from saving a code change to having it running on our dev cluster and just minutes to go from that to staging and prod — mostly from tests.
If you get skaffold running on kubernetes you’ll never want to go back to developing any other way.
To give an idea about how developers feel about it once they start using it, one of the developers we just onboarded to our cluster gave An internal talk evangelizing for it and subtitled it “A love story”
> It takes seconds for me to go from saving a code change to having it running on our dev cluster and just minutes to go from that to staging and prod — mostly from tests.
I agree with this. I just feel like it can be achieved without the overhead of Docker. Deploying a .qcow2 image to an `lxc` container seems simpler.
In production it is pretty good without Kubernetes (i.e. using it on elastic beanstalk).
One of the biggest reasons for me is that the base instance's only dependency is docker. Without docker you have to install binaries on the main system and hope that virtual environments or something similar exists for the binaries. With Docker I can test the exact code that will run on production and guarantee that with an image hash.
when I put an image on elasticbeanstalk, all I have to do is specify the image and the commit hash (built with travis) I want to deploy. If I want to roll back to a previous release by changing the hash. All the instance has to do is pull in docker layers and go. I dont have to worry if package managers are going to fail or a plethora of other things that can go wrong.
I think kubernetes is overkill TBH but docker is worth it just to standardize environments between local and prod.
I have seen a number of companies try this without Docker, and it's never as thoroughly, reliably identical as Docker makes it. Plus it's a surprising amount of work.
I'm not convinced that those are good reasons to use it locally. All of them seem like crutches that allow you to rely on magic that someone else got to work so that you can delay or avoid taking the time to understand what your software actually relies on.
In my experience, that kind of understanding is critically important, especially if you want to be the kind of engineer who can find the root cause a problem and fix it permanently, rather than the kind who just shrugs and blames a configuration error that they don't actually understand, and that might happen again tomorrow or next week.
If you actually need to deploy things to dozens of servers at once, then you might have a good reason for looking at these tools. But this should come after you understand what your software is doing, what it needs, how it works, what the dependencies need, etc.
In my experience it usually is some sort of stupid config error from which I glean no deeper understanding. I'd much rather rely on magic than go around chasing bugs that I might not ever be able to convince the owner of a repository to fix, assuming the thing is even open source to begin with.
> especially if you want to be the kind of engineer who can find the root cause a problem and fix it permanently
In my experience, when it comes to team building, managers usually want to spend just enough resources to have 1-2 members of the caliber you are describing on a team. Once 1-2 are in place, you can add 6-8 mid/junior people who go to those 1-2 when there are the deep/hard problems you are describing.
> Docker helps you create a reproducible environment. You are able to specify the specific OS
Not exactly ... containers use the host kernel, but the libraries within the container. Also, global system settings can be changed at the system level.
> Does Docker support target OSes other than Linux? I'd love to have a way to test on non-Linux OSes.
Your target OS must support linux cgroups, etc. So no.
AFAIK, you can create Docker containers with Linux (these will work on every host system that is supported by Docker) or Windows containers (which work only on Windows hosts). For max performance, you should probably use Docker Linux containers on Linux hosts.
One thing though that I feel like in most cases using it, especially for small companies without separamte DevOps team, can overcomplicate the technology stack and Docker Swarm will be more simple approach without overspending limited resources on what you don't need yet.
If you want to self-host then Kubernetes is like Email, you can do it yourself but most likey it will consume too much resources to maintain and keep it up to date, so you end up choosing service provider for it.