January 2022
When designing microservices, it’s important to ensure that each service is decomposed into a business capability. As microservices follow a lean and focused philosophy, designing microservices around business capabilities ensures no unnecessary features or functionality is designed or built. This reduces project risk, the need to refactor unnecessary code, and reduces the complexity of the overall product. Since microservices are built around business capabilities, it’s critical to have business stakeholders or users participate in the design sessions.
Steps to Sketching Out a Defined Microservice
Before diving into the implementation, it’s critical to understand the complete picture of all services and how they interact with one another to avoid feature creep and unnecessary features that don’t meet business needs. An effective approach is to have key technical staff (usually a lead designer, technical lead, and architect) and stakeholders collaborate using event storming. Event storming enables project implementers and domain experts to describe an entire product or system in terms of the things or events that happens. This empowers both the business and technical staff to have complete control of a problem space and design product services using plain and easy-to-understand descriptions rather than technical jargon.
Engaging in event “post it note” storming enables project implementers and domain experts to describe an entire product or system in terms of the things or events that happen.
Using post-it notes, the team arrange events in a rough order of how they might happen, although not at first considering in any way how they happen or what technologies or supporting structure might be present in their creation. Events should be self-contained and self-describing with no concern placed on implementation details. When doing this exercise, it’s helpful to draw a causality graph to explore when events occur and in what order. Once all events are documented, the team then explores what could go wrong in the context. This approach helps you ask the question “What events do we need to know?” and helps you identify missing events, which is a powerful technique to help explore boundary conditions and assumptions that might affect real estimates of how complex the software will be to build. When the team feels all events have been adequately documented, the next step is to document user personas, commands, and aggregates.
User Personas
User personas document the various users that would use the system. Personas help teams understand the goals of the user performing a given action, which is helpful in the design phase.
Commands
Commands are a user action or external system that caused an event.
Aggregate
An aggregate receives commands and decides whether to execute them or not, thus producing other events as necessary.
Once all personas, commands, and aggregates are documented, the team can now see “big picture” on how the entire system or product should work to meet all requirements. This approach is excellent when designing microservices as each event or handful of events can be clearly defined for a microservice. The service author creates a service that accommodates only those events, creating lean business capabilities that have a well-defined scope and purpose. Event storming is also great for both technical and non-technical stakeholders, as the entire system is described by its events. This removes barriers for stakeholders to participate in the design process as the technical implementation details are not discussed. This approach works well for an existing system or new application.
Design Guidelines When Building a Microservice
Once a team has all their services defined and organized, they can focus on the technical details for each microservice. The implementation details will be specific to a given service, and below are guidelines that will help when building out a microservice:
Develop a RESTful API
Each microservice needs to have a mechanism for sending and consuming data and to integrate with other services. To ensure a smooth integration, it’s recommended to expose the API with the appropriate functionality and response data and format.
Manage Traffic Effectively
If a microservice requires the handling of thousands or millions of requests from other services, it will not be able to handle the load and will become ineffective in meeting the needs of other services. We recommend using a messaging and communication service like RabbitMQ or Redis to handle traffic load.
Maintain Individual State
If it’s necessary for the service to maintain state, then that service can define the database requirements that satisfy its needs. Databases should not be shared across microservices as this goes against the principles of decoupling and database table changes in one microservice could negatively impact another service.
Leverage Containers for Deployments
We recommend deploying microservices in containers so only a single tool is required (containerization tools like Docker or OpenShift) to deploy an entire system or product.
Integrate into the DevSecOps Pipeline
It’s important that each microservice maintain their own separate build and be integrated into the overall DevSecOps CI/CD pipeline. This makes it easy to perform automated testing on each individual service and isolate and fix bugs or errors as needed.
How EGlobalTech Can Help You Deploy Microservices
EGlobalTech has extensive past performance developing and deploying microservices for multiple clients. Our experience includes containerization through Docker and OpenShift, and we have leveraged containers to deploy microservices across many complex applications. Our Technology Solutions group built and integrated microservices on existing legacy applications, developed new applications using microservices, and migrated legacy architectures to complete microservices-driven architectures.