As the last hours of 2020 fade into the history books, I’d like to get this off my chest.
For context, I’ve only deployed one production application on Kubernetes. And that deployment was, by any measure, a success. There were a few head-scratching moments, but for the most part everything Just Worked™. But that doesn’t make me a fan, and this is why:
Kubernetes is not Cloud-native.
Or, phrased in a slightly less contentious way:
Kubernetes manages my infrastructure, but I still need to have deep knowledge of everything that I deploy on it.
You may be saying “duh,” but let’s look at what that means with a typical web-application. Whether it’s a micro-service or a monolith, enterprise-internal or public-facing, every web-application has the following components:
- A front-end web-server, used to serve static content, terminate SSL, and present a (hopefully) hardened face to the open Internet.
- An application server, that contains your business logic and the database queries that support it.
- A database server.
And here’s the problem: each of these components requires specialized knowledge to set up and operate. Or at least to operate well. Sure, anybody can do the basics: there are plenty of tutorials on how to configure nginx; the developers of your web-application probably already run it with an embedded Jetty container; and you can start up a Postgres database container with a single command. A few hours to get a basic understanding of Kubernetes, and you should be able to deploy your web-application.
And most likely, everything will work. Until it doesn’t. The database is the weakest link: are you regularly backing up the persistent volume(s) where it stores data? Have you rehearsed the process of recovering from database failure? How long does it take to come back from failure?
These are all questions that you would have to answer if your were running Postgres in your own data center. But in a “cloud native” deployment, you don’t have to manage your own Postgres server. Instead, you use a managed server that automatically handles its own backups, and lets you recover with a few clicks. That lets you easily turn on replication so that you can scale out read-only workloads. That lets you increase the CPU or memory available, without taking the time to figure out if you have a node available that can support the new size.
And, sure, you can use a managed database and run the rest of your application inside Kubernetes. That’s what we did for the project that I mentioned earlier. And you can replace the front-end web-server as well.
But at that point, what are you really getting from Kubernetes?