Kubernetes and Docker: 9 reasons why DevOps is better with Docker and Kubernetes

I’ve put together this list of benefits that DevOps + Docker & Kubernetes can give you over the traditional DevOps approach.

The traditional DevOps approach

1. In the traditional DevOps approach, developers write code and put it in a git repository.
2. They then check how it works locally and in a development environment.
3. They start a code build process using a CI tool, e.g. Jenkins, which also runs functional tests during the build. If the tests pass, the changes are merged into a release branch.
4. The tests are processed on stage-environment and at the end of the sprint the release is published. The system administrators prepare the scripts for the deployment of the applications in production, using Ansible, Puppet or Chef.
5. Finally, the system administrators deploy the changes to production, i.e. they update the version.

The problems of the traditional approach

• The first problem is that system administrators and developers use different tools. For example, most developers do not know how to work with Ansible, Puppet or Chef. The common result of this situation is that the task of preparing for production falls on the shoulders of the sysadmins. System administrators often don’t understand how an application should work, as it is the developers who have the expertise in this area.
• The second problem is that development environments are usually updated manually without any automation. As a result, they are very unstable and constantly break. Changes made by one developer break changes made by another developer. Troubleshooting is usually very time consuming. Finally, the time to market is very long.
• The third problem is that development environments may be very different from development and production environments. In addition, staging may not be at all similar to production. This leads to many difficulties. For example, a version prepared by the developers may not work properly in the test environment. Even if the tests are passed in the test environment, some problems may appear unexpectedly in production. At the same time, the process of rolling back a broken production release is very problematic and not trivial, even using Ansible, Puppet or Chef.
• The fourth problem is that writing Ansible manifests is time consuming and difficult. It is very easy to lose track of changes made to manifests, when updating an application from version to version. This can lead to a high number of errors.

Improving the DevOps approach with Docker

1. The main advantage of this approach is that developers and system administrators use the same tool - Docker.
2. Developers create docker images from docker files at a development stage. They build them on local computers and run them on a development environment.
3. The same Docker images are used by system administrators who perform upgrades to the stage and production environments using Docker. It is very important that Docker containers are not patched when upgrading to a new version of software. This means that a new version of your software is represented by a new Docker image and a new copy of the Docker container, but not by a patch of the old Docker container.
4. This allows you to create immutable environments for development, storage and production. There are several advantages to using this approach. Firstly, there is a high level of control over all changes, as changes are made using immutable Docker images and containers. You can revert to the previous version at any time. Development, implementation and production environments become more similar to each other than when using Ansible. By using Docker, you can ensure that if the functionality works in the development environment, it will also work in the development and production environments.

How to get DevOps superpowers with Kubernetes and Docker

1. The process of creating the topology of an application, containing several interconnected components, becomes much easier and more understandable compared to Docker.
2. The load balancing configuration process is greatly simplified by the integrated service and input concepts.
3. With the built-in features of Kubernetes Deployments, StatefulSets and ReplicaSets, the process of continuous update or green/blue deployment becomes very easy.
4. You can do CI/CD using Helm, which is more comfortable than using Docker containers for these reasons:
   • Helm diagrams are more stable and production ready than individual Docker images. You have most likely faced a problem when you tried to interconnect different Docker containers in a common topology, but failed because these images were not ready for this type of interconnection.
   • It provides you with a high-level template language and a concept of application versions that can be undone if necessary.
   • In addition, you can use existing Helm graphs as dependencies for your own graphs, allowing you to have complex topologies using third-party building blocks.
5. Kubernetes supports an out-of-the-box deployment scenario across multiple cloud sites (AWS, Google, Hidora or another hosting provider) through federation or service mesh tools.

Have you simplified your DevOps processes by using Docker and Kubernetes? Share your experience!