The Spring Framework is one of the most popular Java Frameworks for building applications based on a distributed microservices architecture. Spring’s programming and configuration model for Java-based applications focuses on the “plumbing” so that developers can focus on application-level business logic, without unnecessary ties to specific deployment environments. Spring Boot then enables easy packaging and configuration of the application into a self-contained executable application which can be easily deployed as a container to Kubernetes.
Spring, like many traditional Java frameworks, does not inherently “know” that it is running in a container on a platform like Kubernetes. The Spring Framework includes many components that make building and deploying distributed applications easier, such as Spring Boot, Spring Cloud, Spring Web, and a host of other components to do service discovery, load balancing, request routing, and more. With Kubernetes, many of these concerns can be delegated to the underlying container platform to produce an application that integrates more efficiently with the platform it’s running on. Building Spring apps using these optimized code paths is key to unlocking the power of Spring + Kubernetes.
Spring apps can rely on Kubernetes and capabilities deployed to it to provide the needed cloud services that enable efficient development on Kubernetes. This includes services like message queues, databases, persistence storage, and caching, among others.
Microservice architectures often imply dynamic scaling of individual services, in a private, hybrid or public cloud where the number and address of hosts cannot always be predicted or statically configured in advance. In Kubernetes, service replication and scaling is a core feature. This means that the client does not need to keep a cache and account for the failure of the service registry itself. For example, Netflix Ribbon (often used with Spring apps) can be declaratively configured to use Kubernetes instead of a service registry, without any code changes.
For client calls to stateless services in Spring apps, high availability (HA) translates to a need to look up the service from a service registry, and load balance among available instances. Kubernetes provides a single service address where calls will be load balanced and redirected to an appropriate instance. Within a Kubernetes cluster, the service name resolves to this cluster IP address and can be used to reach the load balancer. For calls from outside and when going through the router is not desirable, an external IP address can be configured for the service.
The highly distributed nature of microservices implies a higher risk of failure of a remote call, as the number of such remote calls increases. Historically, the burden of implementing fault tolerance patterns like a circuit breaker has fallen to the developer. However, projects like Istio that implement a service mesh can alleviate this burden and provide much greater operational control over Spring services running in the cluster.
Externalized configuration management solutions can provide an elegant alternative to the typical combination of configuration files, command line arguments, and environment variables that are used to make applications more portable and less rigid in response to outside changes. Kubernetes ConfigMaps can be used to store fine-grained information like individual properties, or coarse-grained information like entire configuration files or JSON blobs. They provide mechanisms to inject containers with configuration data, keeping configuration separate from but accessible to Spring apps using annotations like
For all its advantages, a microservice architecture can be difficult to analyze and troubleshoot. Each business request spawns multiple calls to, and between, individual services at various layers. Distributed tracing ties all individual service calls together, and associates them with a business request through a unique generated ID. Going further, metrics enable Spring apps to expose application-level data to enable fine-grained examination of the state of an application. Tracing tools like Jaeger, combined with a metrics stack with Prometheus and Grafana provide a solid foundation for monitoring and troubleshooting Spring apps on Kubernetes.
As Spring applications evolve into collections of decentralized services, managing communications and security between those services becomes more difficult. Red Hat OpenShift combined with Red Hat Runtimes provides Spring developers with the tooling, frameworks and native Kubernetes integrations necessary to build and manage Spring applications at scale on the industry's leading container and Kubernetes hybrid cloud platform.
Get Hands-on learning for developing Spring and Spring Boot apps on Kubernetes and OpenShift
Understand how to architect distributed Spring apps on OpenShift
Learn more about Red Hat’s open approach to building and supporting Cloud Native Spring via the SnowDrop project