I’m pleased to announce the general availability release of Spring Cloud Services (SCS) 1.1, available for download from Pivotal Network. SCS provides application development and operations teams with production-grade coordination services for Cloud Native applications. SCS builds on the Spring Cloud project, which itself wraps a subset of the open-source components available from Netflix with the Spring programming model.
The 1.1 release makes it easier to operate the Spring Cloud managed services currently available within the Pivotal Cloud FoundryⓇ marketplace via SCS, consisting of a configuration server, a service registry, and a circuit breaker dashboard.
The release has four themes:
- Spring Cloud Brixton Release Train and Spring Boot 1.3.x Support
- Asynchronous Service Provisioning and Zero Downtime Upgrades/Updates
- Highly-Available Topologies for Config Server and Service Registry
- Enhancements to the Config Server Git Backend
Let’s summarize each of these themes.
Spring Cloud Brixton Release Train and Spring Boot 1.3.x Support
This is the most important theme of SCS 1.1. Application developers can now migrate their SCS applications to use the latest goodness available in both Spring Boot and Spring Cloud. The latest releases of these projects include major new features, enhancements, and fixes to the SCS 1.0.x baseline of Spring Cloud Angel and Spring Boot 1.2.x. In addition, Spring Cloud Brixton provides important upgrades to the Netflix OSS stack, which improve the stability and performance of both client applications and the SCS Service Registry and Circuit Breaker Dashboard.
Asynchronous Service Provisioning and Zero Downtime Upgrades/Updates
Pivotal Cloud Foundry 1.6 introduced support for asynchronous provisioning of service instances, providing a means for service broker authors to provision service instance infrastructure on demand. SCS has always provisioned dedicated service instances on demand, but was forced to do so using various workarounds for the synchronous provisioning API. SCS 1.1 now takes full advantage of the asynchronous provisioning API. This redesign makes it possible to fully script the process of creating SCS service instances and binding them to applications when they are ready.
An important enhancement to operability is the addition of zero-downtime upgrades and updates to SCS service instances. The Cloud Foundry Service Broker API supports an update operation for service instances, and SCS takes advantage of this operation to provide on-demand upgrades and configuration updates for service instances. A SCS system upgrade consists of two activities:
- Upgrades to the SCS tile via Pivotal Cloud Foundry® Operations Manager. These upgrades affect only the service broker infrastructure. After an upgrade completes, new service instances will be created with their latest available version.
- Upgrades to SCS service instances. After the tile upgrade completes, existing service instances are left untouched. The service instance owner (i.e. a space developer in the service instance’s space) must issue a service update command requesting an upgrade. The upgraded service instance will have its latest available version, and no application instances will suffer any downtime due to the upgrade (see the release notes for one exception for the Circuit Breaker Dashboard).
Additionally, service instances can be upgraded en masse via the SCS operator dashboard (see the upgrade documentation).
SCS service instances can also be reconfigured via the Service Broker API’s update operation. Supported reconfiguration includes changes to the Config Server’s Git backends and HA topologies (see below). These reconfiguration events are also executed such that no application instances will suffer any downtime due to the update.
Highly-Available Topologies for Config Server and Service Registry
SCS 1.0.x supported only single-node topologies for Config Server and Service Registry. While the self-healing capabilities of PCF’s container runtime minimized the effects of SCS service instance crashes, our customers wanted more. SCS 1.1 supports arbitrarily-scalable topologies for both Config Server and Service Registry. Users can provide a “count” argument when creating or updating either of these service instance types. The SCS service broker will then appropriately configure an HA topology with the corresponding number of nodes.
- Config Servers, due to their statelessness, are simply scaled horizontally via the Cloud Foundry API.
- Service Registries, which are based on Netflix OSS Eureka, are stateful components that replicate when clustered. The SCS service broker pushes the correct number of Eureka application instances and configures them for replication.
As stated previously, changes to HA configurations are executed such that no application instances will suffer any downtime.
Enhancements to the Config Server Git Backend
Finally, SCS 1.1 adds some frequently-requested enhancements to the Config Server’s Git backend:
- Config Server now supports all features of the Spring Cloud Brixton Git backend, including multiple repositories, pattern matching, and placeholders.
- Git repositories can now be accessed:
- using self-signed SSL certificates for HTTPS
- via a HTTP or HTTPS proxy server
- via the Git or SSH protocols (in addition to HTTP/HTTPS).
Download and Upgrade Now
Spring Cloud Services 1.1.1 is recommended to all customers for immediate upgrade of their production systems. Note that a CVE surfaced last week following the 1.1.0 release, and SCS has already been patched to address the vulnerability. For more information, please consult the following links:
- Download from Pivotal Network: https://network.pivotal.io/products/p-spring-cloud-services
- Detailed Release Notes: http://docs.pivotal.io/spring-cloud-services/release-notes.html
- User Documentation: http://docs.pivotal.io/spring-cloud-services/index.html
About the Author
