Microservices
And then there were microservices. Extremely tiny architectures of software services that can be deployed everywhere thanks to the cloud. Where legacy monolithic architectures come as a package deal, microservices operate independently from each other, turning IT from a house of cards into a speedy highway. Businesses that work with microservices can have their applications up and running in no time and anywhere they want, which makes them fast, flexible and capable of making all their customer wishes come true. Microservices often communicate through APIs, that function as a revolving door and pass on the derived information while integrating it with other data. It’s magical.
I don’t understand a word of what you’re saying
Many people believe that a combination of microservices and APIs are the future of IT. Those people are probably right; however, they overlook one small problem. APIs are brilliant in many ways, but they lack the ability to translate. So, when combining information from two completely different systems, chances are high their data is still incompatible. Here, the API is like a recruiter that travels the world, bringing together all sorts of people, but forgetting there’s such a thing as a linguistic barrier. In the real world, this makes people angry, while in IT, things simply stop working. In this situation, there’s need for a translator that makes sure that everybody is one the same page. Hence, there’s still need for the message translator of the Enterprise Service Bus.
ESB on steroids
Now that we’ve established that there’s indeed a place for the ESB in our future IT, we must make one very important sidenote. Yes, ESBs will remain a crucial part of software integration, but not in the way we know them. To keep up with all the changes that are going on both in and outside of the IT department, we need nothing less than an ESB on steroids. One that’s better, faster, more flexible and 100% compatible with APIs, microservices and IoT devices to make any kind of data exchange run smoothly. If the former ESB supported your internal data infrastructure for 80%, the new one should offer at least 120%. It’s not for nothing that WSO2 launched the Enterprise Integrator (EI), that re-established the WSO2 Enterprise Service Bus at the center of data integration, by offering a future-proof product that supports business strategies based on micro-services and APIs.
So, did API kill the ESB star?
No, but APIs did kill the ESB as we know it. At the moment, traditional ESBs are still needed for their message translator and integration capabilities. In healthcare, however, IT specialists cleverly introduced a universal language called HL7 to allow communication between all kinds of healthcare systems and organizations. In this specific situation, ESBs can actually be replaced by APIs as there’s nothing left to translate. The fact that healthcare managed to develop one universal language, shows that one day, the translating functions of the ESB will probably be replaced by APIs altogether. So where does this leave the ESB? We would recommend to not give him up just yet. First, the era of micro-services hasn’t arrived yet, which means that throwing out your ESB will leave you empty-handed for the upcoming years. Second, renewed ESB like the WSO2 Enterprise Integrator will keep on adding value to your IT infrastructure, but in ways you cannot even imagine.
So, instead of organizing a funeral for the ESB, we suggest you hire a wedding planner to unite the ESB and the future in marriage. They’ll probably get along just fine!
What is your take on the future of the ESB? Please let us know by leaving a comment below!
Want to select a future-proof ESB that matches your company requirements? Then download our ESB comparison guide. It’s free!
