1. What is it?
Already heard of the shiny "new" tools called Docker, Compose, Swarm or Kubernetes? All of them can have a significant business impact and have the potential to cut your costs by enhancing the deployment of your applications, release-management, technical support (e.g. better/more logs, watchdogs, automatic fallback-mechanisms, ..), scalability, maintainability as well as availability (& much more). No wonder that huge corporations like Alphabet, Netflix, Uber & Co. as well as other large-, medium scale companies and even most of the startups are using Docker or at least a related technology.
This blog post won't address all the technical aspects nor the advantages/disadvantages of these technologies as there are a ton of other blog posts about it, but will rather focus on how companies which have been around for a while, could start using these tools in a productive & cost-efficient manner.
2. How to start?
Below you'll find a list of questions you should ask yourself as an entrepreneur as well as your more experienced employees (e.g. software architects, senior software engineers, ..) before proceeding with this blog post.
- What could be potential use-cases?
- What are the most urgent challenges within your organization?
- Do your employees have any prior experience with Docker & Co?
- What is your vision for your company?
2.1. What could be potential use-cases?
Established companies usually have several processes in place which can't be replaced without a hassle as employees most of the time prefer sticking to old workflows for convenience and changing processes also goes hand in hand with new problems you might have never thought of. Moreover, there is also an important saying among software engineers "Never change a running system". And they are right as long as the trade-off sticking to old routines is not big enough to switch to an alternative.
Considering that, we should rather evaluate how we can integrate Docker & Co. into our existing processes and then migrate step by step to the actual best practices. A prominent example could be that your organization deploys applications directly on the customer's server by copying the required files manually or with another tool, while container orchestration tools like Kubernetes/Docker Swarm work the opposite way by having one or more centralized dashboards to manage all of your customers' applications.
After thinking this through, we could draft some more specific use-cases for your organization, but please note that some of the exemplary use-cases below should be considered as mid-term solution to give your organization time to adapt to industry-standard best practices in the long-term.
- Dockerizing existing applications & deploying them manually on the customer's server or the cloud.
- Add simple health-checks to your docker-containers to get notified about errors immediately.
- Deploy a packaged set of containers (e.g. frontend, proxy, backend,..) with Docker-Compose which are related to one application to reduce version mismatches etc.
2.2. What are the most urgent challenges within your organization?
Talk to your employees. Where is the bottleneck in your organization? In my experience many companies need signifikant resources to maintain their applications. This issue shouldn't be underestimated as humans don't scale easily and the amount of bugs/issues which have to be handled by your support won't increase linearly but exponentially over time as the more features you add the more bugs occur, you'll introduce or discover new issues in old code and especially the deployment becomes increasingly more complex as more and more applications are interwoven which makes the whole process itself very error-prone. So, how can we fix that?
Docker, Kubernetes & Co. are not a solution for everything, but they can reduce the complexity within your infrastructure drastically (e.g. gathering all logs at one place, having one graphical control panel for all your customers, less errors because of faulty deployments -> e.g. version mismatches, etc). I think the best approach to identify your bottle-necks is to have some short meetings with your software-architect(s) and other technical leads (e.g. support, ..).
2.3. Do your employees have any prior experience with Docker & Co?
Docker, Compose, Swarm & Kubernetes are easy to get started with, but you'll face a lot of challenges as soon as you need to use them in production. Independently of the size of your organization you should have at least two employees which have some prior experience with Docker, Compose and Swarm or Kubernetes (depending on what you plan to use). As an employer it should be clear why you need to have at least two Docker/Kubernetes specialists as you would increasingly depend on those DevOps-engineers as your whole infrastructure will drastically change. That being said, most developers should have some basic knowledge about Docker to be able to debug Docker containers locally, via Kubernetes or on the Cloud.
2.4. What is your vision for your company?
I think every software-company can profit from Docker & Docker-Compose itself, but depending on how large you envision your enterprise in the future you could decide for or against container orchestration (Kubernetes/Docker-Swarm). Docker-Swarm is very easy to setup and to maintain, it has very-limited features, but isn't used in a lot of companies in production (even Docker recommends Kubernetes). On the other hand, there has been a time where people made jokes at conferences of how "easy" Kubernetes was to setup & to maintain. Although, Kubernetes became easier & more user-friendly, it is still very hard to maintain a production-grade Kubernetes cluster (especially if the cluster is self-managed = self-hosted). If you have the resources or are not sure about it, I would always go with Kubernetes as switching at a later time would be even more difficult than starting with Kubernetes at an earlier stage.
3. Important things to note
If your organization is new to Docker & Co. you should take following aspects into account.
3.1. Start with Docker
No Docker-Compose, Docker-Swarm or even Kubernetes should be used as long as your CI/CD pipelines, processes, employees (e.g. support, developers) and knowledge within your organization itself would not be fine with further changes. Nevertheless, in some cases it might make sense to start with Docker-Compose as some containers depend on each other which might make bare Docker deployments a little bit tedious. The rest can be introduced later when your adapted processes are in place.
3.2. How to configure Docker containers/images?
Use environment variables and build-arguments to configure your Docker images/containers. If you have some sort of configuration files within your application you might also want to consider substituting the environment variables into these files upon startup. Using volumes for your configuration files might be fine too, but it's not how Docker is supposed to work and this approach might get tedious when introducing Docker-Compose, Kubernetes/Swarm or even just hosting your bare Docker container on cloud providers (e.g. Azure, AWS, ..).
3.3. Prefer Linux-containers & Linux-nodes
Although Docker, Compose, Swarm & Kubernetes support Windows containers (= containers which use the windows operating system as base image), they are not very handy and come along with many new & unexpected challenges. I've listed some examples below, which I've experienced in the past.
- Kubernetes doesn't support Windows-only clusters. This means you always need at least one Linux node which has to act as master (= controlling/managing unit). Moreover, Kubernetes for Windows only works on Windows Server 2019 which needs Docker EE (charged Docker distribution) to run also Linux containers.
- Windows-Containers neither work on Linux nor with Docker Toolbox. Windows Server distributions only support Windows containers if you pay for Docker Enterprise.
- Docker-Swarm doesn't like mixed environments within one stack (= having 1 compose-file = grouped containers for one application).
- Almost all Docker images are Linux-based, which makes it almost impossible to exclusively use Windows containers. Therefore, mixing environments is unavoidable.
- Windows containers are not as well supported on Clouds as Linux containers (some don't even support Windows containers at all). Deploying a Linux stack is easy, deploying Windows containers (or even mixed environments) is a lot more complicated and might require several workarounds.
- Windows images are huge & harder to debug.
- Windows containers are almost never necessary except you are using some "Legacy" frameworks or tools (e.g. .NET Framework 4.8 and less, ..).
- To build Windows images you need to switch Docker-Desktop to Windows mode and for Linux to Linux-mode. Mixed environments then need to be run in Windows mode.