Today’s post brought to you by an innocent sounding question in the Rands Leadership Slack (paraphrased):
I’m joining a company as their first Devops person and their infra needs a serious upgrade. The codebase is a monolith, but they want to pursue microservices, and if growth keeps on its path, that seems likely. I think I’m going to be allowed to dictate a better setup, but I’m currently having an existential crisis between going with ECS and K8s. I realize this is a huge question, but all things being equal: if you had the chance to start fresh, would you go towards K8s or ECS?
#devops channel, Rands Leadership Slack
I felt like that “step on the brakes” TikTok meme when I read this (you can google that, there’s no way I’m linking to it). This person is well meaning but it’s a question without necessary context — and a question I’ve seen asked by people who haven’t figured out the outcome and strategy they want in the first place!
As an aside, Kubernetes seems to be all the rage these days; and that’s OK. Beanie Babies were once cool too. But, much like Beanie Baby mania, some of the hype precedes the value, and let’s be clear: Kubernetes is not an outcome or strategy. It’s a tactic.
Let me explain.
When someone says, “Hey, you should adopt Kubernetes”, that’s skipping a few crucial steps. LIke, “What would buying all these beanie babies get me?”
Or
“Why do I even feel the need to buy beanie babies?”
So let’s start there.
What pain-points are you having with your current architecture and topology? Is it legitimate scaling issues? Is the database server experiencing timeouts due to high load? Are you writing the same data to multiple places and finding that you’re clogging up the pipes, as it were? Are users experiencing latency or are you having operational issues? Can your system handle the scale you need it to?
The answers to those questions will give you the idea of what outcomes you want to fix:
- Ensuring the database can handle OLAP and OLTP transactions without requiring a complete system rewrite
- Ensuring the database doesn’t timeout
- Improving the ability to increase resiliency and not lose data during high load times
- Ensuring the system can scale to 10x transactions per hour due to expected future load
Keep in mind, none of those outcomes specifies beanie babies or Kubernetes. Those are desired outcomes.
Next is strategy. What strategy will we use to achieve those outcomes?
Well, each outcome can be solved different ways; only one of those requires buying beanie babies (using Kubernetes).
For the Database; we could implement CQRS; we could add ETL process/data warehousing operations; we could improve the performance of our OLTP transactions so they aren’t blocking OLAP; we could implement a queuing mechanism, etc.
Break the system out into services and have those services communicate with each other through an event-driven architecture.
Those are strategies: they’re ways to solve the problem in an overarching fashion. Strategies don’t include implementations.
Next are tactics:
What tactics can we use to fulfill the chosen strategy?
That’s where Kubernetes comes in. It’s a tactic to a chosen strategy where your chosen strategy is: I want to implement micro-services but I don’t want to use a vendor-specific solution to orchestrate them.
Kinda feels like a self-licking ice cream cone when I put it like that, but alas.
So the next time you hear someone say, “We should adopt Kubernetes”, have them put on the brakes and talk you through the pain-points first, then the outcomes they want, then the strategy, and then if all of that works out, you can have the Kubernetes discussion.
Before deciding that you need Kubernetes, let’s talk about where you’re going, and what you want. What outcome do you want? What strategies are on the table? How will they achieve that outcome? How can they be measured?
Once you’ve done that work, then we can talk about which beanie babies you should buy.