Spring Cloud still shows up in every other résumé and job posting, but its content has changed radically: half of the jobs the project was created for have been taken over by the platform — Kubernetes. Let's go job by job: what used to be solved by libraries inside the application, what the platform solves now, and which parts of Spring Cloud remain alive and useful.
Where Spring Cloud came from
When microservices were spreading across virtual machines with no orchestrator, all the "network plumbing" had to live inside the applications: finding each other (Eureka), shared configuration (Config Server), load balancing (Ribbon), breaking failure chains (Hystrix), edge routing (Zuul). Spring Cloud packaged all of this into starters — and for its time it was the best answer available.
Kubernetes solves the same problems, but outside the application: a service doesn't have to know it is being balanced and restarted.
Job by job
| Job | Spring Cloud (classic) | Kubernetes |
|---|---|---|
| Find a neighboring service | Eureka + a client in every service | DNS: http://orders — the Service balances |
| Configuration | Config Server + a Git repo | ConfigMap / Secret mounted into the pod |
| Load balancing | Ribbon on the client | Service / kube-proxy, a mesh if needed |
| Edge routing | Zuul / Spring Cloud Gateway | Ingress / Gateway API |
| Restart on failure | — (by hand) | liveness / readiness probes |
| Zero-downtime rollout | — | rolling update out of the box |
How to read the table: if a job is infrastructural (who lives where, how config is delivered, how restarts happen) — it belongs to the platform. An application dragging Eureka and Config Server inside Kubernetes duplicates the platform and pays for it in complexity and memory.
What stays with the application
The platform doesn't see the meaning of requests — so the application-level jobs stayed with libraries:
- Client-side resilience: circuit breaker, retries with jitter, timeouts, bulkheads — that's Resilience4j (Hystrix has long been archived). The platform will restart a dead pod, but it won't decide for you whether to wait 30 seconds for a payment gateway.
- Distributed tracing: Micrometer Tracing (formerly Sleuth) — request context lives in code.
- API gateway as an application: Spring Cloud Gateway is alive and appropriate when the edge needs application logic — authorization, per-user rate limits, response aggregation. For pure routing, Ingress is enough.
- Feign / HTTP clients: declarative clients remain a code convenience; they no longer need discovery — they call DNS names.
A separate niche is the service mesh (Istio, Linkerd): mTLS, canary rollouts, network policies with no code changes. It is the next level of the platform approach, and it narrows the role of libraries even further.
How to choose
- You are on Kubernetes (the typical case): discovery, config, balancing, routing — the platform's. From Spring Cloud you take selectively: the Resilience4j integration, Gateway if you need an application-level edge. Eureka, Config Server, Ribbon, Hystrix, Zuul — do not start them.
- You have no orchestrator (VMs, own hosting): classic Spring Cloud still solves real problems — but the honest question is why there is no orchestrator.
- An inherited project with the full Netflix stack: it works — don't touch it for fashion's sake; migrate job by job as you move to Kubernetes.
In short
- Spring Cloud predates orchestrators and solved infrastructure problems inside the application; Kubernetes solves them outside.
- The platform took over: discovery (DNS), configuration (ConfigMap/Secret), balancing, edge routing, restarts and rollouts.
- The application keeps: circuit breakers and retries (Resilience4j), tracing, a gateway with application logic, declarative HTTP clients.
- Eureka, Config Server, Ribbon, Hystrix, Zuul in a new project on Kubernetes are a sign of copying old recipes.
- The service mesh moves the boundary further toward the platform — watch the boundary, not the fashion.
What to read next
- Kubernetes and graceful shutdown — how the platform manages a pod's life.
- Network reliability: timeouts and retries — the application side that remains yours.
- Monolith or microservices — whether your project needs this conversation at all.