Last week, when Stratos SOA platform maker WSO2 announced a retooled version of its enterprise service bus (ESB) along with other middleware for cloud computing environments, it begged the question: What do IT shops need to know about ESB implementation in the cloud?
Some evidence shows that IT shops can scale up the reach of their ESBs with cloud computing, but they must consider operations management, connectivity and security issues as they do so.
ESBs often take on the role of transformation engine where Web services are used. In cloud computing applications their ability to scale may be sorely taxed. Unspoken admission of this may be found in IBM's recent move to place its DataPower XML accelerator in the cloud.
These are early days for cloud-based ESBs, but there is some early adoption, particularly in the healthcare industry, said Heath Kessler, a consultant with Savoir Technologies Inc. of Evergreen, Colo. As the need to transform and route patient data between hospital departments and even between hospitals grows, many healthcare providers still have a different system for each department, he said. Integrating siloed systems often means more IT overhead.
"That's where the power of the ESB in the cloud comes in, even within a hospital," said Kessler. "A department can easily take their message as it is, pass it off to an ESB service and that ESB can transform and enhance that message, and pass it on." Internally cloud-based ESBs can mean better information flow between siloed departments. Externally, they can enhance B2B integration and connect to Web-based information services. In both cases, he said, ESBs can allow you to reduce IT budgets spent on integration.
ESBs and operational support
Deploying an ESB is still a new experience to many software architects and application development managers. One major challenge can be getting the necessary operational support. This is not likely to get less challenging as the ESB is applied in the cloud.
"The operations team only knows how to manage Web servers and application servers, so if we can't make our ESB look like an app server, the ops team won't support it," said one architect who declined to be identified. "Oddball services like the ESB are very hard to integrate into the cookie-cutter operational support model." His company has recently been trying to integrate an open source ESB into its private cloud architecture.
Paul Fremantle, CTO at WSO2, said he has been through this with many companies who insist that the ESBs run on top of their application servers. The problem is not the ESB, but the "cookie-cutter operations" themselves, he said. To get the real desired benefits of a cloud ESB, he said, an enterprise needs to think about cloud as more than just a way to virtualize hardware running the same kind of applications and services.
Of course, following Fremantle's advice could mean reworking the application infrastructure in a major way, which can be costly in itself.
WSO2's cloud platform contains a governance registry, an ESB, an application server, identity management, a mashup server and business activity monitoring. Fremantle said a business process server would be available later this year.
Making middleware available in a cloud form factor is an important step toward giving enterprise architects more flexible deployment options, said Chris Haddad, analyst with the Burton Group.
"I think Stratos is important because the product is one of the first open source Platform-as-a-Service offerings," said Haddad. "The open source distribution enables greater client customization, deployment within public or private clouds."
Cloud ESB architectural challenges
From an architectural perspective, an ESB will face different challenges based on whether it is deployed in a public or private cloud, said Mark Little, senior director of middleware engineering at RedHat JBoss. He said one of the important considerations in a public cloud scenario -- where an ESB runs in an external hosted environment -- is security.
"The ESB really needs to come in here and help you when the application is running to make sure that messages that flow within the cloud, between your different services, are correctly encrypted," said Little, "and that there's authentication so no one can sniff the network."
Security is less of an issue in cloud architectures that live behind the firewall, because the enterprise controls the network. Latency can become an issue when moving an ESB from private to public clouds, he said, because an enterprise may suddenly have to work with transport protocols for which its ESB was not originally configured.
Network connectivity in general is one of the trickier aspects when dealing with an ESB that lives in an external cloud. Demilitarized zones (DMZs) outside the firewall and network address translation (NAT) can make it difficult to detect on-premise applications from external sources, said Steven Nagy, consultant with Readify of Australia.
"This leads to a reduction in technological choice," said Nagy, "or it means that 'dev' managers need to put pressure on infrastructure teams to allow specific connections to specific machines, which creates maintenance points that are often difficult to track over time."
At the same time, loose coupling is one of the major goals of SOA, as well as cloud computing, said Jeff Genender, Java champion and CTO at Savoir Technologies.
"One of the big things in cloud is being able to deploy without really having to know what the exact IP address is," said Genender. While loose coupling can be a goal for any ESB, those running in cloud environments can have an even wider variety of connections to make between internal and external services, he said.