Spring Cloud

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer's own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.

Quick Start
Fork me on GitHub

Spring Cloud builds on Spring Boot by providing a bunch of libraries that enhance the behaviour of an application when added to the classpath. You can take advantage of the basic default behaviour to get started really quickly, and then when you need to, you can configure or extend to create a custom solution.

Quick Start

The release train label (see below) is actually only used explicitly in one artifact: "spring-cloud-dependencies" (all the others have normal numeric release labels tied to their parent project). The depednencies POM is the one you can use as a BOM for dependency management. Example using the latest version with the config client and eureka (change the artifact ids to pull in other starters):


The recommended way to get started using spring-cloud in your project is with a dependency management system – the snippet below can be copied and pasted into your build. Need help? See our getting started guides on building with Maven and Gradle.


Spring Cloud focuses on providing good out of box experience for typical use cases and extensibility mechanism to cover others.

  • Distributed/versioned configuration
  • Service registration and discovery
  • Routing
  • Service-to-service calls
  • Load balancing
  • Circuit Breakers
  • Global locks
  • Leadership election and cluster state
  • Distributed messaging

Spring Cloud takes a very declarative approach, and often you get a lot of fetaures with just a classpath change and/or an annotation. Example application that is a discovery client:

public class Application {
	public static void main(String[] args) {
		SpringApplication.run(Application.class, args);

Main Projects

Release Trains

Spring Cloud is an umbrella project consisting of independent projects with, in principle, different release cadences. To manage the protfolio a BOM (Bill of Materials) is published with a curated set of dependencies on the individual project (see below). The release trains have names, not versions, to avoid confusion with the sub-projects. The names are an alphabetic sequence (so you can sort them chronologically) with names of London Tube stations ("Angel" is the first release, "Brixton" is the second). When point releases of the individual projects accumulate to a critical mass, or if there is a critical bug in one of them that needs to be available to everyone, the release train will push out "service releases" with names ending ".SRX", where "X" is a number.

Release train contents:

Component Angel.SR6 Brixton.RELEASE Brixton.BUILD-SNAPSHOT
spring-cloud-aws 1.0.4.RELEASE 1.1.0.RELEASE 1.1.1.BUILD-SNAPSHOT
spring-cloud-bus 1.0.3.RELEASE 1.1.0.RELEASE 1.1.1.BUILD-SNAPSHOT
spring-cloud-cli 1.0.6.RELEASE 1.1.0.RELEASE 1.1.1.BUILD-SNAPSHOT
spring-cloud-commons 1.0.5.RELEASE 1.1.0.RELEASE 1.1.1.BUILD-SNAPSHOT
spring-cloud-config 1.0.4.RELEASE 1.1.0.RELEASE 1.1.1.BUILD-SNAPSHOT
spring-cloud-netflix 1.0.7.RELEASE 1.1.0.RELEASE 1.1.1.BUILD-SNAPSHOT
spring-cloud-security 1.0.3.RELEASE 1.1.0.RELEASE 1.1.1.BUILD-SNAPSHOT
spring-cloud-starters 1.0.6.RELEASE    
spring-cloud-cloudfoundry   1.0.0.RELEASE 1.0.1.BUILD-SNAPSHOT
spring-cloud-cluster   1.0.0.RELEASE 1.0.1.BUILD-SNAPSHOT
spring-cloud-consul   1.0.0.RELEASE 1.0.1.BUILD-SNAPSHOT
spring-cloud-sleuth   1.0.0.RELEASE 1.0.1.BUILD-SNAPSHOT
spring-cloud-stream   1.0.0.RELEASE 1.0.1.BUILD-SNAPSHOT
spring-cloud-zookeeper   1.0.0.RELEASE 1.0.1.BUILD-SNAPSHOT
spring-boot 1.2.8.RELEASE 1.3.5.RELEASE 1.3.5.RELEASE
spring-cloud-stream-app-starters*     1.0.0.BUILD-SNAPSHOT
spring-cloud-task*     1.0.0.BUILD-SNAPSHOT

(*) These projects are not yet part of Brixton but they will be when they are released

The Angel release train builds on Spring Boot 1.2.x, and is incompatible in some areas with Spring Boot 1.3.x. Brixton builds on Spring Boot 1.3.x and is similarly incompatible with 1.2.x. Some libraries and most apps built on Angel will run fine on Brixton, but changes will be required anywhere that the OAuth2 features from spring-cloud-security 1.0.x are used (they were mostly moved to Spring Boot in 1.3.0).

Use your dependency management tools to control the version. If you are using Maven remember that the first version declared wins, so declare the BOMs in order, with the first one usually being the most recent (e.g. if you want to use Spring Boot 1.3.6 with Brixton.RELEASE, put the Boot BOM first). The same rule applies to Gradle if you use the Spring dependency management plugin.

NOTE: starting after Brixton.M4 the release train contains a spring-cloud-starter-dependencies as well as the spring-cloud-starter-parent. Use the parent as you would the spring-boot-starter-parent (if you are using Maven). If you only need dependency management, the "dependencies" version is a BOM-only version of the same thing (it just contains dependency management and no plugin declarations or direct references to Spring or Spring Boot). If you are using the Spring Boot parent POM, then you can use the BOM from Spring Cloud.