Spring Cloud Services 2.0 is now generally available! Pivotal Cloud Foundry customers can download the bits and read the docs.
Spring Cloud Services 2.0 is built atop the latest major releases from the open-source Spring Boot and Spring Cloud projects. That’s right: along with the service broker, all of the server-side components provided by Spring Cloud Services–Config Server, Service Registry, and Circuit Breaker Dashboard–are now based on Spring Boot 2.0 and Spring Cloud Finchley. That means that each Spring Cloud Services component will work seamlessly with client applications written in or upgraded to Spring Boot 2.0.
What about backwards compatibility? We’ve got you covered.
The Spring Cloud Services client-side dependencies–the connectors used in a client application to interact with the Spring Cloud Services components–have also been updated. The two latest releases, 1.6 and 2.0, are compatible with Spring Boot 1.5.x and Spring Boot 2.0.x, and both are compatible with Spring Cloud Services 2.0. Choose the dependency version that works for your application now. Then, you can opt to upgrade your client applications to Spring Boot 2, or instead upgrade your Spring Cloud Services installation to 2.0 first. The choice is yours!
This is a big milestone for the product. We’re feeling nostalgic, so let’s take a look at how we got here.
Spring Cloud: From Netflix OSS to Your Modern Cloud Platform
The Spring team first launched Spring Cloud in March of 2015. The big idea was to expand on the power of Spring Boot, providing "tools for developers to quickly build some of the common patterns in distributed systems."
In their 1.0 release announcement, Spring Cloud's founders said:
"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."
Spring Cloud began by including the most crucial set of server and client components, including:
-
A configuration server that retrieves configuration properties stored in Git
-
A service registry, built using Netflix's Eureka
-
A dashboard for monitoring circuit breakers within microservices, built using Netflix's Hystrix Dashboard.
All of these services build on the foundation of Spring Boot. Creating a Spring Cloud configuration server, for example, is as simple as creating a new Boot application, adding a dependency to its build file, and then adding an annotation to its application class.
The Spring community eagerly adopted these components, and their popularity soared. Later in 2015, Pivotal commercialized these services with Spring Cloud Services for Pivotal Cloud Foundry (PCF). The suite of services was packaged as a tile, made available to operators of Pivotal Cloud Foundry.
Spring Cloud Services further boosts developer productivity and operator happiness: key servers from the Spring Cloud project are packaged, secured, and maintained by Pivotal as managed services in the PCF marketplace. The toil of deploying, patching, and updating a Spring Cloud server is done on the developers’ behalf, so that the power of these components is only a cf create-service away. Operators can rely on Pivotal to secure, provide, and maintain these services, fully integrated with Pivotal Cloud Foundry.
A Look Back at How Far We’ve Come
Spring Cloud Services 2.0 is a major milestone. In the spirit of reflection, let’s take a moment to recall some product highlights from the last few years, and how the Spring community helped us along the way.
The Service Instances Dashboard: Effortless Instance Management
To give operators a bird’s-eye view of Spring Cloud Services usage in the platforms they maintain, Spring Cloud Services 1.0.4 added a dashboard for service instances. This displays the org, space, and version of all service instances deployed on a PCF foundation, and links out to the dashboard for each service instance. Operators can also use the dashboard to upgrade service instances, individually or all at once, with the click of a button.
Zero-Downtime Upgrades: Painless Infrastructure Updates
Speaking of upgrades to service instances: after an operator installs an update to the Spring Cloud Services tile, the upgrades to each service instance don't incur downtime. The service broker uses a blue-green deployment strategy to upgrade the applications that back each service instance. Blue-green deploys are also used for the broker applications themselves, so you can freely update your microservice support infrastructure with zero interruption of service!
High Availability Modes: No Single Points of Failure
Now that your microservices have outsourced configuration properties to a centralized source and depend on a registry to connect to each other, what happens if one of these components goes down? Nothing, if you take advantage of the high-availability (HA) modes for Config Server and for Service Registry. At create time, you can specify the number of server applications that will back each service instance. You can scale up each of these services after creation, too–simply set the number of server applications using parameters given to cf update-service.
$ cf create-service p-service-registry standard my-service-registry -c '{"count": 2}'
$ cf update-service my-service-registry -c '{"count": 3}'
Proxy and Encryption Support for Config Server: Simple, Flexible, and Secure
If your environment requires an HTTP or HTTPS proxy for web access, you can easily set up the Config Server to comply. As of the 1.1.0 release of Spring Cloud Services, the Config Server can access Git repositories through a proxy configured using parameters given to cf create-service or cf update-service.
The Config Server can also use multiple protocols for accessing Git repositories: choose from Git, SSH, HTTPS, or HTTP. Need to protect sensitive property values while they’re stored in a central Git repository? The Config Server also can encrypt values, and then serve the encrypted configuration properties for decryption on the client side.
Service Registry Peer Replication: Service Discovery Across Data Centers
When your system spans multiple PCF foundations, how does a microservice in “PCF East” connect to a microservice running in “PCF West”? As of the 1.2.0 release, the Spring Cloud Services answer is: peer replication for the Service Registry! When you create or update a Service Registry, just specify the absolute URL of another Service Registry, whether it's in the same space or in a completely different foundation, as a "peer." Peer replication of registrations works across PCF foundations, availability zones, orgs, and spaces. Check out the detailed demonstration by Spring Cloud Services product manager Chris Sterling.
Config Server Support for HashiCorp Vault: Seamless Secrets Delivery
More sensitive application configuration demands strict control, audit ability, and highly-secure storage. To meet this requirement, Spring Cloud Services 1.4.0 added support for HashiCorp's popular secrets management tool, Vault, as a backend for the Config Server service. This support is already available to open-source Spring Cloud Config, and is now built into the tile's Config Server service with all of the same operational and security benefits of the rest of Spring Cloud Services. Just add a Vault server.
Config Server Composite Backend: the Right Repository for the Right Job
What if you have applications that must consume configuration properties from one or more Git repositories and a Vault server? Spring Cloud Services supports a declarative composite backend for the Config Server. For each service instance, you can easily add multiple Git repositories and your Vault to the mix of configuration sources. When a client application makes a request to the Config Server, the Config Server sends back a unified set of all properties available to that client, sorting by the order in which each configuration source was declared in the Config Server's settings. This makes it possible for you to set the priority of configuration sources.
See the blog post giving background on using Vault and a composite backend with Config Server.
CredHub Integration: Platform-Level Credential Management
CredHub stores and manages the lifecycle of credentials used throughout Cloud Foundry. Using the Spring CredHub project, the 1.5.0 release of Spring Cloud Services can use CredHub to secure service instance credentials. Operators can enable this support to have the service broker store credentials for each service instance in the Pivotal Application Service (PAS) Runtime CredHub (this support requires PAS 2.0 or later). Expect to see further integration with CredHub in future Spring Cloud Services releases!
Upgrade Today – and See You at SpringOne Platform!
All of this goodness is now updated for Spring Boot 2.0 and made using the latest Spring Cloud. Ready to lead your microservices into the cloud-laden springtime of a Boot 2 future? Download Spring Cloud Services 2.0 today!
For more information about the release, see the documentation at the links below. Better yet, join us at SpringOne Platform in Washington, D.C., September 24 to 27, 2018. Register now! Use discount code S1P200_JLong for $200 off the registration fee.
Spring Cloud Services Documentation Home
