Choosing your future
How to select a development approach for an upgrade project.
The Kubernetes Matrix: Red Pill or Blue Pill?
· 7 min read
The Red Pill and Blue Pill
If you haven't seen The Matrix, watch it. It's worth it.
The Matrix is a sci-fi action movie about a hacker named Neo who learns that reality is a simulation run by machines. With Morpheus and Trinity, he struggles to free humans from this illusion. However, he must first make a crucial decision:
Blue pill: comfortable illusion. Red pill: uncomfortable reality.
So what does this have to do with Kubernetes? Picking Kubernetes is the same kind of choice.
| Take the Blue Pill if you think | Take the Red Pill if you think |
|---|---|
| Kubernetes solves all my problems. | Kubernetes is very powerful but adds complexity, which is not necessary for current requirements. Let's start simple. |
| It's the future - all big companies use it. | Big companies have big problems and big teams. Your team with 5 developers has different needs than Google. |
| No vendor lock-in - we stay flexible. | You trade cloud vendor lock-in for Kubernetes ecosystem lock-in. Plus managed k8s still ties you to a provider. |
| We need it to stay competitive. | Competitive advantage comes from solving customer problems, not from adopting the latest technology hype. |
| It scales infinitely. | It can scale, but you need the team, monitoring, and infrastructure to support it. And this is not cheap. |
| DevOps will be so much easier. | DevOps becomes more complex. You need specialized knowledge and significantly more operational overhead. |
Which one do you pick?
Kelsey Hightower, aka Morpheus of Kubernetes
Kelsey Hightower is one of the few Kubernetes voices worth listening to. He calls out teams running Kubernetes when they don't need it.
Kelsey is the Morpheus of Kubernetes. He has been trying to wake people up to the real trade-offs for years. He talks about the costs and challenges, not just the benefits. Like Morpheus, he does not force you to take the red pill. He lays out the facts. If you want the blue pill, stay in the world of Kubernetes hype. Pick the red pill and get ready for the rabbit hole of Kubernetes complexity.
The Matrix of Kubernetes Complexity
What You See
Remember the blonde woman in the red dress? In the training program, Morpheus shows Neo a simulation of a city. Neo is supposed to focus on the training, but he gets distracted by the woman in the red dress. A second later, she turns into an agent and tries to kill him.
She was a distraction. Distractions are everywhere, not just in the Matrix. Go to a conference, read a blog, or watch a Kubernetes video. You will see all the cool features:
- auto-scaling,
- self-healing,
- service discovery and load balancing,
- automated rollouts and rollbacks,
- extensible API and ecosystem,
- and much more.
If you are lucky, someone will actually explain why they picked Kubernetes. Most of the time, it is not clear what problem they were solving, or if Kubernetes was just the shiny new thing. You see a demo: a simple app, a few lines of YAML, and it looks like magic. You think this looks great. Maybe you want it for your company. Maybe you want it on your CV.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: my-app:1.0
Looks simple, right?
What You Don't See
Kubernetes is an abstraction layer that hides much of the complexity.
So what is all this complexity people keep warning about?
Depending on your role in the organization, you will face different challenges and trade-offs when adopting Kubernetes.
Developers
As a developer, you might see Kubernetes as a way to deploy and manage your applications easily. You can define your application declaratively using YAML and let Kubernetes manage the rest.
However, you might miss:
- Logging & debugging: When something goes wrong, it can be difficult to figure out what happened and how to fix it.
- Container basics: write Dockerfiles, build and tag images, run containers locally, multi-stage builds, tools like Docker, Podman, Rancher
- Pods vs. Deployments: Rolling updates, Replica Sets, Scaling, Rollbacks
- Configuration management: ConfigMaps & Secrets, Environments
- Health Checks: Liveness Probe vs Readiness Probe
- YAML: Write and read ;)
- Templating: Helm, Go Templating, Kustomize
You might not see the learning curve. It takes real time and effort to learn Kubernetes well enough to run your apps.
Operations team (SRE / Security / DevOps / DevSecOps / Ops)
As an operations team, you might see Kubernetes as a single tool for managing your cluster at scale. You can automate deployments, scaling, and management. Bring some standardization, monitoring, and self-healing capabilities.
However, you might miss:
- Security compliance: auditing, rbac, network policies
- Cost control: over-provisioning
- Maintenance: upgrades and maintenance of nodes
- Operational overhead: You might need a full-time engineer to keep clusters and core services running. Some teams spend 10 to 30 hours per cluster per month on basic maintenance. That does not include upgrades or unexpected incidents. Costs add up fast with management tools, cloud resources, and on-call. One incident or upgrade can eat days.
Architects
As an architect, you might see Kubernetes as a way to gain flexibility, scalability, and availability, along with a rich ecosystem. You may see a way to reduce the vendor lock-in. Or you want to run a Netflix microservice architecture reliably.
However, you might miss:
- Vendor lock-in: Yes, Kubernetes allows you to port your containerized apps. Based on our experience, you cannot easily move from one hyperscaler to another. The YAML files for your apps will not change, but the cluster setup will. Your knowledge, contracts, and ecosystem lock you in. Read more about vendor lock-in here (German).
- Operational burden and skilled teams
- Security and compliance complexity
- Not all workloads fit: legacy apps or stateful workloads are challenging
Customers
What do customers see? They do not see Kubernetes at all. They only see the product or service you deliver. They do not notice when your app runs flawlessly. That is expected. They notice when something does not work, when prices are higher, when response times are long, when there are downtimes, or when it takes too long to deliver a feature or fix a bug.
Every technical decision, Kubernetes included, should be measured against the value and impact delivered to customers. If you are delivering value to customers, it does not matter what tech stack you use.
Evolution of your architecture
When you start a new project or product, you usually start with understanding the problem you want to solve and building a minimum viable product. For that, you first need to understand your customers, their needs, and how to deliver value to them. You need to understand the constraints you have and how to work within them. You need to understand the quality attributes that are important for your product, and how to achieve them.
Let me give you an example of what I mean by constraints and quality attributes:
- Examples for constraints are:
- limited budget,
- limited time,
- limited team size,
- limited expertise,
- governance and compliance requirements,
- etc.
- Examples for quality attributes are:
- performance,
- reliability,
- security,
- maintainability,
- … and many more.
- Understand the sandbox When you understand the sandbox (constraints and quality requirements) you are playing in, you can select the right tools and technologies to start building your solution.
- Simplest and most boring architecture Build the simplest, most boring architecture that delivers value. Ignore what the cool kids are doing. Focus on your customers.
- Get feedback from your stakeholders Show your architecture to stakeholders, get feedback, and adapt if needed. Do not over-engineer. Keep it simple. Your architecture survived feedback? Great. Start building and deliver value to your customers.
- Repeat
I like to compare it with the following: Your kid is excited to learn how to ride a bike. You can give them a bike with training wheels, which is simple and safe. Or you can give them a BMX bike with no training wheels, which is more complex and risky. Or worse, you can give them a motorcycle, which is way too complex and dangerous for a kid learning to ride a bike. You would not give your kid a motorcycle to learn to ride a bike. You start with training wheels, then take them off when they are ready.
Same goes for your architecture. If your team is not ready for Kubernetes, do not use it. Start with something simple and manageable. Evolve as you grow.
The Blue Pill
Kubernetes is powerful. It can help you manage and orchestrate containers at scale. So what are the reasons to go for Kubernetes:
Hybrid- and multi-cloud strategies
Kubernetes provides a consistent platform that allows you to run workloads seamlessly across on-premises data centers and multiple cloud providers, making migrations or workload balancing between environments far simpler and less risky. But be aware of the multi-cloud complexity.
Compliance
Kubernetes helps you meet strict regulatory or data residency requirements. Especially when certain workloads must remain on-premises or within specific jurisdictions.
Company standards and know-how
When Kubernetes is already established as a company-wide standard, your teams benefit from shared tooling, operational processes, and expertise, resulting in increased efficiency, smoother onboarding, and reduced friction across projects and departments.
The problem is not Kubernetes. The problem is picking it for the wrong reasons.
Conclusion: Choose Your Reality
This is not just about Kubernetes. The same trade-offs show up with any tech choice: microservices vs. monoliths, SQL vs. NoSQL, cloud vs. on-prem. Be honest about your needs and constraints. Do not fall for hype. Do not adopt complex solutions before you need them.
If you still want to learn it the hard way, try Kubernetes the Hard Way by Kelsey Hightower.
Further Reading
- Kelsey Hightower - Kubernetes the Hard Way
- Woman in the red dress
- Azure: decide what to take for your compute solution
- Design Principle: Simplify
- Vendor Lock-In oder was kostet die Freiheit? (German)
- Don't get locked up into avoiding vendor lock-in
What's your reality? Are you picking the red pill or the blue pill? What surprised you most after adopting or rejecting Kubernetes? Did you run into any unexpected wins or challenges? Let’s hear your experiences.
