Exploring Synergy between SOA Cloud Computing
Date: Thursday , July 02, 2009
Cloud computing is at the leading edge of its hype curve. On the other hand, Service oriented architecture (SOA) hype is subsiding. No wonder the other day I actually heard someone’s remark “Looks like cloud computing has stolen the thunder from SOA”. If that refers just to the hype, I might concede some ground however if that refers to inherent value I’d have a different opinion.
In my mind, cloud computing a s a concept complements SOA as an architectural style and I’d rather go on to say that cloud computing is another piece of the enterprise architecture jig saw puzzle which SOA has been part of and will continue to remain so.
This short write-up takes a close look at these two and explores how these two complements each other and rather stand by them selves as competing approaches. The id ea is not to dwell comprehensively either on SOA or on cloud computing but to limit the discussion to comparisons complimentary characteristics, common challenges and synergies between these two technologies.
Since, SOA has been around for a while; it may mean different things to different people based on what perspective they’re looking from. Some look at SOA purely from web-services perspective and m ore of a means of integration using web-services.
Another set of people m ay look at SOA as a comprehensive architectural style, with its roots firmly grounded on principles of enterprise architecture. This notion of SOA is agnostic to technological means employed for delivering services.
Above two are the two extremes and the real SOA lies somewhere in between. The discussion in this write-up applies m ore to SOA as an architecture style. Having set that context, let us understand some concepts that are core to service oriented architecture.
Service: A service is the basic building block of SOA. There is an elaborate list of characteristics for a “good ” SOA service; in its minimal form, a service exhibits at least the following. It represents a discrete chunk of functionality, adheres to a published contract, and is loosely coupled, independent, standards based. Last but not the least, a service in SOA provides a business functionality of value to at least one and potentially to m ore than one consumer.
Composition: Composition is the basis for creating complex application functionality in a SOA enterprise. The application functionality that represents (and automates) enterprise business processes is built in a SOA enterprise from loosely coupled services using composition. In SOA parlance, composition refers to invoking services in a particular sequence in order to represent of complex business process flow.
The process flows thus composed may be exposed as a service so that they in turn can be used by external applications, or made available to user (through a U I).
In addition to these core concepts, there indeed are sets of other concepts that go into making of enterprise SOA. Notable among those are Enterprise Service Bus (ESB) and Business Process Management (BPM) engine. ESB is a messaging and integration platform. An ESB increases the “reach” of SOA b y allowing for better integration. BPM engine helps create sophisticated process flows using standards such as BPEL, which possibly include human interactions. However we will get to these only if necessary, mostly limiting ourselves only to the core SOA concepts discussed earlier.
Now let’s look at cloud computing. There are m any ways people define cloud computing. But since we’re out to get to the core of things, let’s talk about four-core properties that, in my opinion, form the b a sis for anything that wants to stake a claim for being “cloud computing ”.
Dynamic scalability on demand: Cloud computing is expected to provide a computing capability that can scale up (to massive proportions) or scale down dynamically based on demand. This implies a couple of things. First it implies a very large pool of computing resources. This pool of resources may either be within the enterprise intranet or on the Internet (on the cloud). And secondly it also calls for a mechanism to automatically “Provision” these resources in order to provide on demand scalability.
Virtualized resources: Computing resources offered in cloud computing are virtualized, meaning they make it unnecessary for consumer of the resources to worry about details of the underlying layer. The way virtualized resources are organized can be very different from the actual organization of the physical resources. It should be possible that set of small physical commodity servers are grouped and made available as single virtual m machine or a sing le powerful physical machine is split into many small virtual m achines. This implies the use of virtualization technologies or hypervisors.
Resources are provided as a “Service”: Service can include anything that is useful and can b e effectively delivered to a consumer asking for it. In principle, cloud computing embraces the notion of “everything as a service”. More popularly, cloud computing encompasses following three categories of service.
Infrastructure as a service (IaaS)
Platform as a service (PaaS)
Software as a service (SaaS)
The utility model: An important characteristic of a service in cloud computing is that a consumer pays only for service usage; contrast this to a “captive” or dedicated resource, where you pay for the resource regardless of whether you use it or not.
This model implies use of technologies that allow you to deliver the services for use as needed and meter their usage in order to arrive at a proportionate price.
A good place to start with is to look closely at the promises these technologies make that prompt enterprises to embrace these technologies. If we understand the implication of living up to those promises we know what necessarily needs to get under the hood of these technologies. Take the case of SOA. One of the important reasons why enterprises embrace SOA is because it promises reusability and agility. Reusability implies that services (as discrete chunks of functionality) can be used beyond their originally envisaged usage in an application.
Thus, Cloud computing provides everything as a service. Taking simplistic notion of SOA, where SOA is just about services, it’s quite tempting to say that cloud computing can now “replace” SOA as the mechanism to dish out services.
Notion of services in cloud computing is much broader that that of SOA. The notion of services in SOA certainly gels well with notion of the services in cloud computing. This is particularly true in cased of SaaS and that too when “services” in cloud computing a re provided in a “hosted ” paradigm.
So software as that’s delivered as a Service from cloud (SaaS) and particularly in case of hosted application services among in cloud computing could be dished out using a full fledged SOA stack. This will allow SaaS to take ad vantage of benefits that a SOA stack entails. This includes deriving benefits from the technologies such as enterprise service bus, BPM, and more, which go into making of SOA enterprise grade.
Well, success for both SOA and cloud com puting depends on their respective services possessing certain desirable characteristics from a functional as well as from a Quality of Service perspective. In earlier section we looked how in certain cases (Hosted SaaS) SOA service delivery stack could be leverage.
However, as a mature architectural style, SOA brings in a wealth of mature processes, which are potentially applicable across the complete spectrum of everything as a service in cloud. For example, SOA governance is now a relatively mature field, there is a good scope for cloud computing to borrow from best practice in SOA governance albeit judiciously.
It is well acknowledged that BPM can help in SOA governance and hence in cloud governance. That’s because after all governance deals with service life cycle management process and BPM by definition can help automate processes.
Major SOA vendors provid e products in both SOA governance space and also in IT governance space that includes an embedded BPM engine. Even if one is not using such a specific vend or product, but if BPM has been used in enterprise IT. It can be leveraged to automate SOA governance and cloud governance.
While some part of the business process resides and executes in the cloud providing you with all the benefits that a cloud entails, a bulk of proprietary processes or application may continue to reside within an organization’s legacy IT infrastructure. Using web-services as a tool for integration of these services with those on the cloud can provide means for integration between services on the cloud and not on the cloud so that the cloud and the non-cloud services form one single enterprise IT based on principles of SOA.
When cloud computing is used in enterprise IT scenario, that calls a couple of m mechanisms. A mechanism to expose legacy functionality as service on the “cloud ”,a way to consume services offered from the “cloud ” into enterprise. Both of the above im ply a need for integration across firewalls, and across technology boundaries. An enterprise service bus by definition is equipped to provide this capability and this becomes a vital component of the IT infrastructure that leverages cloud computing.
ESB vendors have perceived this fact and have been devising ways to create headway for their products and offering sin cloud space.
There is no particular stand one can take whether SOA can be part of cloud computing or cloud computing can be part of SOA. They’re kind of conceptually intertwined with each other. From one perspective, SOA as an architectural style deals with services, and services is what cloud computing provides. So, cloud computing is an instance of SOA.
From another perspective, SOA deals with application services, which form a subset of SaaS. So, SOA can be part of cloud computing. Real wisdom lies in desisting from this debate and in figuring out how service oriented architecture and cloud computing compliment each other so that mutual strengths can be leveraged in combination so that enterprise IT stands to win.