Microservices in Modern Enterprise Architecture

As microservices architecture is getting so much of a traction, most of the stake holders of enterprise IT are wondering how does it affects the other architectural paradigms such as Enterprise Integration and API Management. The objective of this post is to provide an insight into how a modern enterprise architecture would look like once we introduce  Microservices architecture into it. (However if you are still new to Microservices architecture you may refer my previous blog post 'Microservices in Practice'.)
I would like to start this discussion of how Microservices fits into the the overall IT landscape by elaborating some views from Gartner on Microservices.
The microservies architecture, essentially removes quite a lot of complexity when it comes to design, development, deployment and inter-service/system communication of the (micro)services.
However, the complexity which is removed from Microservices layer, has to be fulfilled by some other component/layer. For example, since MSA do not recommend to use ESB as the centralized bus, all the tasks done by ESB, such as service orchestration, routing and integrating with disparate systems should be done by some other components including microservices themselves.

Inner and Outer Architecture 

In order to use MSA in real world IT solutions we need to address both the above mentioned requirements. Gartner suggests that MSA has two different architectural domain.
  • Inner Architecture : The pure microservices components  which is less complex are categorized under 'Inner Architecture' 
  • Outer Architecture : This delivers the platform capabilities that are required to build a solution around the microservices that we build.
In fact the resulting enterprise architecture of the combination of inner and outer architecture, is the modern microservice based enterprise IT architecture. 

The Modern Enterprise Architecture with Microservices

The microservice architecture encourages the enterprises to get build all its IT solutions as microservices and not to use any intermediate integration products such as ESB. However, unless you are a green-field startup which has no any internal proprietary or legacy systems, that's not a realistic approach. If you consider any large organization or a cooperation, you simply can't convert all your software systems, services and solutions to Microservices. But such organizations want to leverage the microservices architecture to build agile and scalable software solutions. So, what we really need to have is a mix of Microservices architecture blended with the conventional monolithic architecture of the existing systems.
Figure 1.1 : The modern Enterprise Architecture with Microservices, Enterprise Integration and API Management
The figure 1.1 illustrates a high level overview of a modern enterprises IT architecture. Here you can find we have used a hybrid architecture which comprises of both Microservices and existing systems. This is similar to what Gartner has presented with their inner and outer architecture model.
Here are the key design decisions that you need to take when you introduce Microservices architecture to your organization.
  • Use microservices architecture to build solutions whenever required and try to gain the full power that MSA brings in.
  • Enterprise Integration is still needed. : Since we are going for a hybrid approach you will still need to integrate all your internal systems and services with the use of an integration software such as ESB.
  • You won't be able to throw away most of the existing systems, but the new microservices may need to call such monolithic systems to facilitate the various business requirements. In this case you may use the underlying integration software/ESB and microservice can call the integration server to connect to disparate systems.
  • The 'new' ESBs : Although Integration software such as ESB may be still needed for the modern enterprise architecture, such tools won't be the central integration bus any more. Organization should look for light weight, high-performant and scalable integration software instead of heavy-weigh integration frameworks. 
  • API Management : Microservices can be exposed via the Gateway and all the API-Managmement techniques can be applied at that layer. All the other requirements such as security, throttling, caching, monetization, monitoring has to be done at Gateway layer. Also the non-microservice based services (traditional SOA stuff) can also be exposed through the API Gateway.
Now lets have a closer look at microservices layer and see how do they interacts with each other in real world scenarios. 

Integrating Microservices

The most commonly asked questions in Microservice space is that 'Can microservices talk to each other?' or 'How to build new microservices by leveraging existing microservice'.
In fact, microservices architecture foster to build a microservice with limited and a focused business scope. Therefore when it comes to building IT solutions on top of Microservices architecture, it is inevitable that we have to use the existing microservices. The interaction between microserivices can be done in conventional point-to-point style, however that approach becomes quite brittle when it comes to microservices solutions with several services. Therefore we need to adhere to the best practices of Integrating microservice.
  • Using a Gateway to expose microservices : Use a GW to front all your microservices and all microservices consumers uses the microservices through through the Gateway only.
  • No direct calls among microservices : Microservices cannot invoke other mircoservices directly. All calls must go through the Gateway.
