Other day, I was talking to one of my friend at office about ESB and the misconception of “Micro-services=ESB Dead” phrase that we hear a lot these days. It somehow does not make sense truly that Micro services will be replacing or killing the ESB.

Basically, all these discussions lead to why do we need ESBs?

This question can be answered in 3 points in layman terms:

• Many applications, many technologies thus leading to many formats of data, many protocols for communications.
• Business is evolving at a higher rate.
• We need to integrate all these systems with both legacy and modernized is a continuous problem.

Management says:

• We have more number of integration points and are expanding every year.
• We have many applications that run on different protocols and always scalability, management, monitoring, data transformation and security is the issue with the current systems.
• Architects though providing integration solutions with in house development, it is taking lot of time and we have to find out solutions in less time for our problems.
• We have to follow many compliance procedures every year and they get changed.
• We need a tool that can take care of these integration issues and helps in reducing the time of delivery and also gives us a better solution.

Architect says:

• I want to model, test and evaluate a particular product or component for integration in a very less time.
• I do not have team at hand and so whole evaluation is on my shoulder.
• So, I want some tool or technology that helps me in my job to provide quicker solutions to the management.
• Management is always behind me about the evaluation feedback.

Developer says:

• My company is brining many different products every year for improving their business.
• I need to work on my development tasks and also have to write services/interfaces for integrating all these new products and management does not give much time for me and always under pressure.
• My service built to talk to product A cannot talk to product B as B supports different protocols or data formats.
• My company is either adding new product to integrate or replacing one with another.
• So, I want some tool or technology that takes away the integration tasks from my user stories and I want to concentrate on development tasks. Integration is not I am interested in.

They all want this:

• A tool which is ease to use.
• Should have monitoring dashboard and should provide its own logging and other functionalities.
• Better if it has a community support so that I can always look for custom components or code shared in github, if the tool does not provide a particular feature.
• It should Enterprise application integration by supporting easy scalability and distributed architecture.
• Should provide 24/7 support and well-defined SLAs.
• It should support mapping different data structures and easy to build applications.

These all will be addressed by ESB tools.

If your company is not a big enterprise where your applications only need to talk with few other applications through common protocols and standard services and your typical system involves reading data from repository and sending data over internet or displaying the data on UI or collecting the data, then ESB is not for you. Or if you are a service provider who provides services for the clients, then you may not worry about ESB. ESB is needed for the companies that heavily invest in procuring the new tools, products every year from vendors and they want to integrate with in less time in order to reap the benefits of the procurements.

Some argue or opines that Micro-services are the future and ESB is dead. But as per me, they solve two different purposes and we cannot compare them apples to apples. For example, web service is a language and platform agnostic and can be easily extended with inbuilt exception handling support and WS-* standard support. But they are heavy weight, more verbose, hard to develop and time consuming to build. Similarly, REST services are also platform and language agnostic, they have small learning curve and can be developed in less time. But it lacks security standards, support for policy, reliability.

It makes sense for supporting business rules and distributing the functionality over internet and for other inter-system related communications, services are the best solutions. Spending time on the services for the business logic and distribution of data is worth and also we can promote good SOA practices that decouples client applications and data. But services cannot be developed at ease to incorporate ESB core capabilities like Routing, Message Transformation, Message Enrichment, Message Processing, Transaction Management, Monitoring, Logging and Security. It takes lot of development efforts and impossible to keep up with the growing infrastructure in an organization.

My point is Services are built for specific purpose and ESB architecture is meant for different purposes and we cannot compare both. More than all, ESB has been experimented and trusted since 10 years and all the companies have heavily invested in the ESB tools. It is very difficult to move totally into Micro-Services architecture which is still young and people have just started experimenting it. It has to stand the test of time and it can definitely be embraced by the enterprises. But, ESB still has its own place and it keeps growing with the growth of the enterprises in parallel with the services architecture.

Everyone has a different opinion and there is no one answer. It basically depends upon the organization culture and how they embrace the newer architectures over existing ones.