Microservices Solution Patterns
Microservices Solution Patterns
This article discusses the possible solution patterns which can be used in a microservices architecture-driven enterprise.
Join the DZone community and get the full member experience.Join For Free
Sysdig is the container intelligence company. The only unified platform for monitoring, security, and troubleshooting in a microservices-friendly architecture.
Microservices Architecture (MSA) is reshaping the enterprise IT ecosystem. It started as a mechanism to break the large monolithic applications into a set of independent, functionality focused applications which can be designed, developed, tested and deployed independently. The early adopters of MSA have used this pattern to implement their back-end systems or the business logic. Once they have implemented these so-called back-end systems, then came the idea of implementing the same pattern across the board. The idea of this article is to discuss the possible solution patterns which can be used in an MSA driven enterprise.
At 33,000 feet, enterprise IT system looks like the picture shown below.
Figure 1: Enterprise IT system at 33000 feet.
As depicted in the above figure 1, the system is comprised of multiple layers horizontally and vertically. The business logic will be implemented in back-end systems as monolithic applications and there will be third-party systems like ERP, CRM, etc. On top of the back-end systems, there is the integration layer which interconnects heterogeneous back-end systems. Once these services are integrated, they need to be exposed as APIs to internal and external users as managed APIs through API management layer. Security and analytics will be used across all those 3 layers. With the introduction of the MSA, this entire ecosystem is opened up with new solution patterns which can serve the purpose of different enterprises based on their needs.
Pattern 1: MSA BE + Monolithic ESB + Monolithic APIM
This is the most common and the starting pattern of microservices implementations where back-end systems (business logic) are developed as microservices while keeping the other layers as is.
Figure 2: Pattern 1 - MSA BE + Monolithic ESB + Monolithic APIM.
The above-mentioned pattern is a good starting point for any organization to bring in the MSA and evaluate the pros and cons of the approach. Based on the results of this approach, a wider adoption can be done by moving into the patterns mentioned below.
Pattern 2: Monolithic APIM + Service Mesh + Message Broker
The latest development of the MSA is the concept of a “service mesh,” which provides the additional functionalities which are required for communication between microservices. The message broker is used as the communication channel (dumb pipe) for message exchange across microservices. This will reduce the requirement of an integration layer in some use cases.
Figure 3: Pattern 2 - MSA BE + Service Mesh + Message Broker.
As depicted in the above figure 3, in this solution pattern, MSA has extended to the integration layer and removes the need for a separate integration layer. Even though this pattern can be implemented for a green field IT organization, it will be harder for larger enterprises with so many additional systems.
Pattern 3: Monolithic APIM + Micro Integration + Service Mesh
One of the challenges of the Pattern 2 is to integrate CRM, ERP kind of systems to the microservices layer. Instead of doing the integration at microservices layer or through message broker, it is possible to bring in a micro integration layer to fulfill this requirement. With that, Message Broker functionalities (messaging channel) can also be moved into the micro integration layer.
Figure 4: Pattern 3 - Monolithic APIM + Service Mesh + Micro Integration.
As depicted in the above figure 4, microservices, database systems, and COTS systems (ERP, CRM) are integrated using the micro integration layer.
Pattern 4: Service Mesh + Micro Integration + Edge Gateway
With the widespread adoption of microservices architecture within the enterprise, the monolithic API gateway can also be replaced with a micro-API gateway or an edge gateway. This is the next solution pattern which can be implemented.
Figure 5: Pattern 4 - Edge gateway + Service Mesh + Micro Integration.
In this pattern, monolithic API management layer is replaced with a set of edge gateways which are deployed based on the APIs which are exposed to the users. These edge gateways behave similarly to microservices when it comes to design, develop, test and deployment while providing the API management functionalities.
Pattern 5: All MSA
Once the microservices wave is in full swing, security, analytics and database layers can also be implemented as microservices, except the COTS systems, entire enterprise IT ecosystem is implemented as microservices in this solutions pattern.
Figure 6: Pattern 5 - All MSA.
As depicted in the above figure 6, all the component within the enterprise are implemented as microservices except third-party systems. This pattern can be extended so that service mesh is extended across micro integration, analytics, security, and database microservices.
Published at DZone with permission of Chanaka Fernando , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.