In a monolithic application, cross-cutting concerns can be designed and developed once. After their development is complete and they are available for use, they can be leveraged throughout the application.
Microservices are independently deployable, self-contained services. As a result, implementing a cross-cutting concern has to be done repeatedly for each microservice. This can make it prohibitively expensive for an organization to develop microservices when considering the development resources that would be needed. A system may consist of hundreds of microservices, and your team may be creating new ones throughout the life of the application. The process of creating a new microservice should be made as fast and easy as possible, and you are not going to want to implement cross-cutting concerns for each one.
To overcome this challenge, a microservice chassis can be used. A microservice chassis is a framework that can take care of many of the cross-cutting concerns for microservices and do so in a way that allows all of your microservices to utilize the functionality.
Some examples of a microservice chassis include Spring Cloud, Microdot, Gizmo, Go kit, and Dropwizard. Each microservice framework is different, but some of the cross-cutting concerns that they handle include the following:
- Logging
- Externalized configuration
- Metric reporting and instrumentation
- Service registration and discovery
- Health checks
- Tracing
It should be noted that it is not required that you use an open-source or third-party microservice chassis. It could be a framework that you develop within your organization, specifically tailored to your needs and using the technologies that you choose. The important point is to have a microservice framework that you can reuse so that you are not implementing the same cross-cutting concerns multiple times. Once a microservice framework is in place to handle cross-cutting concerns, the development team can focus on the core concerns of the microservices themselves.