Spring Cloud was created to facilitate the development, configuration and operation of distributed systems. The features implemented in Spring Cloud abstract the complexity of distributed systems and reduce the amount of boilerplate code you need to write.
In this post I describe five Spring Cloud capabilities that you might not be aware of. The features in this post are geared towards cloud native applications and and some of them to Kubernetes.
SpringOne Platform (S1P)
While there is still time to register, we’re just a few weeks from SpringOne Platform 2018, the best and largest event on Spring technologies. In this post I also highlight sessions at the event that align with the given topics. SpringOne Platform is a must attend event for Spring developers. Register today with discount code S1P200_DRettori and get $200 off!
1. Spring Cloud Config with Hashicorp Vault as Backend and CredHub
Versioning source code is really a given today. I can’t imagine how much work we would have to do if we didn’t know what version of our code we’re running. Just think about bug fixing, security and compliance to start. Yes, there is a lot of value in versioning source code. And if you’re doing container (read: docker)-based deployments, versioning, and packaging all the dependencies neatly together certainly brings some comfort in knowing that rollbacks can be less painful.
Sometimes I think that if we are going to be honest with ourselves, we often miss taking care of the application configuration the same way we do with the application code and this is why I love Spring Cloud Config. With Spring Cloud Config your applications can get configuration from an external trusted application, the Spring Cloud Config server.
Vault as backend
Vault is a tool to store and manage access to secrets. A secret is simply a piece of data that you want to securely store and retrieve. A secret could be a sensitive url, a password or a certificate. It’s safe to say that Vault is an appealing choice for storing secrets.
Vault has become popular with container-based deployments especially due to its integration with Kubernetes.
If you’re currently running your Spring Boot apps with the Cloud Config server, then you can just tell the Config server to use Vault as a backend (see example above). So If you already trust Vault for your secrets and other sensitive information, you can easily continue using it with Spring Cloud Config.
CredHub
CredHub goes beyond Vault in that is also creates and performs lifecycle management of certificates. While it was initially created to facilitate credential management for Cloud Foundry users, it can also effectively perform that function for Kubernetes environments.
The project Spring CredHub is the recommended option for integrating with CredHub, which can also be run with Kubernetes deployments.
If you want to know more about how CredHub and Kubernetes work together, then make sure you attend SpringOne Platform and this session on using CredHub for Kubernetes deployments on September 25 at 5:00 p.m. in Maryland Ballroom D.
For more details also about Spring Cloud Config, which is part of the Spring Cloud Services suite of projects check this session by Chris Sterling on September 25th, at 2:00pm in National Harbor 2-3.
2. Open Service Broker API - Developing Services with Spring Cloud
Microservices architectures allow business to expose functionalities that were once only used in the context of a single business transaction. The result is that companies are producing more services for internal and external consumption today than ever before. Abstracting the mechanics of these services makes them more accessible and easier to provision and use. The Open Service Broker API (OSBAPI) is one of my favorite abstractions.
OSBAPI was initially created as part of the open source Cloud Foundry project. It allows SaaS, ISVs (and anyone) to offer their services to developers on any platform. The services look the same to developers, whether they are using PCF or any other platform, making them easy to consume. The OSBAPI is used by Pivotal, Google, Red Hat, SAP others through the Open Service Broker API initiative.
If you’re new to the OSBAPI, its objective is to define a contract between a service provider and a service consumer. To give you a quick example, if you want to use Google Pub/Sub, you can rely on the Open Service Broker API to create the necessary cloud infrastructure so that you, as a consumer, would then just use the service.
The OSBAPI has an important component called the ‘Catalog,’ which is exactly as the name says. If you’re using GCP, this is how your catalog might look:
Check here for current services available on GCP.
Now, imagine that you are on the provider side and you’d like to allow your customers and users to interact with your many services. The Spring Cloud Open Service Broker gives you the needed Java components in a lean programming model to implement your service according to the Open Service Broker API.
You might be thinking that a ‘service’ needs to be an infrastructure service, such as Google Pub/Sub. But that’s not the case. The API is flexible by design and the example application gives you a hint of what’s possible.
The example app provided in the Spring Cloud documentation uses books as the item to be managed by the API. You can think of the catalog as a bookstore or a library. There you can execute the four common OSBAPI operations (provision, deprovision, bind, unbind) against a catalog of books.
Last year at SpringOne Platform, Matthew McNeeney and Sam Gunaratne presented on How to Build Spring Services for Cloud-Native Platforms Using the Open Service Broker API. The presentation was recorded and you can watch it here.
3. Spring Cloud Sleuth - Business Focused Spans and Why It Matters
Distributed tracing is a great, useful feature. How else would you know what part or parts of your microservices ecosystem are impacting your SLAs?
Sure, metrics are great, but not enough. The traditional perspective on application metrics often fail to represent the context at which a metric was generated. Tracing brings you this much needed context, with a big plus that it does it across distributed systems.
Spring Cloud Sleuth provides an easy way to instrument Java applications so they automatically send traces about the state of transactions or requests across distributed systems. Sleuth takes care of both creating and forwarding the necessary headers to identify traces that are part of the same span. Sleuth has out-of-the-box integration with Zipkin, a very popular distributed tracing framework. The image below from Zipkin shows a call with many spans and traces generated across four services (client, flask-server, tornado-server and tchannel-server).
As companies migrate and evolve their stacks to support microservices, they might not want to rely only on the automatic instrumentation. The ability to specify when spans start and finish, together with span names that map to business functions, allows you to create a link between your application and how well it’s helping run your business. Let’s see an example:
In the diagram above, service calls that happen within the ‘calculateTax span’ are properly identified. The documentation goes into more details about about interacting with spans.
For those new to distributed tracing, please watch Adrian Cole’s introduction to tracing and Zipkin presentation.
If you are attending Spring One Platform and would like to know more about Spring Cloud Sleuth, then this is for you: How Sleuth Bravely Cracked the Case of "Too Much to Code" - by Adrian Cole and Marcin Grzejszczak. The session will be on September 26, 2:00 pm, Maryland Ballroom A.
4. Spring Cloud Kubernetes Graduated!
Kubernetes is a wonderful platform to run your workloads.
Once you have figured out a way to consistently build container images for your applications, running them on Kubernetes gives you the power of a large scale cluster management and container orchestration tool, but one that you can still run on your laptop.
With Kubernetes’ popularity in mind, the Spring community created the Spring Cloud Kubernetes project, and it just recently graduated from an incubator project to an official Spring Cloud project. (Do I hear fireworks?)
One reason I like Kubernetes is that it was written with state and reconciliation management in mind. You declare to Kubernetes how many replicas of your application you should have and it will fight hard to maintain that state. That capability can increase the overall resiliency and availability of your application.
For example, let’s say you have the ‘tax calculation rules’ service from above, and you want it to always have at least four replicas available to handle requests. If for some reason one of the processes goes down, Kubernetes will bring a new one up. That is great, but what if an application becomes ‘unhealthy’ and it still is up? Will Kubernetes solve that too? Well, maybe not, and Spring Boot Actuator and Spring Cloud Kubernetes can help fix that.
Spring Boot apps can be configured to automatically produce information about your application health. If you’re not familiar with how it accomplishes this, it’s through the the /actuator/health endpoint and you can find more information here. Most users extend it to add the particularities of the specific app they are writing. If the application is somewhat slow to respond, ideally the health endpoint should have that information, or at a minimum suffer from the same abnormalities as the app. You don’t want a responsive health indicator notifying solely that the app is running while the transactions are infringing your SLA, right?
When you use Spring Cloud Kubernetes (and your application happens to be running inside Kubernetes), it can automatically discover and enrich your health information about where exactly your application is running. The following information is available for you to use on your Kubernetes readiness and liveness probes:
-
Pod name, ip address, namespace, service account, node name and its ip address
-
Flag that indicates if the Spring Boot application is internal or external to Kubernetes
Cloud Foundry users have been relying on Spring Boot actuators for quite some time, and now Kubernetes users can also take advantage of the same technology. There’s no need to write code yourself to understand where the application is running if Spring already has that information.
For more details about Spring Cloud Kubernetes, check out the Git repo.
And if you’re attending Spring One Platform, make sure to catch the session Spring Cloud on PKS on September 27 at 10:30 a.m. in Maryland Ballroom D.:
5. Spring Cloud Contract
I’ve saved the best for last.
Sure, the proliferation of microservices applications and APIs has given us more flexibility and agility. We no longer have to move large monoliths around because we changed a small or sometimes insignificant feature.
With this proliferation, however, comes a degree of complexity. How do we write and test applications before all the pieces are there? Enter Spring Cloud Contract, which, in my opinion, serves as a way to represent an expectation when dealing with external service calls. I say expectation because it’s not a schema, but it’s also not only mocks. I believe it is a healthy stage in between those, but in a easy to use format.
There are two main pieces in Spring Cloud Contract:
-
A verifier mostly used by producers.
-
A stub runner used by consumers.
The beauty of Spring Cloud Contract is that you don’t actually have to be a Java developer to test your contract. It assumes a polyglot word, and allows you to write your contract using YAML.
Below is an example of a YAML contract:
There’s a great blog post that goes into more detail about Spring Cloud Contract. I also recommend reading this post by Martin Fowler.
After you’ve invested in creating your contracts, a good next step is to have a pipeline that covers such contracts. I recommend you take a look at the Spring Cloud Pipelines project to aid you in defining and running your pipelines.
At SpringOne Platform, you can catch the presentation by Olga Maciaszek-Sharma and Eddu Melendez where they’ll cover Spring Cloud Contract among other topics. It takes place on September 25 at 4:20 p.m. in Maryland Ballroom A.
Register for SpringOne 2018 Today!
Whether you’re developing Java applications to run on Kubernetes, Cloud Foundry or almost anywhere, it is a relief that you can trust in the Spring Cloud set of tools to bring distributed system patterns closer to you. To learn more, register for SpringOne Platform 2018, taking place in Washington, D.C., September 24 to 27. Use my discount code, S1P200_DRettori, for $200 off!
A quick introduction about me. I recently joined Pivotal as Marketing Director for Spring, and I’m very excited by the great technology this community builds. The Spring community is solving hard problems and making complex topics accessible to all. Before being part of this amazing group, I worked for 7+ years at Red Hat, where I was deeply involved with the Kubernetes and Service Mesh space. I’m one the organizers of the Boston Kubernetes Meetup and also a CNCF Ambassador. You can find me on twitter @rettori.
About the Author
Follow on Twitter Follow on Linkedin
