Do not run Kubernetes only because your customer will do

Published August 15, 2024

If you ship code to enterprise customers, if you have SaaS that you sell on-prem, you will hear about things like:

Avoid to run your software in Kubernetes if you are not ready to handle the complexity, if you run it yourself or the cost if you will run on Autopilot or managed by some partners.

If you adopt it too early you will spend hours dealing with Kubernetes instead of improving the operational experience on your solution.

When you target enterprise customers they are already burning CPUs with their own self-hosted solutions so it means people with opinions about how the software should run. It is impossible to predict how strong those opinions will be.

This is a testing exercise, if you decide that your code needs to run on EC2 create a testsuite that validates that. If you live in today ERA you know that software that runs in containers can be shipped to Kubernetes. Provide that but nothing more until you see some enterprise coming your way.

Kubernetes is great, and most likely somebody will ask for an HELM chart that they can apply, but it is work that is nice to do with a serious commitment at the other side.

This is valid if you do NOT want to onboard Kubernetes to soon, if that’s not a concern remember that shipping an enterprise distribution of your software to Kubernetes may not look like the one you use for yourself or for your SaaS.

In your own environment you want flexibility, the ability to try new configuration and to early validate that a new feature works as expected. When you prepare the packaging that a customer will install by itself you want stability, clarity, and probably not that much flexibility otherwise figuring out what does not work will be pretty hard.

Packaging is a feature and like any other feature it requirements, spec, testing and release. Putting together an enterprise offer is a challenge that I don’t think get easier if you run your code in Kubernetes.

Are you having trouble figuring out your way to building automation, release and troubleshoot your software? Let's get actionables lessons learned straight to you via email.