This post is by one of our MuleSoft champions, Antonio Abad.
Let’s start with a simple definition of both concepts:
“An ESB is basically the integration of the new and the old, providing a central place for the services, applications, and IT resources in general that you want to connect.”
“A microservice architecture (vs. the legacy monolithic architecture) is an approach to developing a software application as a series of small services, each running autonomously and communicating with one another, for example through HTTP requests to their APIs.”
Microservices have called into question the future of ESB. But how does the new architecture trend really affect Enterprise Service Bus?
It seems that the Microservices have arrived to stay. More and more CIOs want to install this type of architecture to their projects. Microservices are perceived as the future of doing business. Many believe that it is a generational change promoted by the “Digital Transformation” and think that ESB is becoming obsolete. Are they right? Are micro-services the new era of SOA? Definitely. You have to take them into account. But for ESBs, no, they are still alive. We must adapt our concept of this architecture and can no longer understand the Integration Bus as a centralized and inflexible concrete structure for the whole company. When we talk about them today, we should think of a flexible, scalable and well-distributed infrastructure in which we can incorporate, implement and monitor any type of service in an agile and efficient way.
The ESB must fulfill a function of integration, coordination, routing and monitoring of the business activity. Understanding the ESB in this way, we can build applications through services or microservices to solve the requirements and needs of a company. The services must be treated in an individualized way with a standardized interface to a platform with automatically scalable execution time. Thus, these services are decoupled and scaled in a linear fashion on non-specialized hardware. This is the best way to understand an Enterprise Service Bus today. Microservices do not mean the death of ESBs if the latter are used in a suitable way. That is to say, focusing on an architecture where services are the protagonists and not in a centralized architecture towards the Integration Bus itself.
About this tool, we must not forget to integrate a gateway of services for security and exposure of services as API Gateway to external consumers. The services gateway can direct the integration of integrated services into the Bus, external service applications and cloud services. Finally, we have to think twice if we really need this type of architecture. An Entreprise Service Bus only makes sense if our goal is to coordinate the actions or events that are happening in our services from a set of heterogeneous systems that we must integrate and present to the upper layers.
In conclusion, we can definitely assert that microservices do not make ESB an obsolete technology. In fact, both are perfectly compatible and can function in a coordinated way. Of course, for them, we must ensure that we work with a correct and updated Business Services Bus concept. If so, microservices together with ESB are a winning combination. They have not come to deprecate them, at most, they have come to be their accomplices to get a critical support architecture to the business!
Please check out MuleSoft’s Microservices Best Practices whitepaper and a fascinating blog post about taking the API approach to microservices with lessons learned from SOA.
The post reflects on the MuleSoft champion’s personal experiences & thoughts and not necessarily from MuleSoft directly.
