Enterprise Service Bus For Pessimists
posted by John Spacey, April 27, 2011The case for Enterprise Service Bus (ESB) a classic architectural argument.
When every application integrates directly with every other application you end up with n2 integrations. This is called Point to Point integration and everyone knows it is bad. After all, if you have 100 applications you might need 10,000 point to point connections — that's a lot of dependencies.
ESB simplifies things. Each service publishes data to the bus only once. Applications can subscribe to this data and the bus will take care of distribution to all the subscribers. So if you have 100 applications the maximum number of dependencies is 100.
In other words, ESB decouples service publishers and subscribers — a requirement of popular design methodologies such as SOA.
ESB seems like a no-brainer — it's about as controversial as toast for breakfast. However, a pessimist might ask: is there a case against ESB?
There are four problems with ESB:
1. Project Dependencies
Most projects have an integration aspect to them. So your ESB team is going to be involved in most projects. If your ESB team is slow or unreliable they can hold up every project in your organization.When application teams build point to point integrations there are less project dependencies — making projects simpler and less risky.
2. Cost
Even if we forget about the sky high licensing costs — ESB development costs are high. It is not unusual for integration to consume 40% to 50% of budget for COTS (commercial off the shelf) projects.In the point to point days — integration seemed cheaper.
3. Single Point of Failure
With all integration going through the ESB — the ESB is a single point for failure for the organization. This can be mitigated with high availability infrastructure or by deploying multiple instances of the ESB. However, ESB licences can be expensive — it is not unusual for all transactions to go through a handful of instances.If your ESB has regular production problems it can wreak havoc on your organization. Point to Point integration (despite all its faults) is distributed and highly redundant.
4. Declining Importance
In the past, ESB was critical because applications used a wide variety of messaging and communication protocols. ESB tools typically have dozens of adapters for both standard and proprietary protocols. Adapters were one of the key benefits of ESB products — just imagine trying to write custom adapters for each of your point to point connections.These days most applications have Web Service APIs. Even legacy applications often support Web Services. Messaging mediators such as ESB are less important when everyone is speaking the same language.
ESB Alternatives
Many popular ETL products now have real-time capabilities and represent a realistic challenge to ESB products.There is also a convincing architectural argument for Web Service Frameworks over ESB.
|
This is the way to prove to your stakeholders that your recommendations are not just whims. |
|
Learn about the 10 most important patterns for SOA success. |
|
A large collection of enterprise architecture tools. |
|
Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats.
~ Howard Aiken |
Recently on Simplicable
| 10 Big Data Definitions: Take Your Pickposted by John SpaceyAs with any emerging field, the definition of big data is always in flex. |
| 9 ITIL Implementation Challengesposted by Anna MarITIL implementation is no cakewalk. ITIL impacts your entire organization — your business, your IT department and your inflight projects. |
| The 9 Principles Of Soa Designposted by Anna MarService-oriented Architecture (SOA) is as simple as can be — it can all be boiled down to these 9 principles. |
| What Big Data Really Meansposted by John SpaceyThe 3 things you need to know to cut through the big data hype. |
