Does Cloud Computing Hold Water? (Part II)
In our previous ZapFlash, ZapThink Managing Partner Jason Bloomberg explored the recent upswing in interest in Cloud Computing and evaluated its merits vis-à-vis Service-Oriented Architecture (SOA). In that ZapFlash, Jason concluded that cloud computing is an ill-defined term that has turned into a bandwagon that vendors, consultants, and end-users alike are jumping on without asking first where they are going. He also complained that there is a broad chasm between the sort of public clouds espoused by organizations like Amazon and the internal do-it-yourself clouds that large vendors would like you to sink your time and money into. But, his biggest bugaboo was that too many well-intentioned individuals and organizations are jumping without doing architecture of any sort, let alone SOA. Lack of an architecture perspective, preferably a Service-oriented one, is sure to doom any cloud computing effort just as much as it has doomed Web Services on a Bus efforts branded as “SOA”.
However, that’s not ZapThink’s final word on cloud computing. In this ZapFlash, we’d like to take a different perspective on whether cloud computing holds water with regards to SOA. In particular, there are some aspects of cloud computing that positively inform SOA and vice-versa, and allow us to shift the conversation of SOA beyond what many still consider to be standards-based integration.
Finally… a Reason to Stop Talking about ESBs
One of the best reasons to bless the cloud computing movement is that it finally allows us to shift the focus away from the Enterprise Service Bus (ESB). As you may recall from a number of previous ZapFlashes on this topic, the ESB has been far too central in organization’s discussions about SOA. The logic goes that all you need to do is develop a bunch of Web Services, plop them on an ESB and voila, you have a SOA. Isn’t it amazing that you can get architecture without actually doing architecture? As ridiculous as this might sound, for many organizations, this approach represents fully their SOA strategy. But, the movement to cloud computing throws the ESB “strategy” out the window.
In the cloud computing world, you have no visibility into the infrastructure, nor do you know where and how it is implemented. Indeed, you can both provide and consume Services without having to give a whit about the stuff in the middle. After all, that’s why it’s called cloud computing and not “vendor A’s bus” computing. Not only can you build a perfectly good SOA using a cloud as your infrastructure, but it might actually be a best practice to do so. In our Licensed ZapThink Architect (LZA) boot camps, we frequently espouse the position that Services should be designed to be location-independent, implementation-neutral, and distributed (potentially heterogeneous) intermediary based. A good cloud implementation should allow you to do all three.
With all this cloud goodness, there’s no need to even have to start your SOA planning by buying (or contemplating buying) an ESB. Design your Services to be infrastructure neutral and you can put them in the cloud or on existing infrastructure or on network intermediaries. Does it matter? No. This of course means that you should beware message queues that turned into EAI platforms that turned into ESBs getting turned into “cloud platforms”. Remember that you heard that warning first here, from ZapThink.
There is a major difference, however, between organizations that might leverage a third-party cloud as their SOA infrastructure from those enterprises that may want to implement their own internal clouds to serve as their SOA infrastructure. For the latter, you’ll still need some sort of infrastructure to make the Services behave in a cloud-like manner. However, odds are that it won’t look like what your current ESB looks like. After all, if a cloud was simply a message bus, then why don’t we call it such? Odds are that an internal cloud will look like more like the old grid-based computing infrastructure with massively redundant systems and virtualized compute infrastructure. In any case, the when the SOA conversation turns to cloud, it will necessarily have to turn away from being ESB-centric since there will be many more options for your SOA infrastructure deployment.
The Power of Service Virtualization
Another benefit of adding cloud computing to the SOA mix is that it allows us to consider the power of virtualization from the outset of designing our Services, rather than as an afterthought. In our previous ZapFlash on this topic, Jason complained that virtualization and SOA, while good in concept to combine, are not done so in practice because the people involved in the virtualization efforts and the SOA team are usually different people addressing different issues. However, that does not need to be the case.
Indeed, planning to use a cloud as your SOA infrastructure will require you to think about how to design, manage, govern, secure, and compose your Services from a virtualized perspective. At a 30,000 foot level, virtualization as a concept requires you to abstract a single instance of a particular resource as multiple. This means that a single storage resource becomes a virtualized many, as does compute and application resources. From a SOA perspective, Service virtualization therefore means that there should not be a single implementation, contract, composition, or process for the Service. Rather, each of these things should be virtualized so as to minimize the impact of failure, improve overall performance, and allow for variability and flexibility when things change. By focusing on movement to cloud computing infrastructures for SOA as an excuse to design virtualized Services, you are doing yourself a favor, even if you don’t end up deploying those Services in a cloud.
The ZapThink Take
This brings us to probably the biggest benefit of this whole cloud computing hoopla — a change in the way we think about Services. For those of you who have long considered Services to be location-independent, infrastructure-neutral, network intermediary-based, process-focused, and contract-driven then the cloud computing movement doesn’t really add much color to your SOA vision other than confirm what you have already suspected about SOA: you don’t need Web Services and you don’t need an ESB to make SOA a success. However, for those that have equated SOA with Web Services and ESB, they might see this looming cloud computing movement as the next iteration of their SOA efforts. For these readers, we would say, “finally!”
To properly implement SOA, you need to have abstraction as your primary perspective. But this also needs to be your primary perspective when you implement cloud computing initiatives. Service-oriented cloud computing is in many ways a redundant statement. Not having a Service-oriented perspective on cloud computing means you’re building tightly coupled clouds, which in theory should not even be possible. Having a non-cloud perspective on SOA means that you might (potentially) be building infrastructure-coupled Services that are not properly abstracted. While it’s certainly the case that you can build non-cloud SOA just as you can build non-SOA cloud, the reality is that one informs the other to the extent that it changes your thinking on each concept, even if you don’t implement the other.
Designing Services as if they would be implemented in a cloud, even if they are not going to be, helps you to build Services they way they should be built. Likewise, implementing cloud infrastructure as if it would be the core infrastructure for your SOA, replacing your ESB usage helps you to build a properly abstracted and agile cloud infrastructure, even if it never handles a single Service request. And this is why in many ways cloud computing can hold water. The question is, what will the future of cloud computing be? The dark, stormy cloud that is more like fog described in our first ZapFlash, or the silver lining on wispy clouds described here? The choice is not really ours. It’s yours. After all, you can’t buy architecture… you can only do it.