31 · Cloud Native and Deployment Platform Selection

The thesis in one line: cloud native is not "use Kubernetes." It is the ability to make deployment, scaling, rollback, observability, and failure recovery repeatable. Deployment platform selection asks whether your team should pay that complexity cost right now.

🧰 Technology Stack Selection Track, Chapter 5 · One thing to practice
Chapter 30 covered how services communicate. This chapter goes one layer down: where services run, how they are released, scaled, rolled back, and operated. Small systems need less to worry about. Large systems need control and autonomy. The wrong platform taxes you every day.

Opening: you are choosing an operating model

Beginners ask:

   VM or container?
   Serverless or Kubernetes?
   Self-hosted or cloud?

Architects ask:

Who owns releases?
Who owns scaling?
Who owns alerts?
Who can roll back a broken version?
Who manages secrets, config, certificates, logs, metrics, permissions?
Can the team understand the platform during an incident?

A deployment platform is the whole path from code to online service: build, config, secrets, release, health check, traffic switch, autoscaling, logs, metrics, rollback.

Rule of thumb: the more convenient a platform is, the less control you usually have and the more vendor lock-in you may accept. The more control you want, the more operations capability you need.

1. Four steps, not a maturity ranking

   PaaS / managed app platform
      -> easiest, good for MVP / small teams / standard web apps

   Managed containers
      -> still simple, but with containers and service boundaries

   Serverless
      -> good for event-driven work, bursty traffic, background tasks

   Kubernetes / K8s
      -> strongest control plane, highest platform burden

Do not read this as "later is better." A three-person team shipping steadily on PaaS is healthier than a team constantly repairing a cluster it did not need. But if you have dozens of services, multiple teams, and complex traffic management, a very simple platform can become the bottleneck.

Architectural wisdom: choosing a platform is like choosing transport. A bicycle is best for a nearby errand; a truck is best for moving house. The question is not whether a truck is more advanced. The question is whether you are moving house.

2. When Kubernetes is worth it

Kubernetes does not merely "run containers." It manages many changing containers:

Scheduling.
Autoscaling.
Service discovery.
Rolling releases.
Self-healing.
Resource isolation.
Declarative configuration.

Good signals:

Signal	Meaning
Many services	Need unified scheduling, release, resource governance
Multiple teams deploy independently	Teams cannot queue behind each other
Complex traffic control	Canary, blue-green, region routing are normal
Hybrid/private deployment	Need a portable deployment model
Platform team exists	Someone turns K8s into an internal developer platform

If you have one standard web app, one database, and one queue, K8s is often burden, not benefit. You buy certificates, ingress, network policy, image registry, cluster upgrades, access control, node resources, and observability all at once.

3. Serverless changes the constraints

Serverless is valuable because:

It scales on demand.
It fits event triggers: file upload, scheduled tasks, webhook handling.
The team manages less infrastructure.

Costs:

Cold start.
Runtime, memory, timeout, package-size limits.
Harder local debugging and observability.
Stronger vendor binding.

Serverless fits short, scattered, event-driven work. It does not fit everything. Splitting a complex long workflow into dozens of functions without workflow orchestration, tracing, and retry discipline creates another kind of unmaintainability.

4. Deployment strategy is architecture

Do not only ask "can it run?" Ask what happens when a bad version ships:

Capability	Question
Health check	How does the platform know an instance can receive traffic?
Rollback	Can you quickly return to the previous version?
Progressive delivery	Canary, blue-green, gradual traffic shift?
Config and secrets	Are config, passwords, and certs separated from code and auditable?
Infrastructure as Code	Are resources versioned, reviewed, and rebuildable?

GitOps matters because it turns "what production should look like" from manual console clicking into versioned, reviewable, revertible declarations. For a small team this might be one config file. For a larger org, it becomes the platform engineering golden path.

5. A steady evolution path

   MVP / monolith:
      managed app platform + managed database + simple CI/CD

   multiple services:
      containers + managed container platform + standard logs/metrics/secrets

   multiple teams:
      managed K8s + platform team + GitOps + service catalog + permission governance

   regulated / private / hybrid cloud:
      K8s or private platform, with higher ops cost accepted

This is the same restraint as Chapter 04's "monolith first" and Chapter 15's platform engineering: let the business run first, then turn repeated operational complexity into platform capability.

6. Selection table

Signal	Better choice	Why	Watch out
1-5 people, MVP, standard web app	PaaS / managed app platform	Low ops, short release path	Less control, migration cost
Few services, need environment consistency	Managed containers	Container consistency without full K8s burden	Still need images, config, logs, health checks
Many services, many teams	Managed Kubernetes	Unified scheduling, scaling, release, isolation	Without platform team, business teams absorb complexity
Event-driven or bursty background tasks	Serverless + queue	On-demand scaling, no long-running servers	Cold start, limits, observability, vendor lock-in
Regulated/private/hybrid cloud	Private cloud / self-managed K8s	Data boundary, compliance, portability	Highest ops cost

🎯 Quick check

🤔A 4-person team is building its first SaaS MVP: one backend, one frontend, one database. They want self-managed Kubernetes because future scale is likely. What is the best judgment?

AUse self-managed Kubernetes immediately; earlier is more professional
BPrefer PaaS or managed containers, get releases/logs/backups working first, and reassess managed K8s when service count, team count, and independent deploy needs appear
CNever deploy to cloud; buy physical machines

🤔When evaluating a deployment platform, what should you ask first?

AWhether it is fashionable and has a nice logo
BWhether it supports health checks, rollback, progressive delivery, config/secrets management, logs/metrics, and whether the team can operate its complexity
CWhether it eliminates the need to write tests

Chapter summary

Cloud native is not a tool list: it is automation, elasticity, recovery, observability, repeatable release.
Deployment platform selects an operating model: convenience vs control, simplicity vs governance.
Kubernetes is not the default: it fits multi-service, multi-team, complex governance.
Deployment strategy is architecture: health checks, rollback, canary, secrets, IaC/GitOps decide incident recovery.
Start simple, upgrade on signals: managed first, then containers, then platform.

Next: deployment platforms make systems run and roll back. Chapter 32 adds the other half: can you see, alert, and recover?

Method core: 04 · Core patterns · 06 · Quality attributes · 12 · Designing for failure
Organization: 15 · Organization as architecture · 24 · Review checklist
Cases: PatchDesk · CodePilot

31 · Cloud Native and Deployment Platform Selection ​

Opening: you are choosing an operating model ​

1. Four steps, not a maturity ranking ​

2. When Kubernetes is worth it ​

3. Serverless changes the constraints ​

4. Deployment strategy is architecture ​

5. A steady evolution path ​

6. Selection table ​

🎯 Quick check ​

Chapter summary ​

Related links ​

💬 Comments