There is no shortage of articles shouting that the rise of MicroServices means the death of ESB’s (Enterprise Service Bus). ESB’s are characterized as being monolithic1 and inflexible2. If frequent changes are needed in order to respond to the market, don’t implement an ESB, go with MicroServices. Another common statement says that if you are an established company with a lot of legacy application, your most likely choice will be to go the ESB route, but if you are a greenfield company, you may as well skip the ESB, and go only for MicroServices. But is that really the case?
As usual the answer is going to be that it depends. Even though MicroServices are fairly new, it has captured a lot of attention as an alternative to monolithic applications and service oriented architecture. But believe it or not, ESB’s still serve a very real function. In reality, even younger companies are still looking at implementing ESB’s. In part it is because the first part of ESB has traditionally been focused on integration.
For an organization that looks like this, with the need to integrate with many different internal business applications, to external business partners or 3rd party services, login services, and more.
A lot of money has already been spent on getting these applications and services to talk to each other. But these applications are often changing, and even for companies that have undertaken a lot of direct integration, the way going forward, to streamline existing and future integration, can be to build an ESB. An ESB can centralize messaging and aid in communication between the components.
Does an ESB make sense?
For any or all of the following reasons it may make sense to explore an EventDriven architecture, especially if the plans include needing to scale and integrate with additional applications.
- Do you plan to integrate more than two applications?
- Do you expect to connect more applications together in the near future?
- Do you need to use multiple communication protocols?
- Do you need message routing, e.g. aggregations, splitting, routing based on the message content?
- Do you need to publish services to be consumed by other systems?
- Do you need your services to communicate with ones that they currently can’t communicate with?
An ESB is scalable, as new applications are developed or the need arises, the new application can “simply” be hooked up to the bus, eliminating the need to directly connect applications to one another.
Where is it going to hit you?
No matter what solution is chosen; to continue with direct integrations or to develop an ESB, there are costs involved.
ESB’s are not without their costs as well. While there are open source ESB’s, enterprise versions have license fees associated with them. Some ESB’s will have templates or built in connectors to at least the most common enterprise systems such as Salesforce or SAP, these only need to be configured. Depending on the ESB, additional hardware may also be needed.
However, conventional wisdom tells us that direct integrations are going to always cost more to initially develop. The number of direct connections, grows exponentially the more applications that need to be integrated. Since they all have to be connected all to each other. This alone can take a mountain of time to write initially as well as maintain as applications change.
The Favorite for now – Mule ESB
There are a number of ESB products out there. A favorite of Softjourn’s is Mule ESB, over the other solutions on the market. The number of connections, templates, API’s that are available is quite high, for ease of integration. Mule supports legacy systems integration easily. Additionally, it has a cloud system which can make it easier to get started working with an ESB, versus having and supporting it in your own infrastructure, as well it can more easily scale with you. Their cloud solution supports both sandbox and production environments, which can be switched on the fly. A good aspect is that Mule ESB supports a number of languages, (Mule itself is written in Java), in which you can code your scripts to transform messages and do workflows. According to Kostiantyn Korniienko, Softjourn Architect, “There are a lot of out of the box components to route, transform, receive and send messages around. The paid version has a very good message transformer and http router.” All these features make Mule ESB a really strong competitor and one to be looked closely at.
Summary
ESB’s are far from dead. If only, or if initially for the aspect of integration of many applications. When deciding to build an ESB or continue with direct integration between applications, cost is a factor, as well as the time for maintaining many direction integrations, which leads to increased costs.
There are a number of ESB products on the market which can assist in the development of this type of architecture. When deciding which product to use look at current applications, and future plans for integration. As well as look at which 3rd party systems the ESB product has built-in connectors to, templates for and more.
Next stop?
An ESB or direct integration is just the start of the conversation. The next most interesting question is, “For an established company, with a number of legacy systems, when do MicroServices make sense versus an ESB?” That is a subject for future discussion.
