Can a cloud-based ESB trim your integration costs? Yes, according to a recent TechTarget article, but depending on how it's used, you might find it has created operational support, security and latency issues along the way.
The question of how ESBs fit with the cloud began to generate a bit of buzz this month, after WSO2 announced its cloud-based platform as a service, which includes its ESB. But while that may have prompted the discussion, it was inevitable because some companies are starting to use ESBs to connect with cloud-based services.
On its surface, this looks like more of an issue for enterprise architects than IT executives. But read the TechTarget article, and I think you'll see why I say the potential problems of ESBs and the cloud transcend the scope of most enterprise architects and might require guidance from higher-level IT leaders.
For instance, the article quotes an enterprise architect who couldn't persuade the operations team to support ESBs for private clouds. "Oddball services like the ESB are hard to integrate into the cookie-cutter operational support model," he told TechTarget.
Of course, the big problems occur when an ESB is used to handle integration with external clouds. That's when issues of scalability, security, latency and network connectivity become an issue, as the article explains.
Then again, some hospitals are using cloud-based ESBs to cut integration costs. Heath Kessler, a consultant with the Colorado-based Savoir Technologies, told TechTarget that cloud-based ESBs simplify information-sharing between departments internally, while assisting with B2B integration and integration with Web services externally.
It seems ESBs are going to create as much controversy when it comes to the cloud as they did with service-oriented architecture, and for the same reason. While ESBs can simplify integration, they're doing it with an hub-and-spoke model-essentially a broker model - designed for EAI, writes Ganesh Prasad, an Australian-based software architect. Instead, companies should be using SOA's more federated approach, writes Prasad.
Enterprise architects and developers will enjoy Prasad's piece, as well as the ensuing argument in the posts, in which a reader asserts that Prasad is underestimating ESBs. But the rest of you might prefer Joe McKendrick's summary of Prasad's arguments and the whole cloud/ESB debate on a recent ebizQ post.
It's worth noting, though, that Prasad's not alone in his contention that ESBs do not make a SOA. In fact, some contend that those who pursued a more "pure" approach to SOA - without trying to buy solutions - will be better positioned to take advantage of the cloud now.
But McKendrick does offer a more moderate suggestion: If you're considering a cloud-based ESB, restrict it to internal, aka private, clouds.