Spring Boot Best Practices for Microservices

Learn more about Spring boot!

In this article, I'm going to propose my list of "golden rules" for building Spring Boot applications, which are a part of the microservices-based system. I'm basing on my experience in migrating monolithic SOAP applications running on JEE servers into REST-based small applications built on top of Spring Boot. This list of best practices assumes you are running many microservices on the production under huge incoming traffic. Let's begin.

You may also like: Spring Boot Microservices: Building a Microservices Application Using Spring Boot

Continuous Delivery with OpenShift and Jenkins: A/B Testing

One of the reasons you could decide to use OpenShift instead of some other containerized platforms (for example, Kubernetes) is out-of-the-box support for continuous delivery pipelines. Without proper tools, the process of releasing software in your organization may be really time-consuming and painful. The quickness of that process becomes especially important if you deliver software to production frequently. Currently, the most popular use case for it is microservices-based architecture, where you have many small, independent applications.

CI/CD on OpenShift is built around Jenkins. OpenShift provides a verified Jenkins container for building continuous delivery pipelines and also scales the pipeline execution through on-demand provisioning of Jenkins replicas in containers. Jenkins is still the leading automation server that provides many plugins that support building and deploying. One of that plugins is OpenShift Jenkins Pipeline (DSL) Plugin, which is by default enabled on a predefined Jenkins template available inside Openshift services catalog. There is not only one plugin enabled on Openshift Jenkins image. In fact, Openshift comes with a default set of installed plugins on Jenkins, which are required for building application from source code and interaction with the cluster. That's a very useful feature.

Redis in a Microservices Architecture

Redis can be widely used in microservices architecture. It is probably one of the few popular software solutions that may be leveraged by your application in so many different ways. Depending on the requirements, it can act as a primary database, cache, or message broker. While it is also a key/value store we can use it as a configuration server or discovery server in your microservices architecture. Although it is usually defined as an in-memory data structure, we can also run it in persistent mode.

Today, I'm going to show you some examples of using Redis with microservices built on top of Spring Boot and Spring Cloud frameworks. These applications will communicate between each other asynchronously using Redis Pub/Sub, using Redis as a cache or primary database, and finally using Redis as a configuration server. Here's the picture that illustrates the described architecture.

Kotlin Microservices With Micronaut, Spring Cloud, and JPA

The Micronaut Framework provides support for Kotlin built upon the Kapt compiler plugin. It also implements the most popular cloud-native patterns, like distributed configuration, service discovery, and client-side load balancing. These features allow you to include an application that's been built on top of Micronaut into an existing microservices-based system. The most popular example of such an approach may be integration with the Spring Cloud ecosystem. If you have already used Spring Cloud, it is very likely you built your microservices-based architecture using the Eureka discovery server and Spring Cloud Config as a configuration server. Beginning with version 1.1, Micronaut supports both these popular tools as part of the Spring Cloud project. That's good news because, in version 1.0, the only supported distributed solution was Consul, and there was no way to use Eureka discovery together with Consul's property source (running them together ends with an exception).

In this article, you will learn how to:

A Quick Guide to Microservices With the Micronaut Framework

The Micronaut framework was introduced as an alternative to Spring Boot for building microservice applications. At first glance, it is very similar to Spring. It also implements patterns like dependency injection and inversion of control based on annotations, however, it uses JSR-330 (java.inject) to do it. It has been designed specifically for building serverless functions, Android applications, and low memory-footprint microservices. This means that it should have a faster startup time, lower memory usage, and be easier to unit test than competing frameworks. However, today I don't want to focus on those characteristics of Micronaut. I'm going to show you how to build a simple microservices-based system using this framework. You can easily compare it with Spring Boot and Spring Cloud by reading my previous article about the same subject Quick Guide to Microservices with Spring Boot 2.0, Eureka and Spring Cloud. Does Micronaut have a chance to gain the same popularity as Spring Boot? Let's find out.

Our sample system consists of three independent microservices that communicate with each other. All of them integrate with Consul in order to fetch shared configurations. After startup, every single service will register itself in Consul. The applications organization-service and department-service call endpoints exposed by other microservices using the Micronaut declarative HTTP client. The traces from communication are sent to Zipkin. The source code of the sample applications is available on GitHub in the sample-micronaut-microservices repository.

Testing Spring Boot Integration With Vault and Postgres Using Testcontainers Framework

I have already written many articles where I was using Docker containers for running some third-party solutions integrated with my sample applications. Building integration tests for such applications may not be an easy task without Docker containers. Especially if our application integrates with databases, message brokers, or some other popular tools. If you are planning to build such integration tests, you should definitely take a look on Testcontainers.

Testcontainers is a Java library that supports JUnit tests, providing a fast and lightweight way for running instances of common databases, Selenium web browsers, or anything else that can run in a Docker container. It provides modules for the most popular relational and NoSQL databases like Postgres, MySQL, Cassandra, or Neo4j. It also allows running popular products like Elasticsearch, Kafka, Nginx, or HashiCorp's Vault. Today, I'm going to show you a more advanced sample of JUnit tests that use Testcontainers to check out an integration between Spring Boot/Spring Cloud application, Postgres database, and Vault.