Now lets have a look at the techniques related to the interaction between microservices. 

Orchestration at Microservices Layer 

When you have to call multiple microservices to support a given business requirement you can build another microservice (which is again addressing a limited business scope) which orchestrate the service calls to the required microservices and aggregate the final response and send that back to the original consumer.
For example, the figure 1.2 depicts a scenario which we have few microservices A, B, C and D. Now we want to introduce a new business functionality which requires to call microservices A and C sequentially and provide an aggregated response. For that we can build a new microservice (Microservice E) and the orchestration logic that contains calling service A and C is embedded into Microservice E. And all the invocation of microservices are done through the Gateway. If the microservice E has to be scaled independently, that can be done by scaling microservice E, A and C as required.
Figure 1.2 : Service orchestration implemented at the microservices level 

Orchestration at the Gateway Layer

The other possible approach to implement the same orchestration scenario by brining in the orchestration logic to the Gateway level. In this case, we don't have to introduce another new microservice, but a virtual service layer hosted in the Gateway takes care of the orchestration.

 For example, as shown in figure 1.3, the service calls to microservices A and C can be implemented inside the Gateway layer (Most of the microservice gateway implementations do support this feature).
 When it comes to scaling the newly introduced business functionality, we have to scale the Gateway, microservices A and C. Now with this, the gateway is kind of becoming the monolith as it is also responsible to route all the other microservices requests.

Figure 1.3 : Service orchestration implemented at Gateway level. 

Choreography Style

Another possible approach to build interactions among microservices using asynchronous messaging style such as MQTT or Kafka. In this case there is no central component that take care the service interactions. Various services can do publisher-subscriber based messaging using messaging protocols.

Conclusion

So as a conlusion on how you can use Microservices architecture in modern Enterprise IT landscape we can summarize the following key aspects. 

  • Microservices is not a panacea : It won't solve all your enterprise IT needs. Therefore we need to use it with other existing architectures. 
  • Most enterprise won't be able to convert their entire enterprise IT systems to microservices. Instead, they will use microservices to address some business use cases where they can leverage the power of Microservices Architecture.
  • Enterprise Integration never goes away. - That means you need to have an integration software such as ESB to cater to all your enterprise integration needs. 
  • All the business functionalities should be exposed as API by leveraging API management techniques. 
  • Interaction between microservices should be support via a Gateway.  
  • Service orchestration between microservices may be required for some business use cases, and that could be implement inside another microservice or gateway layer can do the orchestration. 

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Understanding Reactor Pattern with Java NIO

Imagem
Why non-blocking IO A typical server application, such as a web server, needs to process thousands of request concurrently. Therefore, the modern web server needs to meet the following requirements. Handling of thousands of connections simultaneously (significant number of connections may be in idle state as well) Handling high latency connections Request/response handling needs to be decoupled Minimize latency, maximize throughput and avoiding unnecessary CPU cycles Hence, to cater to such requirements, there can be several possibilities in the server application architecture. Having a pool of sockets for each client, and periodically polling them: This is the most straightforward approach; however, it is more or less impractical without non-blocking sockets. This is extremely inefficient and never scales with the increasing number of connections. Thread per socket: This is the conventional approach and was initially used in some applications and this is the only practical solution wi...
Leia mais

A new journey.. A new working place.. WSO2 Inc.

Imagem
I guess switching blogs is less riskier than switching jobs. Anyway I had to take that risk of switching jobs in last month (12/2009) as I've joined WSO2 as a Senior Software Engineer. My very first job lasted only one and half years owing to various issues I had with the type of work I got during my first employment. However it was a good experience on some rare technologies like Search Engines and Indexing.. and not forgetting C++. Now.. the context has changed.. technologies has changed.. environment has changed... So I believe it's a whole new experience to me to work for WSO2 , which is a renowned Open Source SOA Company. These are my first few steps in the world of SOA and Web Services...
Leia mais