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

WSO2 ESB tuning performance with threads

I have written several blog posts explaining the internal behavior of the ESB and the threads created inside ESB. With this post, I am talking about the effect of threads in the WSO2 ESB and how to tune up threads for optimal performance. You can refer [1] and [2] to understand the threads created within the ESB. [1] http://soatutorials.blogspot.com/2015/05/understanding-threads-created-in-wso2.html [2] http://wso2.com/library/articles/2012/03/importance-performance-wso2-esb-handles-nonobvious/ Within this blog post, I am discussing about the "worker threads" which are used for processing the data within the WSO2 ESB. There are 2 types of worker threads created when you start sending the requests to the server 1) Server Worker/Client Worker Threads 2) Mediator Worker (Synapse-Worker) Threads Server Worker/Client Worker Threads These set of threads will be used to process all the requests/responses coming to the ESB server. ServerWorker Threads will be used to pr
4 comments
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
7 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
3 comments
Read more