Docker/Kubernetes for Decision Makers

If you’re involved in a project that is building/migrating a platform, system, web portal or APIs and you are exploring what tech stack to use? You’re probably wondering about docker, containers and kubernetes. But do you really need this tech? Consider below points before making the decision!

Assumption

This article assumes you understand basics of cloud, containers, docker, kubernetes, CI-CD, and microservices. I will be using some of the terms interchangeably throughout the article.

The Decision Makers

If you’re a CIO, CTO, Director, Manager, Architect, Consultant or Developer who is involved in the decision making process, financially or delivering the solution, you would want to use the latest tech and build robust systems.

Typical Use Case

The biggest advantage provided by docker or containers is deployment consistency. Docker clearly wins against traditional deployments on Windows or Linux servers (physical or virtual) where the server OS, software, and programs or versions were different in each environment (DEV/QA/PROD etc.), making configuration management very difficult. Now, assuming you are deploying your services in cloud. Let’s say in any managed compute services like Azure App services, AWS Elastic beanstalk, or GCP App Engine for your environments (DEV/QA/PROD) then you already have deployment consistency. You are not managing underlying servers, security/OS patches and overall system management. You can host APIs, web apps, background processes, cron jobs, etc. that are developed in various technologies like .NET, Java, Python, Node, etc hosted on Windows or Linux. If you have a consistent way of creating your environment using IaS scripts (ARM/CloudFormation/TerraForm etc.), then you achieved 100% deployment consistency without using any containers. Cloud provider is managing underlying infrastructure for you.

Another advantage the kubernetes (orchestration) offer is automatic elasticity and scalability — if there is a load/high traffic, servers will scale out to support the load. This helps keep infrastructure costs low. In cloud managed compute scenarios, these features are all built in and cloud providers will take care of it. Here’s a sample screenshot for Azure webapp autoscaler:

Learning Curve

Container orchestration is a complicated tech may look simple to begin with, but learning how to use it correctly will take time. There are advanced scenarios with networking, deployments, troubleshooting, monitoring etc. that you will need to learn and develop. In addition, this technology is still evolving and new tools such as keda, helm and service mesh are added every day.

DevOps Heavy Team

To support this infrastructure, you will be maintaining container registries, a kubernetes cluster, monitoring and troubleshooting of nodes, networking, upgrades etc. While it may look like maintaining a non-containered app, this is different for quite a few reasons:

1. Technology is still evolving.
2. Cloud managed services do a lot of that automatically for you whereas with containers it’s do-it-yourself (DIY).
3. Non-functional pieces are just too complicated for an application team focused on business/product/end users. So, if you are part of an application development team, ask yourself: do you have time, energy and budget to focus on so many non-functional aspects? What is your team size? Do you have DevOps team members and skillsets? This is a huge cost in terms of creating, maintaining and supporting this kind of infrastructure.

Cloud/Hosting Costs vs. Labor Costs

Cloud hosting costs or cost savings (compared to cloud managed services) will depend on your product architecture but this cost will be insignificant compared to labor costs (people to create/maintain) the infrastructure. So, if you are counting on costs savings with kubernetes then review this again. Use cloud cost calculators for your scenarios and loads.

Niche Use Case

You may need containers if have a specific use case that is not supported by cloud managed services. For example: you are using a technology or a product not supported by any cloud managed services. In that case, you have options to use containers or host it on the cloud virtual servers.

Self-hosting

You are planning to deploy k8s/swarm cluster on-prem or on a cloud virtual instance yourself. You don’t plan to use cloud managed k8s clusters.

Cloud agnostic

If you don’t want to have a tight coupling with any particular cloud provider or you want to support multiple cloud providers, or if you are looking for a loose coupling in case you have to port to another cloud in the future, then kubernetes can be your choice! Cloud portability is not as simple as it looks since your cluster may leverage/depend on other cloud services like networking, storage, monitoring and logging. There is kubernetes cluster available on all three major clouds — AKS/EKS/GKE so this is possible.

Ideal Scenario

You have a use case for it. You have a great skilled DevOps team. You need a highly custom infrastructure/environment where you have a full control. You are ready for it.

Build a POC

Build a proof of concept with all the dependencies and compare the experience, product, tooling and cloud support.

So, do you really need it?

In the end, decide if you need such a complex tool. Understand what you are buying into before you decide to go with it.

Examples

1. Startup creating a new mobile app for small set of consumers
2. A gaming app
3. A blogging platform
4. E-commerce website and mobile app
5. Healthcare applications
6. Government website used by millions of users in peak hours
7. Search engine
8. An enterprise insurance product suite
9. New video streaming platform
10. Social media app
11. A product that manages cloud

In above list of examples, it may be overkill to use kubernetes in simple scenarios especially startups and small scale products. In case of large scale systems, you can decide to go with simple architecture in the beginning to keep things simple. Despite amazing features, kubernetes tech doesn’t seem to be necessary, especially for small- to medium-sized projects/products. If you are starting a big enterprise scale project this is used by a very large user base and needs a large scale cluster that involves a lot of domains/entities, it might make more sense.

In summary, I am suggesting to consider cloud and leverage on cloud managed services where cloud providers have done all the work for you and it’s ready for the application developers. When you think cloud providers are not sufficient then target containers technology.