The Future of ESBs
Yogish Pai had a interesting post titled, “A decision maker’s concern about ESB.” In it, he provided two quotes, one from a Chief Architect of a financial services company and another from a CTO of a transportation company, both of which were raising some concern about leveraging an ESB.
ESBs have been one of the more controversial technology products in quite some time. They’ve been attacked as either rebranded EAI technology or efforts by vendor to “sell SOA” when most of us pundits have all stated that you can’t buy SOA. I’ve posted in the past (here, here, and here) on ESBs with more of a neutral approach, discussing capabilities that are needed and simply pointing out that ESBs are one way of providing those capabilities, and that’s still my stance. I’ve had the opportunity to work with companies that had purchased an ESB as well as companies that wouldn’t touch it with a ten foot pole. In both cases, the companies had found a suitable way to provide these capabilities, so you can’t say that one approach was better than the other.
What ultimately will decide the fate of the ESB will probably not be the specific technical capabilities associated with it, but the value that enterprises place on those capabilities. My past posts have stated my preference that the capabilities associated with the space really belong in the hands of operations rather than the hands of developers. As a result, you’d have to compare the cost/value of an ESB or other intermediary to the cost of other network intermediaries, such as switches, load balancers, and proxying appliances. Unfortunately, the ESB space is dominated not by traditional networking companies, but middleware companies. As a result, the products are being marketed to developers with feature after feature being thrown in, creating overlap with service hosting platforms, integration brokers, and orchestration engines. This dilutes the benefits of the core capabilities, and if anything, can make it more complicated to get those things done. In addition, these products may now clash with other products in the vendor’s portfolio, putting the sales staff in a difficult position.
The challenge that I see is that the value of a typical network load balancer from the view of a developer is pretty low. From their perspective, the features provided by the load balancer are minimal compared to what they need from the typical application server. As a result, I suspect that ESBs are very likely to become bundled capabilities rather than standalone products. It certainly means that there’s room for open source products, given that developers aren’t putting a lot of value to those capabilities, yet they are necessary. Open source products still need mindshare, however, so it will be interesting to see where it goes.
4 Responses to “The Future of ESBs”
Leave a Reply
Message queueing by any other name…
Integration capabilities (under whatever TLA) have been predicted to become bundled for quite some time now. And indeed they have in many instances.
Application vendors bundle integration toolsets, to provide one (often of many) interface. SAP R/3 is a well-known example, bundling webMethods tools years back and then switching to the Netweaver set.
Application servers bundle similar capabilities. WebSphere and WebLogic have long had integration capabilities, from low-level pieces to higher-level components, with varying success (e.g. WLI didn’t make much headway).
Will the latest set of tools achieve greater “embeddedness?” Time will tell.
From the transportation CTO: “…you expect me to tie it together by leveraging an ESB? Why shouldn’t I stay with my existing messaging infrastructure?”
Why not indeed. The difference between an ESB and “traditional” integration tools is, well, three letters, IMO.
From the financial services architect: “On an average I already have 7 hops for providing my customer the relevant information whenever they login to my web site. Based on your reference architecture recommendation I would increase the number of hops.”
This would seem to be an architecture problem, not an ESB problem. Refactoring things (not an easy task, I’m sure) to reduce the hops would seem to be in order.
IMO, Yogish is far off the mark in predicting the demise of ESBs by 2010. They might have another name by then, but the basic toolset and capabilities will be around for a while.
[…] Biske to come up with basic, common sense insights that never occurred to you. In his latest post, The Future of ESBs, he reiterates a conclusion he came to some time ago, that “the capabilities associated with the […]
As stated, the ESB has been marketed to developers as middleware. The long term implications of this are astounding when you consider how siloed we still are with regard to hybrid solutions (hardware & software).
There are few architects out there today with the skills to understand the implications of blades, SAN, virtualization, routers, load balancers, etc. on their software solution and vice verse. Hence, you never get the optimal solution that leverages the best of both worlds.
Until the market produces architects with the skills to understand the complete end-2-end solution inclusive of the physical deployment architecture, we will continue to see the world as either hardware or software and the lack of blending of the 2 worlds will result in non-optimal solutions.
The ESB should ultimately be an infrastructure component that provides real-time event management. The speed and reliability needed for these components do lend themselves to hardware better than pure software.
Hence, the question is not what is the future of ESB, but is there a future for the ESB at all? Or is the ESB merely a stopgap solution for software-only minded architectures.
[…] But, bringing the point back home, it’s a question of dealing with potentially warring tribes, as a debate rekindled by Todd Biske on the future of ESBs brought out a few weeks […]