Spring Cloud Introduction

From one Spring Boot app to many#

A single Spring Boot application is straightforward to configure, deploy, and reason about. Once a system is split into multiple independently deployable services (see the Microservices vs Monolith tutorial in the System Design track for the trade-offs of making that split at all), a new set of problems appears that a single application never had to deal with:

• Where is configuration kept, when dozens of services each need database URLs, feature flags, and API keys — copy-pasted into every service's application.yml, or centralized somewhere?
• How does one service find another's network location, when instances are constantly starting, stopping, and being rescheduled by an orchestrator, so a fixed hostname/IP can't be hardcoded?
• What happens when a downstream service is slow or failing — does every caller hang, retry forever, and potentially crash along with it?

Spring Cloud is a family of libraries, built on top of Spring Boot, that address exactly these distributed-systems concerns with the same annotation-driven, convention-over-configuration style Spring Boot uses for a single application.

What Spring Cloud addresses#

Each of these maps directly onto a well-known distributed-systems problem — this track ties each Spring Cloud component back to the underlying concept it implements, rather than treating them as standalone tools to memorize.

A conceptual picture#

                     ┌───────────────────────┐
                     │   Config Server         │  <- every service pulls its config from here at startup
                     └───────────┬───────────┘
                                 │
        ┌────────────────────────┼────────────────────────┐
        │                        │                        │
┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│  Orders Service  │      │  Users Service   │      │ Payments Service │
└───────┬───────┘      └───────┬───────┘      └───────┬───────┘
        │  registers/discovers via  │                       │
        └────────────────> Service Registry <───────────────┘
                          (Eureka / Consul)
                                 ^
                                 │  "where is Payments right now?"
                     ┌───────────────────────┐
                     │      API Gateway         │  <- single entry point for external clients
                     └───────────────────────┘
                                 ^
                              Client

Config Server answers "what should I be configured with?"; the service registry answers "where is the service I need to call?"; the gateway answers "which internal service should this external request go to?"; and resilience patterns (covered in the last page of this track) answer "what do I do when the service I'm calling is struggling?"

Common mistakes#

• Reaching for Spring Cloud's distributed infrastructure before there's an actual multi-service system to manage — a single Spring Boot application has no need for service discovery or a config server at all.
• Treating each Spring Cloud component as an isolated tool to configure, rather than recognizing they're solving the same handful of recurring distributed-systems problems (config management, discovery, resilience) that come up regardless of which specific library implements them.
• Assuming Spring Cloud replaces the need to think about microservices trade-offs — it makes building a distributed system more manageable, not automatically the right architectural choice for a given team or product stage.