Service-oriented architectures burst on the IT scene a decade ago, and many companies have substantial investment in SOA applications already. It's clear that cloud computing's success hinges on its ability to add value to existing SOA implementations. Surveys show that more enterprise IT dollars are spent on applications based on SOA principles than on "monolithic" applications. What may be less clear is that
In an SOA system, applications differ from traditional apps in that they're based on a combination of componentization and orchestration; they are built from modular elements that are combined according to the specific workflow requirements of users, even individual workers. This is normally accomplished through a "workflow engine," sometimes called a message or service bus.
The big issue in creating SOA in the cloud is the dynamic load balancing most enterprises will expect in hybrid cloud apps, particularly for core, mission-critical SOA applications.
SOA applications are designed to be hosted on multitasking operating systems, and most service or message bus technologies today will support clusters of servers. Thus, within the enterprise SOA data center, "cloud computing" is already effectively a reality, with each SOA system component acting as an "as-a-service" element. Making SOA applications truly cloud-compatible, particularly with hybrid cloud, is a matter of balancing what SOA can do with what the cloud needs.
SOA-based cloud for failure prevention
The big issue in creating SOA in the cloud is the dynamic load balancing most enterprises will expect in hybrid cloud apps, particularly for core, mission-critical SOA applications. There are two elements that make load balancing work: creating additional instances of components when needed and balancing application traffic across those components as loads change or failures occur.
If load-balancing switches are already in use in the data center, it's possible to create public cloud instances behind these switches, making them look like an extension of the data center. This allows you to continue to use your existing load-balancing strategy. However, if data center power is lost, load-balancing switching is lost as well and failover to the cloud won't work. If load balancing is implemented as a cloud or network service, it can support a hybrid cloud SOA implementation -- even if the data center fails.
Sometimes the SOA service bus or "workflow engine" will be able to dynamically spawn additional instances of app components on multiple hosts to improve performance or respond to failures. In this case, check with the cloud service provider to ensure the service bus interface is compatible with a public cloud service. If it's not possible to link the service bus app instance creation process directly to the cloud's management interface to start a cloud component, you may have to use a development script or DevOps tool to spin up the necessary public cloud resources and then let the service bus use them.
When using cloud services of any sort to create an elastic extension to a private SOA resource pool, it's important to assess the impact of the provisioning delay on the application. Whether a public cloud resource is activated directly by the workflow engine or through DevOps, there will be an activation period when the resource will not be available, which will affect productivity. The delay has less of an effect on workload overflow applications because you can simply adjust the demand level at which new resources are requested. This adjustment, however, could result in spinning up public cloud resources that are not needed if demand tapers off. Having standby services or service-level agreements (SLAs) in place to reduce the provisioning time for cloud resources may be the best solution.
Choosing an SOA-compatible public cloud vendor
Depending on the OS and middleware used to run your SOA applications on-premises, you may have multiple options for hosting components in the public cloud. Companies like HP, IBM, Microsoft and Oracle have Platform as a Service (PaaS) options that are compatible with their server and middleware tools. So if you use SOA software from one of these vendors, the first step should be to assess the benefits and costs of using a cloud service from the same company.
If that's not possible or if you want to explore wider choices, then Infrastructure as a Service (IaaS) could be the better direction. Remember that for IaaS public clouds to work with your current SOA components, the IaaS machine image will have to include the OS and middleware you use. Make sure your IaaS cloud provider can support your OS and middleware, and ensure the licensing is compatible with public cloud use.
Generally, admins need to recognize that SOA and "RESTful" or "Web interfaces" aren't the same thing. Most SOA applications include orchestration and workflow, security and compliance elements that are often absent in basic Web services. Most cloud applications today are based more on RESTful interfaces than on SOA, and so it would be risky to presume that experience with the former teaches lessons for the latter. Explore the issues carefully and always run a thorough pilot test before making a production commitment.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in February 2013