Is Kubernetes overkill?
It’s a common enough question, especially since most midsized SaaS, web and eCommerce companies will one day decide to get off Heroku. (Everybody leaves Heroku eventually.) The decision is this – choose AWS, Docker Swarm or some other “simple” solution, or take a leap of faith and choose Kubernetes.
The migration from Heroku to AWS, Docker Swarm or a homegrown solution usually involves self-inflicted, avoidable migration wounds. That’s because these solutions look simpler than Kubernetes but always end up being more limiting, challenging and costly in the long run. There are no end of Heroku exit horror stories, yet many companies are hesitant to embrace Kubernetes. Let’s examine why.
One of the most common reasons small and midsized companies cite for not choosing Kubernetes has to do with scaling. “"I just have a Rails application,” a CTO might say, “and plain old EC2 VMs will give me what I need. Kubernetes is all about scaling. It’s too much – I don’t need to scale to infinity.”
Here’s the problem. No infrastructure needs to go from ten to thousands of nodes. (However, you do need at least two nodes because the reality is that apps can and will crash.) This scalability story is a red herring. Kubernetes isn’t just about scalability.
For starters, apps running on regular EC2 instances have no automatic restart if your Rails application runs out of memory and crashes; instead, someone gets paged in the middle of the night and has to restart it. Kubernetes, on the other hand, has automatic health checks, and if your Rails application fails to respond for any reason, including running out of memory or just locking up, Kubernetes automatically restarts it. Branch-based development environments are also easy with Kubernetes, but they’re near impossible with home grown EC2 automation.
Consider this – what might you accomplish with higher availability, autoscaling and a richer feature set?
Another common reason small and midsized companies don’t want to use Kubernetes? Complexity.
The truth is that Kubernetes is complex. It can be a challenge to get up and running – there’s no denying it. But this very complexity means that there’s an argument to be made in its favor.
In the 1960s, Fred Brooks wrote a seminal work in the field of computer science called The Mythical Man Month. In it, he discusses his team’s efforts to build the IBM mainframe OS/360, and he describes two kinds of system complexity: accidental and essential. Accidental is the kind that’s randomly introduced (the bad kind), and essential is the kind that’s necessary to get a job done (the good kind).
ECS and Docker Swarm seem simpler on the surface, but they both have more accidental complexity – and they foist that complexity onto you. This complexity isn’t obvious at the outset. So what exactly does accidental complexity look like? First and foremost, you need to compensate for what the system can’t do. For instance, ECS requires you to write a lot of code to make it usable (sometimes tens of thousands of lines of code). There are also structural limits to the way these tools work, and there’s a steep learning curve.
Kubernetes, in turn, has low accidental complexity and high essential complexity (the complexity needed to achieve the things you actually want to achieve). The power of Kubernetes is that it’s Google’s third generation of container management, whereas Swarm and ECS are in their first run.
Some companies are less worried about the complexity of Kubernetes than about the possibility that the complexity won’t pay off. They’re afraid their team will have to pay a Kubernetes “tax” and won’t get enough value to justify the overhead.
To avoid this “tax,” they hire a smart DevOps team and see what they come up with. Guess what? If you let them, they’ll build a Kubernetes-based platform. And if not, they’ll try to build something just like Kube from scratch (we call it "Fauxnetes"), which will leave the company with technical debt. (When you build it yourself, you always get a bug-ridden, more expensive version of Heroku. That’s the Tenth Rule of Cloud-based Infrastructure.)
Why deploy limited development resources to operations tasks when your goal is to build products? Why hire DevOps engineers if you don’t have to or go so far as to build your own Heroku? Find out in our next post: How to Make Your Developers Badass