These days it’s impossible to talk about cloud (specifically IaaS, PaaS, and hybrid/multi-cloud), without talking about Kubernetes.
Though just a few years old, Kubernetes already enjoys significant adoption. According to a Cloud Native Computing Foundation survey of 2,400 IT professionals, 83% of respondents use Kubernetes for container orchestration.
That result far outstrips alternatives such as Docker Swarm (21%) and Amazon ECS (24%).
This open-source container orchestration project is being touted as a universal platform or substrate for modern, cloud-native architectures.
Public cloud providers and enterprise IT vendors alike position Kubernetes as the control plane for cloud-native applications. They promise an application environment that will run on any public or private cloud, reducing cloud lock-in and enabling hybrid and multi-cloud designs.
In other words, Kubernetes is being hyped as a magic formula to abstract away the complexities of building, running, and managing cloud applications.
Want a multi-cloud strategy? Kubernetes.
Need to build apps to run on-premises and in public cloud? Kubernetes.
Want a floor wax and a dessert topping? Kubernetes!
Not so fast…
While Kubernetes has real potential, organizations that assume Kubernetes is the “easy button” for the cloud are likely to be disappointed. Here’s why:
1. Kubernetes Can’t Do Everything
A microservices architecture needs more than just container orchestration. Thus, an ecosystem of tools and projects are growing up around Kubernetes to address other domains.
For example, different application components or functions will need to communicate with one another, which has given rise to the notion of a service mesh. A service mesh provides capabilities that Kubernetes doesn’t, such as service discovery, access control and authentication, load balancing, monitoring and logging, routing, and so on.
Istio is a popular open-source service mesh, which itself uses Envoy, another open-source tool, as a proxy that sits between services.
Also witness the rise of Helm, an application package manager for Kubernetes designed to help developers define, install, and upgrade applications.
These and other software tools require their own care and feeding, including infrastructure to run them, updates and patches to maintain them, and training to operate them.
In other words, if you’re buying into Kubernetes, you’re also buying into a larger ecosystem of tools and requirements. Kubernetes doesn’t stand alone.
2. You Need To Skill Up
Speaking of training, Kubernetes isn’t something a developer masters over a weekend of hacking. If you’re building new containerized applications or refactoring existing applications, you’ll need to invest in training for developers and operations teams.
Unfortunately, many enterprises take a dim view of investing in their employees. They don’t like the cost, and they don’t want to train up staff just to see them defect to greener pastures.
If you’re hoping to embrace Kubernetes while skimping on staff skills, you’ll get what you pay for.
3. Cloud Evolves Quickly
Enterprises like operational consistency and uniform frameworks. Thus the appeal of Kubernetes as a common substrate for cloud applications.
However, while Kubernetes is today’s flavor, tomorrow it could be serverless/Functions as a Service. The next day it could be something entirely new.
The point is that cloud isn’t going to stand still. It’s unwise to plant your flag on a specific technology or platform and say “Let’s build our entire strategy around this and only this!”
4. Kubernetes Could Fail Or Fracture
Remember all the excitement around Hadoop? Or the hype about OpenStack? How did those turn out?
Popular open-source projects sometimes collapse under their own weight, or fail to live up to expectations. The same could happen with Kubernetes.
Even if Kubernetes thrives, individual vendors or cloud providers could fork or “embrace and extend” the code in ways that serve their own interests, while eroding core values such as application portability and uniformity of experience.
5. Don’t Forget Existing Applications
While you may be pouring resources into shiny new cloud-native applications, you’ve still got legacy (or ‘heritage’) systems you need to operate and support.
These heritage apps may be running on mainframes, in traditional three-tier architectures, or on VMs. You may have long-term plans to lift and shift or refactor these applications, but in the meantime, they’re still generating revenue and still require attention and investment. Kubernetes won’t help you with that.
We’ve Been Here Before
The cloud is disruptive. It creates new opportunities, but also new complexities and challenges. Enterprise IT has been here many times over.
The enterprise freaked out about BYOD.
And SaaS.
And opening port 80 on the firewall.
“How will I control it? What about security? What about my data? What about regulatory compliance? What about the cost and complexity?” Does this song sound familiar?
While cloud is going to be difficult to wrangle, enterprise IT can adapt. When you think about the cloud, you need to think about:
- What’s best for your applications
- What’s best for your customers
- What’s best for your IT competencies
- What’s best for your corporate culture
- What’s best for your bottom line
You’ll negotiate among these competing constituencies, just like you always have. Weigh the risks and opportunities, and then dive in. Perhaps Kubernetes will be a part of your strategy.
Just be wary of folks preaching Kubernetes as “The Solution.” It’s probably because they have something to sell you.
