Please load the images to see all the content in this ZapFlash!
<http://t.ymlp178.com/qbeaxauwwakaumqeazambmuu/click.php>
Does Cloud Computing Hold Water? (Part II)
Document ID: ZAPFLASH-2009325 | Document Type: ZapFlash
/By: Ronald Schmelzer/
Posted: Mar. 25, 2009
In our previous ZapFlash
<http://t.ymlp178.com/qhmaoauwwakaumqeavambmuu/click.php>, 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”
<http://t.ymlp178.com/qhjazauwwacaumqeacambmuu/click.php>.
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
<http://t.ymlp178.com/qhbavauwwapaumqeaxambmuu/click.php> may recall
<http://t.ymlp178.com/qhhalauwwazaumqeagambmuu/click.php> from a number
<http://t.ymlp178.com/qhwavauwwaaaumqeaxambmuu/click.php> of previous
ZapFlashes <http://t.ymlp178.com/qhqaaauwwaaaumqeakambmuu/click.php> on
this topic <http://t.ymlp178.com/qhyaxauwwaraumqeavambmuu/click.php>,
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
<http://t.ymlp178.com/qwsacauwwacaumqeaaambmuu/click.php>, 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.
<http://t.ymlp178.com/yubadauwwaoaumqeapambmuu/click.php>
