Why You Should Consider Kubernetes Over a Custom Docker Deployment

A few years ago, when Docker burst into the tech world’s consciousness, best practices for deploying Docker containers at scale weren’t obvious.

That’s the main reason companies that were early adopters of Docker started by building their own custom automation to deploy their Dockerized applications on a fleet of cloud instances.

Over the years, I’ve seen many custom solutions that aim at solving the orchestration problem.

Some companies built automation using existing configuration management tools like Ansible or Chef. Others coded their own orchestration engines or built a huge spaghetti of unmaintainable bash hell.

The question that I hear many times is why and when should we migrate from our custom deployment solution to Kubernetes — or any other Docker orchestration platform, for that instance.

Here are a few benefits to consider when you evaluating a migration to Kubernetes:

Benefits Of Kubernetes Over Custom Solutions

1. Quicker onboarding for new team members

Kubernetes quickly becoming an industry standard. More and more developers are getting their hands dirty using its CLI and learning its declarative manifests format (more on that later).

Over time, it will become easier to onboard new team members if you use a common tool like Kubernetes for your deployment.

Some may say that Chef and Ansible are already standard and many developers know how to understand its language.

And to some extent it’s true.

However, since Kubernetes doesn’t have a full blown configuration management language, (more like a YAML definition of its resources), it’s easier for a new employee with some Kubernetes experience to understand what’s going on under the hood. The other option would require him or her to learn your Chef or Ansible’s code structure and how this configuration code is being deployed and run on actual servers.

2. Faster feedback loop

Deploying a new Docker image to an existing Kubernetes cluster usually takes less than a minute, so the process is very efficient.

Running Chef or other configuration management roles on a server may take several minutes, and it’s even worse if you need to bake a new AMI image and gradually replace old servers with the new image.

Reducing the time it takes for your team members to see results of their work will make them much more productive. And there is even an open-source utility called draft that will watch for local changes and redeploy your code to a Kubernetes cluster automatically, which is very convenient and automates a few commands, which makes the development process faster.

Kubernetes also has a local development environment, called Minikube. You don’t need to configure and maintain your own Vagrantfiles and images to help your developers create their local dev environments.

3. Large and evolving ecosystem

Let's say you need to attach a persistent disk to a container.

If you’re deploying with Ansible, you’ll need to write your own roles to accomplish that. However, if you’re running your containers on Kubernetes, you have a wide range of persistent volume plugins to choose from, from Amazon’s EBS to cloud-agnostic solutions like GlusterFS.

This is only one example, and the Kubernetes ecosystem is growing day by day. You can find a variety of networking plugins, monitoring services, serverless implementations and more.

Just checkout the awesome Kubernetes repo on Github and see yourself.

4. Fewer silos

What happens with custom solutions is that usually someone on a team will know everything about it and will maintain it while other team members will need his wisdom to solve their deployment problems.

This creates a silo within your development organization. If this person is unavailable, or just buried working on urgent production issues, everyone else on the team will be waiting for his availability, which means the release process will stall.

Kubernetes, in comparison, has a higher-level configuration format than Ansible or Chef, so fewer people on your team will become rare experts. It also has a powerful CLI which allows your team members to interact with the platform directly instead of committing changes to configuration management code and expecting to see a working service sometime in a future.

Kubernetes also has lots of documentation online which evolves and becomes better over time. Most of the time, your developers will be able to solve their own problems by reviewing Kubernetes documentation or reading a few relevant answers on StackOverflow.

Chef and Ansible are valuable because they allow you to define infinite ways for your application’s deployment. With Kubernetes, you have some flexibility, but instead of coding your deployment process, you use a built-in object that implements the deployment process for you — you just need to provide it with a few configuration parameters.

Summary

These are only a few situations I’ve experienced while working with my clients. I’m sure that people who are responsible for Kubernetes marketing can add more points to this list.

Overall, for small to medium size organizations, migrating from a custom solution to Kubernetes for deploying Docker containers will eventually increase their developers’ productivity.

The only downside is the migration itself — migrating to a new infrastructure is risky and takes time. If you want to understand more about migration challenges, I’ve written about them in “How To Avoid Downtime When Migrating To Kubernetes.”

***

Loved this article? Give this post some ? below.

The article was originally published at opsfleet.com