For some teams, Kubernetes is the new hotness, a must-have — either because of bottom-up pressure (developers want to play with cool tech) or from top-down — because your CIO heard that it will solve all your problems. You may not actually need Kubernetes.

Dilbert cartoon from https://twitter.com/danieldibswe/status/1169485819993841664

It turns out that just moving an existing solution to the cloud doesn’t automatically fix inherent issues in its design (who would have known?) There are however some benefits, so let’s look at a stepped approach to technology vs complexity.

Move to the cloud

On the continuum, moving some applications to the cloud can leverage benefits without a large up-front investment.

My complexity rating level is: low to average.

Pros:

Easy to get redundancy and cheap to start — compare the up-front cost of 10 EC2 instances vs 2x Dell PowerEdge servers.

Elastic capacity means it’s easier to handle spikes and simple to bring on new hardware

Managed services, dashboards for visibility and built-in compliance for SSO/audit trail

Cons:

Unpredictable spend, many SaaS services start low and ramp up exponentially, according to usage

Requires expertise in cloud automation, often using APIs specific to a single vendor

Move to containers

The use of containers can standardize a bespoke, complex build and deployment pipeline into something that is easier to maintain.

My complexity rating level is average.

Pros:

Docker’s motto of “Build, ship, run” does check out, you build an image, ship it efficiently by only moving the delta of its layers and then deploy it to a machine

Developer-friendly

Repeatable build artifacts for local dev, CI, staging, and production

Widely used and recommended by ThoughtWorks to avoid or reduce vendor lock-in

Can be used to bring a Linux-style development environment to Windows users in enterprise IT

Cons:

Provenance and compliance of Docker images can be questionable, when the Docker Hub was scanned for issues, up to 1/5th of the images contained CVEs

Local builds with Docker can be slow, and difficult to optimize

Elastic scaling requires additional software such as Kubernetes

Move to Kubernetes

Many teams will move to Kubernetes without first evaluating “cloud” and “containers”. Generally, both are beneficial when adopting Kubernetes, but not strictly required.

Kubernetes brings clustering to containers and when run on a managed cloud can start to look like “serverless”, where there is a shift in focus away from individual servers and more towards distributed computing.

My complexity rating level is: high to very high.

Pros:

Over 100 independent service providers are certified to provide paid support

Computers join a pool compute and are workloads are scheduled according to capacity and load

Dozens of paid products and open source projects exist in the ecosystem to address: storage, networking, security, governance and more

In 2020 over a dozen local Kubernetes solutions exist for Windows/Mac and Linux. Every self-respecting IaaS/cloud vendor has a managed K8s offering.

It can even be run at the edge on low-end hardware such as Raspberry Pi using Rancher’s k3s distribution

It is possible to extend and customize Kubernetes heavily

Cons:

Many teams are scared of Kubernetes due to its reputation for being complex, others are stuck on last-gen technology because it appears to still work.

Some are just not willing to try Kubernetes because the ecosystem is so broad and that causes confusion

It’s not trivial to operate Kubernetes and customizations are difficult to maintain due to breaking changes in the APIs

Where are you in this journey?

The CNCF defined a Cloud Native “trail” to help companies navigate the ecosystem that has been developed around cloud, containers, and Kubernetes.

You’ll note that the journey begins with containers, and it would be great if we could all start there, but as noted, some teams will benefit from moving workloads to the cloud. Application frameworks and stacks such as LAMP and Ruby on Rails can be deployed to the managed cloud and scaled without containers. There are also managed services such as AWS Lambda, which do not require any containerization to be exploited, but which come with their own set of tradeoffs.

Other teams that have already built-up muscle memory around deploying applications to the cloud, maybe ready for containerization and should spend time getting comfortable here. It may be as far as you need to go for the time being. I recently launched the “faasd” project which combines several of the key technologies used in upstream Kubernetes such as CNI and containers to provide a “Serverless” deployment model for APIs, websites and async processing.

When static scaling of your workloads becomes a pain point, and you need more advanced capabilities around storage, networking, governance, and security, it may be time to consider Kubernetes. But beware, there be dragons. You may benefit from an application stack akin to LAMP or Ruby on Rails, but for Kubernetes. For me, that was the PLONK stack — Prometheus, Linux/Linkerd, OpenFaaS, NATS and Kubernetes. For you, it may be something else, but it is worth thinking through whether you want to deal with low-level configuration files and toolings like Helm, or higher-level concepts such as “services”, “secrets” and “auto-scaling”.

In conclusion, I believe there are benefits to using the cloud (whether private, hybrid or public), containers and to Kubernetes. The more these are compounded together, the greater the complexity, but the greater the potential.

So yes, you may not actually need Kubernetes, yet.

Connect with me on Twitter and subscribe to my premium newsletter at alexellis.io if you’d like to read more content on Cloud Native, containers and Kubernetes.

You may like some of my other recent stories about Kubernetes:

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬.

To join our community Slack team chat 🗣️ read our weekly Faun topics 🗞️, and connect with the community 📣 click here⬇