“I just got my people trained on SOA,” I heard someone say recently, “and now they want to go off and learn about Cloud computing. When are they ever going to do some actual work?”
We in IT are lucky that the big new ideas keep coming in, even if it can be hard sometimes to keep up with them. SOA was yesterday’s big idea, and now it’s Cloud. But these ideas are more than one-hit wonders: they need investments in equipment, skills and culture change that take years to provide a good return on your investment. Many enterprises have now invested in SOA, with initiatives planned, in progress or nearing completion.
How will Cloud computing affect those initiatives? Was the SOA investment wasted?
Of course, we all hope that the answer is “No,” and the conventional wisdom among analysts is that this is the case. Independent analyst David Linthicum, for example, says that “SOA is all about the process of defining an IT solution or architecture, while cloud computing is an architectural alternative. Thus, SOA can’t be replaced by cloud computing. In fact, most cloud computing solutions are going to be defined through SOA.”
So, your SOA investment can still pay off. But how exactly, do you achieve this? How will Cloud Computing help you to develop and deploy SOA?
Cloud Computing
Cloud computing can bring many benefits. Business scenario workshops conducted at two recent Open Group conferences in Toronto and Hong Kong identified nine key reasons why enterprises will use Cloud computing:
Agility Timeliness Resource optimization Cost Ease of innovation Security Risk management Compliance Quality of IT support, and Business continuity.
Each of these explains the explosion of interest in Cloud computing. And because they are all solid business reasons, there is no doubt that Cloud will be, not just a media phenomenon, but an increasingly-large component of enterprise IT systems.
One thing is for sure, if you implement Cloud, you won’t stop hearing about services. Cloud generally comes in three flavors, all of which are based on the service concept: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS).
In the SaaS flavor, the consumer uses the provider’s applications running on a public Cloud infrastructure. For example, rather than buying a CRM package to run on your in-house systems, you can interface to a CRM package provided as a service on the Cloud.
With IaaS, the consumer deploys and runs arbitrary software, which can include operating systems and applications, on the provider’s infrastructure. So, rather than setting up a data center, you can run your software on a Cloud provider’s systems.
PaaS is at a level between SaaS and IaaS: the provider supplies not just the raw infrastructure but also operating systems, middleware and programming tools, and the consumer can deploy applications onto this platform.
But using Cloud effectively is rather more difficult than picking your favorite ice cream flavor. You need to understand the advantages and disadvantages, both from a business and from a technical perspective, of each of the different kinds of Cloud services. Then you can determine how they should integrate with, or replace, the services already provided by your in-house IT department. This should also be part and parcel of the development of your enterprise architecture. Because services are fundamental to Cloud, it helps if that architecture is already service-oriented, just as Linthicum suggests.
How SOA Contributes to Cloud
SOA means more than just thinking in terms of services. It implies a particular way of constructing enterprise business systems using IT. An SOA system includes software services and an SOA platform and supporting infrastructure, just as a column in a classic Greek temple has a capital, a shaft and a base. The software services are supported by the SOA platform, which typically includes components such as an enterprise service bus (ESB) and a service registry. There are established standards for the components of the SOA platform, such as the Web services description language (WSDL) and WS-messaging, and there are commercial off-the-shelf products that support these standards. The SOA platform is in turn supported by the enterprise IT infrastructure of computers, data stores and networks. These elements of the SOA style also relate to the different kinds of Cloud service. The software services relate directly to SaaS, the infrastructure relates directly to IaaS, and the SOA platform relates, but not yet directly, to PaaS.
From the consumer’s perspective, the SaaS provider’s applications are software services that can replace some internally-provided software services and integrate with others, using the internal SOA platform extended over the Internet. This implies no radical architectural change. Decisions on use of externally-provided services can be made on a case-by-case basis, depending on cost, ease of deployment and other factors for the particular services concerned.
The software deployed over IaaS can include part or all of the SOA platform, with some or all of the software services that run on it. Again, there is no radical architectural change. The decision depends on the same factors as a decision to set up an in-house data center: equipment and support costs, return on investment, security, capability for disaster recovery, and so on.
The correspondence is however not quite as close for PaaS. Today, the popular Cloud platform services are running mostly at the operating system and programming language level rather than at the level of the SOA platform. They support standards such as Linux and Java, rather than WS-Messaging and WSDL. Of course, a SOA platform can be implemented on top of Linux and Java, for example, more easily than directly on the raw infrastructure, but this is not as good as being able to obtain the SOA platform itself as a Cloud service. To be really useful for SOA, Cloud platforms should include enterprise service buses, service registries and other SOA platform components―in other words, “SOA as a Service.”