Enterprises with expanding plans for cloud computing, whether public, private or hybrid cloud, are increasingly interested in the intersection of cloud and SOA. In order for software to be useful in the cloud, the cloud and SOA, or service-oriented architecture, need to be compatible. For a growing number of businesses, though, the cloud is being recognized as a proactive driver to SOA when, in fact, SOA is a critical point of support for expanding the use of cloud in the enterprise.
SOA has two goals: componentization and consistency of exposure. SOA builds functional elements that are exposed as "services" through application programming interfaces (APIs). These elements then compose applications, which create SOA's dual benefits of reusing software components to improve development efficiency.
The cloud is being recognized as a proactive driver to SOA when, in fact, SOA is a critical point of support for expanding the use of cloud in the enterprise.
To create an application, a set of components is "threaded" into a workflow, often using a workflow "engine" or service bus software element. The workflow for a given application is directed to the correct component through a directory function, often called the Universal Description, Discovery and Integration (UDDI) in most SOA standards. When an application component is installed, a UDDI entry allows the application workflow to locate the component. This is where the cloud and SOA intersect.
Any time an application or application component is assigned to a flexible resource in any resource pool -- including the cloud -- it's associated with an address. And that address must be published to other components for the software to integrate into a company's overall IT process. Because SOA provides a way to locate components, that mechanism can be used to record what happens when an application runs in the cloud. In most cases, this mechanism will allow a company to deploy an application in the cloud and register its location, making the app accessible to the user. Resolving other addressing issues that involve URLs also requires DNS updating.
Short-term hybrid cloud and SOA concerns
The relationship between SOA and a hybrid cloud environment has its benefits, but it also has downfalls. One issue is the potential for performance problems when the application workflow moves across the public-private cloud boundary. In normal SOA applications that run within the data center, the data center network can maintain fairly efficient workflows across component boundaries. Having those workflows move data over a WAN to the cloud, however, could introduce delays, packet loss and, in some cases, exposure to security problems.
Ten years after its launch, SOA may be destined to succeed -- in the cloud.
The component registration process for SOA apps in a hybrid cloud also has its pros and cons. On the plus side, you can use the public cloud to host a component that can no longer run on-premises because of a system failure. This creates a failover option for the application. If the application and the workflow or system bus processes support the use of multiple component instances, you can also manage that through SOA registration.
However, hosting a component on the public cloud is transparent to the user and IT -- unless the UDDI is examined. But doing so could expose the end user to public cloud usage charges if the component or application isn't brought back on-premises when the system is restored. Part of any SOA management procedure for hybrid cloud applications should include steps to ensure public hosting is used only when necessary.
Additionally, because of the "service" nature of SOA software, applications are accessed either through a graphical user interface (GUI) or through APIs and a third-party GUI tool. When using SOA with the cloud, it's important that the GUI supports the mechanism used to address the application. In most cases, this would be the UDDI, the DNS or both. It's the cloud user's responsibility to ensure associated directories are properly updated, which means the directories must be accessible from both the data center and the public cloud.
In the long run, cloud and SOA are a match
Highly componentized applications with elements that register automatically upon loading fit perfectly into the users' vision of an elastic cloud resource pool. They also could facilitate load balancing and failover between private cloud elements or between a private cloud and the standard data center. In fact, many argue that in order to achieve all the benefits of cloud architecture -- a plug-and-play, fully elastic, self-provisioning, application execution framework -- you need SOA software.
With the industry trending toward the adoption of SOA for complex software products, future applications will likely become more SOA-compliant. And this makes them perfect candidates for a flexible, elastic hybrid cloud.
Service providers already see the value of the cloud and SOA link. One major European carrier that offers cloud services listed SOA expertise as a requirement for chief technology officer (CTO) status. Enterprises agree, as they begin to embrace a private cloud model that focuses more on creating a flexible framework that allows you to blend private IT with hosted public cloud services. Ten years after its launch, SOA may be destined to succeed -- in the cloud.
Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in August 2012