Skip to main content

Microservices Solution Patterns

Microservices Architecture (MSA) is reshaping the enterprise IT eco system. 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 a MSA driven enterprise.
At 33000 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 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 heterogenous 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 eco system 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 it 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 (2,3,4,5)
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. 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. Eventhough this pattern can be implemented for a green field IT organization, it will be harder for a 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 fullfill 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, 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 behaves similar 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 eco system 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.

Labels:

Comments

Post a Comment

Popular posts from this blog

How to protect your APIs with self contained access token (JWT) using WSO2 API Manager and WSO2 Identity Server

In a typical enterprise information system, there is a high chance that people will use different types of systems built by different vendors to implement certain types of functionalities. The APIs might be hosted in an API Manager developed by vendor A and the user management can be implemented using a different vendor (vendor B). In this type of a situation, one system will not be able to directly contact the other system but they want to use both systems in tandem. Self-contained access tokens are used in these types of situations where applications can get the token from one system and use that in another system to access protected resources. In this scenario, the second system does not need to make a contact to the first system over the network to validate the user information since the token is self-contained and it has relevant details about the user. This will improve the token processing time significantly since it completely removes the network interaction. The below fig...
1 comment
Read more

WSO2 ESB creating a response for a "GET" request

When you are creating REST APIs with WSO2 ESB, you may need to send some response message back to the user when something goes wrong. In this kind of scenario, you can create a payload inside the ESB and send it back. For doing this, you can use the below configuration. <api xmlns=" http://ws.apache.org/ ns/synapse " name="LoopBackProxy" context="/loopback">    <resource methods="POST GET">       <inSequence>          <property name="NO_ENTITY_BODY" scope="axis2" action="remove"></property>          <log level="full"></log>          <payloadFactory media-type="xml">             <format>                <m:messageBeforeLoopBack xmlns:m=" http://services...
Post a Comment
Read more

How to configure timeouts in WSO2 ESB to get rid of client timeout errors

WSO2 ESB has defined some configuration parameters which controls the timeout of a particular request which is going out of ESB. In a particular  scneario, your client sends a request to ESB, and then ESB sends a request to another endpoint to serve the request. CLIENT->WSO2 ESB->BACKEND The reason for clients getting timeout is that ESB timeout is larger than client's timeout. This can be solved by either increasing the timeout at client side or by decreasing the timeout in ESB side. In any of the case, you can control the timeout in ESB using the below properties. 1) Global timeout defined in synapse.properties (ESB_HOME\repository\conf\) file. This will decide the maximum time that a callback is waiting in the ESB for a response for a particular request. If ESB does not get any response from Back End, it will drop the message and clears out the call back. This is a global level parameter which affects all the endpoints configured in ESB. synapse.global_timeout_inte...
6 comments
Read more