To K8s or not to K8s
There's a lot of debate on whether early-stage startups should use Kubernetes or not. These are my thoughts on the subject.
As a CTO of an early-stage startup, I've seen my fair share of debates around whether to adopt Kubernetes (K8s) or not. There's a lot of noise out there, with many claiming that K8s is an overkill and advocating for simpler solutions like AWS + ECS.
However, comparing K8s (as deployed by large companies with complex setups) to ECS is like comparing apples to oranges.
Not all K8s setups need to be complex. The perception that ECS is easy while K8s is difficult is misleading. When starting from scratch, you'll need to put in effort to learn both. Sure, K8s might require a tad more effort initially, but in the long run, you'll be thankful you started with it. A lot of growing organizations are adopting K8s, and it's not for no reason. It's a necessary devil.
I acknowledge that Kubernetes is hard. And the documentation is overwhelming. You have to do some hard work upfront. But this complexity stems from its versatility – you can deploy almost any type of workload on K8s. It's like a Swiss Army knife – packed with tools for every occasion, but you don't need to use them all at once.
People have built vast, intricate systems on K8s, but you don't need to go that far. While everything is possible on K8s, you don't need to add that much complexity from the get-go. For simple applications, you don't need to leverage complex and nuanced K8s features.
Minimum Viable Kubernetes
The key is to define what's necessary and what's unnecessary complexity. Take a step back and define your "Minimum Viable Kubernetes" (MVK) – the minimum set of components and configurations required to meet your core needs reliably and efficiently. Do you need namespaces and permissions for every pod? Do you need to be available 99.999% of the time? Do you need a complex observability setup? Choose your battles carefully.
Use a simple Deployment instead of a complicated StatefulSet. Use Node Port services instead of setting up an Ingress controller. Don't create custom ResourceDefinitions; stick to the built-in resources like Pods, Services, and Deployments. Use a hosted solution like EKS or GKE instead of installing every component like networking, storage, and logging yourself.
In my current startup, we started with K8s from the get-go – with a very simple setup. We didn't add namespaces or permissions on pod levels because that wasn't needed. But as our software scaled, K8s scaled beautifully with it.
That all said, why bother with K8s in the first place?
Coz It’s flexible. It’s scalable.
First, you have the entire flexibility. You don't get locked in. And later, when the time comes to be cloud portable, it doesn't become a six-month-long project. This flexibility provides a business advantage. When you're cloud-flexible, you gain a competitive edge.
To illustrate, I once worked at a company heavily tied down to AWS. One of our enterprise clients didn't want to use AWS, and we lost the deal because moving to another cloud for that customer would have been a 3-4 month effort, at least.
A K8s setup also scales with you beautifully. Whether you want to add more services, need better networking, or need to launch in multiple geographies. It won’t be a hassle.
And it's easier to hire people later to manage complex setups than to move to K8s when you have a massive cloud footprint. If you don't want to hire, there are many tools in this space that help you manage K8s easily, at a fraction of the cost of a DevOps engineer.
In conclusion, Kubernetes is evolved, and it can be easy if you make it so. Start on K8s – it's a necessary devil. Embrace its complexity judiciously, and get a competitive advantage as your startup grows.
You can follow me on Twitter (X) as I continue to write more on K8s, DevOps, and Platform Engineering and document my startup journey.