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

Understanding Threads created in WSO2 ESB

WSO2 ESB is an asynchronous high performing messaging engine which uses Java NIO technology for its internal implementations. You can find more information about the implementation details about the WSO2 ESB’s high performing http transport known as Pass-Through Transport (PTT) from the links given below. [1] http://soatutorials.blogspot.com/2015/05/understanding-wso2-esb-pass-through.html [2] http://wso2.com/library/articles/2013/12/demystifying-wso2-esb-pass-through-transport-part-i/ From this tutorial, I am going to discuss about various threads created when you start the ESB and start processing requests with that. This would help you to troubleshoot critical ESB server issues with the usage of a thread dump. You can monitor the threads created by using a monitoring tool like Jconsole or java mission control (java 1.7.40 upwards). Given below is a list of important threads and their stack traces from an active ESB server.  PassThroughHTTPSSender ( 1 Thread )
2 comments
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
1 comment
Read more

How puppet works in your IT infrstructure

What is Puppet? Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud. How the puppet works? It works like this..Puppet agent is a daemon that runs on all the client servers(the servers where you require some configuration, or the servers which are going to be managed using puppet.) All the clients which are to be managed will have puppet agent installed on them, and are called nodes in puppet. Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server. Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using p
5 comments
Read more