The microservices are generating a lot of attention in our sector
While the most innovative keep on talking about its practicality and the possibilities of working with this type of architecture, CIOs of large organizations with complex IT structures think about how this new trend will affect other architectural paradigms and business integrations or API Management. When talking about microservices, one of the recurring questions is how will the enterprise architectures be after we apply a this type of architecture in them.
-All you need to know about microservices, here!-
Such architectures have as an object the reduction of complexity of the services in terms of design, development, and implementation. This simplification in already developed architectures assumes that the complexity that has been reduced with the incorporation of the microservices will be replaced with other components or layers.
Two Layers Architecture
With the advent of the architecture of the microservices, the role of the ESB is questioned. According to this architecture recommendations, the ESB’s should stop acting like a central bus so all tasks performed by the ESB as service orchestration, routing or integration of other systems should be made by other components – even by the same services.
“In order to implement the microservices architecture in already developed complex IT solutions, a good idea might be to act with a two-layer architecture; one acting internally and the other externally. “
In this case, the internal architecture will contain the pure microservices components that will act with less complexity. Moreover, for the platform to have capabilities that are required by this services we will have to build a solution around the microservices we create. We will call this an external architecture. But how do these two layers interact?
This type of services architectures recommend not to use intermediate integration products as ESB. Unfortunately, this is unrealistic recommendation for large organizations with complex IT solutions already developed. Within this approach, these businesses are not eligible to convert their software systems to a solution done with microservices. But even so, these organizations are still interested in introducing a flexible and scalable software solution as microservices. To meet this need, it is essential a combination of microservices architectures with conventional monolithic architectures already existing in the system in a hybrid architecture.
Before applying this solution, we will have to address some key points. The first is that in a hybrid solution, we still will need to integrate all our systems and services through integration software as the ESB. The probability is that we can not get rid of the existing systems. New microservices may have the need to call the ESB to facilitate various business needs. For this purpose, there may be an underlying ESB and microservices can call integration services to connect with dispersed systems.
-This post could be interesting for you:Are te microservices the end of the ESB’s?-
Also related to the ESB, we must have clear that we are not referring to their traditional use. We no longer will have to understand them as central integration buses, but as a light, high performance, and scalable software, instead of heavy integration structures.
Moreover, in a hybrid system, microservices should be exposed by a Gateway and all API Management techniques can be applied at that level. The API manager will also allow us to have access to services that are not microservices and we can also meet other requirements such as security, monitoring or cache storage in the same layer.
In conclusion, although many CIOs think that to apply this architecture in their company is far from their possibilities by the complexity of their current solutions, it is possible if we apply a hybrid architecture. Thus, our systems will have all the advantages of microservices maintaining the fundamentals of the current solution. This way, microservices in a large company, can give great results.