Microservice chassis to handle cross-cutting concerns

In any new application development, you are often required to implement particular scenarios or services, such as cross-cutting concerns. You have to spend a significant amount of time implementing common cross-cutting concerns in the development of a new application. Let's have a look at the following cross-cutting concerns:

• Build system and externalized configuration: We have to choose either a Maven or a Gradle-based system to compile, package, version, and resolve external dependencies. This will also deal with further external configurations, such as credentials, and the network locations of external services, including databases or message brokers.
• Implement logging: Logging is also required for all services of a new application development. You have to configure a logging framework, such as Java, Log4j, Logj42, java.util.logging, Commons Logging, Logback, or slf4j.
• Monitoring and health checks: You have to implement a monitoring system for all services in a new application development. Spring Boot applications are very easy to monitor using the Spring Boot Actuator and JMX. You have to provide a URL for the health check of the application.
• Metrics: The Spring Boot Actuator also provides the metrics of an application. Metrics provide an insight into what the application is doing and how it is performing.
• Distributed tracing: A microservice architecture is based on distributed services across a number of machines, so it needs to be able to trace a complete call end to end across multiple services. Spring Cloud provides a solution for distributed tracing using Spring Cloud Sleuth and Zipkin. It assigns each external request to a unique identifier, which is passed across the services to trace a complete task.

The preceding list shows the most common cross-cutting concerns. There are many others which are specific to each technology. Suppose you want to configure a database and a message broker in a distributed application. You have to handle the external configuration and the boilerplate code across the services in the distributed application so that the relational database is configured with a connection pool. In order to implement these common concerns, we have to write repetitive code. According to the programming principle of Don't Repeat Yourself (DRY), we must avoid code repetition in any of our application infrastructures.

A microservice chassis provides a way of implementing these cross-cutting concerns without repeating the same code across multiple services in the distributed programming model. We can build a reusable chassis and use it across services by asking teams to ensure that the search service shares the same coding pattern. We can create a production-ready chassis, using Spring Boot and Spring Cloud, that you can use to bootstrap your own cloud applications.

For more information, please refer to my book Mastering Spring Boot 2.0, which has some examples of these cross-cutting concerns. In Mastering Spring Boot 2.0, I used the following frameworks and components for the microservice chassis:

• Runtime monitoring: Spring Boot Actuator, Spring Boot Admin, and JMX
• Service registration and discovery: Spring Cloud Netflix (Eureka)
• Distributed call tracing: Spring Cloud Sleuth and Zipkin
• Logging: Slf4j and Logback
• Optional runtime container: Docker and AWS ECS

Let's continue with our online bookshop example and look at how to build microservices using Spring Boot and Spring Cloud.