People often think of Kubernetes as “the microservice platform.” That’s true, but incomplete. Kubernetes hands you an orchestration plane; what actually makes a microservice succeed is service boundaries, traffic management, observability, and operational discipline.
In this post I’ll walk through the decision points that cause the most pain in the field when building a microservice architecture on Kubernetes: things like “where does a service end?”, “how do you define an SLO?”, “what should the platform team standardize?“.
1) Service boundary: not a deployment unit, but a domain boundary
The most common mistake: defining a microservice as “a separately deployable piece” and drawing the boundary along the technical layer.
A practical definition:
- A microservice owns a single business capability
- It manages its own data (or at least ownership is clear)
- It is operated against its own SLO
2) Minimum platform components: without standardization, mess scales up
For a from-scratch setup, the “minimum platform” set:
- Ingress/Gateway (L7 entry)
- Config/Secret management
- Observability (log/metric/trace)
- CI/CD + artifact registry
- Policy/guardrail (PSA + OPA/Kyverno)
If the platform team templates these, service teams stay focused on “the work.”
3) Traffic management: timeouts and retries decide each service’s fate
The most frequent root cause in distributed traffic: the wrong timeout/retry.
Minimum safe defaults:
- Timeout on every call
- Retry budget + backoff
- Outlier detection / circuit breaker (at least at the edge)
- Rate limit (public and critical internal services)
In the mesh vs no-mesh debate, what matters is the consistency of these policies.
4) SLO and error budget: the measurement that makes a microservice real
Saying “it’s working” really means “it’s within SLO”:
- Availability
- Latency (p95/p99)
- Error rate
If the error budget is being burned, deploys slow down; if the budget is healthy, you speed up. Without that rhythm, microservices turn into “many parts, many problems.”
5) Kubernetes primitives: enforce the guardrails
My minimum template items:
- Resource requests/limits
- Liveness/readiness probe
- PDB (on critical services)
- HPA (with the right metric)
runAsNonRoot,readOnlyRootFilesystem, capabilities drop- Multi-AZ spread
Conclusion
Kubernetes makes microservices possible; but success comes from platform design. When you draw the service boundary along the domain and settle the traffic/SLO/guardrail standard, microservices truly scale.