How soa paved the way for cloud

1. How SOA paved the way for
Cloud

2. • Though some think SOA failed and others see it only as a partial
success, this has been because of the approach to SOA and not its
underlying principles. SOA (or what I’d rather call Service Orientation,
but that doesn’t fit our obsession with TLAs) is responsible for
beginning a new evolution in the way we build software. This change
is as fundamental as the shift to OO programming but essentially a
much bigger jump: OO was adopted one developer at a time, but SOA
requires teams and departments to make the culture, technology, and
mind shift together. Where SOA has been most successful is evolving
the way we build applications to the point where new deployment
models become possible; enter the cloud.

3. • There isn’t anything terribly new about the cloud. Virtualization
(VMWare, XEN, Parallels, Hyper-V) has been around for a while,
application scale-out solutions have existed in the forms of Grid
computing (GigaSpaces, GemStone, Globus, GridGain, Paremus), Map
Reduce (Hadoop), and distributed caching (Coherence, GigaSpaces).
We could build clouds in the past, but there was a lot of work
involved. Infrastructure as a Service (IaaS) was coined in 2006, and
Amazon has been at the forefront of this movement. What changed
recently was the ability to pull all of this stuff together in an easy way,
and the utility pricing model, driven by Amazon, has put all this
technology in the reach of a far wider user community that couldn’t
afford to play before.

4. • In order for cloud to work, we also needed to change the way we built
applications to run in the cloud. SOA has paved the way here, shifting our
focus from building isolated applications that communicate using point-to-
point integration to thinking of these applications in terms of services.
Services are discrete pieces of logic that have a well-known contract and
well understood function. This enables consumers to invoke services and
execute their functions. The fundamental shift here is that you must think
about how others will interact with your code. This is quite a big jump since
most developers can happily develop in a vacuum and just get things
working. In a service oriented application, your consumers may be your co-
workers, other departments, the whole company, business partners, or the
whole world.

5. • The fact that other people will be using your services adds additional
burden, since interfaces need to be defined with consideration to
hiding sensitive data, security, versioning, data types, interface
languages, and a consistent API across services. SOA has been
conditioning us to do this. For many organizations moving to the
cloud is much easier, because the heavy lifting has already been done.
Applications that have been componentized into services are much
better suited to the cloud, because by their nature components are
loosely coupled and can be hosted with location independence.

6. • However, moving your services to the cloud isn’t necessarily a plug-
and-play task. The cloud changes some of the rules for applications.
I’ll cover this in a follow-up post.