Top 5 reasons not to use Kubernetes

I decided to do a quite different listicle today. Everyone and their mom are talking about Kubernetes, containers and why you should be using them. How about flipping the tables? Why shouldn’t someone NOT use Kuberentes?

1. You don’t know Kubernetes #

Dead simple. Pods, replicas, daemonsets, ingress, storage, version upgrades, blue green deployments. Oh my! The very thought of wrapping my brains around so many concepts seems daunting. Why can’t things be simpler? Can’t I just SFTP my code and head home? I get it. Kubernetes is not for everyone. In fact, this argument applies to any shiny new technology.

Just because Kubernetes is all the rage, doesn’t mean I have to learn it and use it somehow.

The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

— George Bernard Shaw

2. Your team doesn’t know Kubernetes #

Now, this one’s slightly different. You might drink the kubernetes Kool-aid, but some of your teammates will beg to differ. It’s not for everyone. Unfortunately, team dynamics doesn’t play out in your favour. We can’t move our infra to Kubernetes just because you gave a great talk about Kubernetes in the previous brown-bag session. Maybe next quarter.

3. Your application doesn’t need Kubernetes #

If you’re running simple blog in Wordpress, go and deploy it at a shared host. They give you lot of bells and whistles, like cpanel. I’d never touch Kubernetes with a 10-foot pole if I were in that situation. Nothing wrong with using plain, simple, classic VMs to deploy your applications.

4. You don’t use the cloud #

If you are running applications on legacy platforms, not migrating to the cloud due to business constraints, compliance etc, then you’re under no pressure to adopt Kubernetes. A closely related subset is teams who stick to a single cloud provider. These teams, for example, use reserved instances, deploy using AWS elastic beanstalk and monitor using Cloudwatch. Again, nothing wrong with this approach.

4. You’re already using a platform #

If you’re already using a platform like Heroku or Platform.sh and happy with that, I’d highly recommend you continue to use it. There are a lot of platforms which are optimised for your stack.

The takeaway here is, you shouldn’t be using Kubernetes unless there is a real need to do so. You are better off burning your dev cycles on building a CD pipeline for your team. What qualifies “real need”? You may ask. If any of these boxes tick for you, consider Kubernetes.

• Deploying a large fleet of applications in the cloud, which you want to autoscale, manage and frequently deploy.
• You’re running mostly stateless services which talk to each other.
• You’re already using containers in production, but haven’t jumped ship yet.
• You need high degree of resilience and redundancy.