Problem
How can a team quickly create and setup a maintainable codebase for a production-ready service so they can start developing its business logic?
Forces
- A service must implement
- Build logic that builds, and tests the application and also packages into a production-ready format, such as a Docker container image.
- Cross-cutting concerns such as externalized configuration, logging, health checks, metrics, service registration and discovery, circuit breakers. There are also cross-cutting concerns that are specific to the technologies that the microservices uses.
- Creating a new microservice should be fast and easy
- It should be fast and straightforward to update existing services when the requirements for build logic and cross-cutting concerns change.
What Is a Chassis?
In general, a chassis is the base frame of a car or it can be thought of as a skeleton. Similarly, in a microservices context, it can be the base framework or even another service which can be reused across different services.
This is not something new. Reusability is something we learn in at the very beginning of our developer lives. This pattern cuts down on the redundancy factor and complexity across services by abstracting the common logic to a separate layer.
If you have a very generic chassis, it could even be used across platforms or organizations and wouldn't need to be limited to a specific project. It depends on how you write it and what piece of logic you move to this framework.
Chassis are a part your microservices infrastructure layer. You can move all sorts of connectivity, configuration, and monitoring to a base framework.
Why Do You Need a Chassis?
When you start writing a new service by identifying a domain (DDD) or by identifying the functionality, you might end up writing lots of common code. As you progress and create more and more services, it could result in code duplication, or even chaos, to manage such common concerns and redundant functionalities.
Moving such logic to a common place and reusing it across different services would improve the overall lifecycle of your service. You might spend some initial effort in creating this component but it will make your life easier later on.
How Do You Implement It in Your Microservices?
Before creating or designing your primary service, think of chassis as how to address the common concerns. When you start designing your architecture and use a whiteboard, pull out all the common concerns which can spread across your different domains. If you follow a DDD approach, each domain or subdomain can be a service out of which you can build a chassis framework which works across all your domains.
A few of the notable concerns:
- Logging
- Exception handling
- Interception logic
- Authentication/security
- Some common backend services you connect across services (databases, external calls, MQ, etc.)
The base framework helps in creating new services easily and ensuring that they're maintainable. You can only concentrate on the service boundary and let the chassis deal with all the other common infrastructure functionalities.
So, how do you start writing a framework? There are no hard and fast rules for creating your own custom framework. You can just build a framework with a snapshot version uploaded to your repository. All other services can just pull it from the repository and use it. Use a SpringBoot autoconfiguration with a starter parent to build a library.
