André Wlodkovski - Senior DevOps/Platform Engineer

Kubernetes is not the default.

It is a choice.

A powerful one — but still a choice.

In this series, we’ve discussed observability, availability, and cost. Now we step back and ask a more fundamental question:

Should this workload even be on Kubernetes?

The answer isn’t about popularity. It’s about trade-offs.

1️⃣ The CAP Theorem: Start With Distributed Systems Reality

Before comparing platforms, revisit fundamentals.

The CAP Theorem states that in the presence of a network partition, a distributed system can guarantee only two of:

Consistency — Every read receives the latest write.
Availability — Every request receives a non-error response.
Partition Tolerance — The system continues operating despite network failures.

All modern cloud systems assume partition tolerance.

That means every platform you choose must lean toward either:

Consistency (CP systems)
Availability (AP systems)

How Platform Models Tend to Lean

This is not about vendors — it’s about architectural bias:

Global serverless / event-driven platforms: tend to prioritize availability and partition tolerance. They are highly elastic and regionally distributed, but strict cross-region consistency is often complex.
Co-located container clusters: favor stronger consistency when services and databases are deployed within a tightly controlled network boundary.
Single-region or single-node systems: can achieve high consistency but sacrifice availability during failure events.

Your platform choice encodes your CAP preference.

That’s not a tooling decision. That’s a system design decision.

2️⃣ The Hidden Variable: Cognitive Load

Infrastructure decisions are not purely technical.

They are human.

Kubernetes introduces:

API surface area
Control plane management
CRDs and operators
Networking complexity
RBAC models
Upgrade lifecycles

This creates cognitive load.

A serverless model reduces operational surface area — but shifts complexity into:

Event modeling
Idempotency design
Distributed tracing
Execution constraints

Managed container platforms sit somewhere in between.

The real question:

What kind of engineers does your organization hire and retain more easily?

Platform engineers comfortable with cluster internals?

Application engineers who prefer abstraction?

Operational complexity is a real cost — even if it doesn’t show up on the cloud bill.

3️⃣ Operational Trade-Offs: A Neutral Comparison

Instead of asking “Which is better?”

Ask: “What is optimized?”

Dimension	Kubernetes	Managed Containers	Function-as-a-Service
Scaling Speed	Seconds	Seconds–Minutes	Milliseconds
Management Overhead	High	Medium	Low
Infrastructure Control	Full	Partial	Minimal
Portability	High (open ecosystem)	Moderate	Low
Networking Model	Service mesh / ingress	Simplified container networking	Event-driven / API-based
Workload Fit	Long-running services, stateful systems	Stateless services	Event-driven, bursty, short-lived
Cold Start Risk	None	None	Possible
Operational Surface Area	Large	Moderate	Small

This isn’t about superiority.

It’s about alignment.

4️⃣ When Kubernetes Is the Right Answer

Kubernetes shines when:

You operate long-running services.
You need fine-grained resource control.
You require portability across environments.
You run stateful workloads.
You operate at scale with platform engineering maturity.
You need advanced networking control.
You require custom controllers or operators.

Kubernetes becomes powerful when you treat it as a platform — not just a scheduler.

5️⃣ When Simpler Platforms Win

Simpler platforms shine when:

Workloads are event-driven.
Traffic is highly bursty with long idle periods.
You don’t need deep infrastructure customization.
You want minimal operational ownership.
Your team is small.
Speed of feature delivery matters more than infrastructure flexibility.

The most production-ready choice is often the simplest viable abstraction.

6️⃣ The Hybrid Reality

In practice, mature systems are rarely pure.

You often see:

Kubernetes running core APIs and stateful services.
Event-driven platforms handling background jobs.
Managed container services powering edge services.
Dedicated instances for performance-critical workloads.

This isn’t fragmentation.

It’s specialization.

Example pattern:

Kubernetes → core services, databases, internal APIs.
Event-driven platform → image processing, email notifications, data ingestion.
Provisioned instances → analytics engines.

The goal is not uniformity.

The goal is workload alignment.

7️⃣ Architecture Decision Records (ADRs): Engineering With Intent

An ADR (Architecture Decision Record) is a lightweight document that captures:

The decision made
The context
The alternatives considered
The trade-offs
The consequences

Example ADR topics:

Why we chose Kubernetes over managed containers.
Why we avoided serverless for core APIs.
Why we deployed multi-region.
Why we accept eventual consistency for analytics.

ADRs do three things:

Prevent emotional re-litigation of decisions.
Make trade-offs explicit.
Improve future architectural decisions.

Before your first kubectl apply, you should be able to answer:

Why Kubernetes?

If the answer is “because it’s standard,” that’s not architecture.

That’s habit.

8️⃣ The Strategic Question

Choosing Kubernetes means:

You are building a platform.

Choosing a more abstracted solution means:

You are buying a platform.

Both are valid.

But they imply different responsibilities.

9️⃣ A Practical Decision Framework

Before selecting a platform, ask:

What is the workload pattern? (Long-running vs event-driven)
What are the consistency requirements?
What is the recovery time objective?
What is the expected traffic volatility?
What skills does the team have?
What is the acceptable operational burden?
Is portability truly required?
What is the failure model?

If you cannot articulate these, you are not ready to choose a platform.

Conclusion: Tools Encode Trade-Offs

Kubernetes is powerful.

Serverless is powerful.

Managed containers are powerful.

None are universally superior.

Every abstraction encodes a bias.

The mature engineering move is not picking the most powerful tool.

It’s picking the tool whose trade-offs align with your system’s requirements and your organization’s capabilities.

Build products intentionally.

Build platforms only when you mean to.

Production-ready Kubernetes Series:

Production-ready Kubernetes Part 6 - Kubernetes vs. The Alternatives: An Architectural Decision Framework