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…
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.
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.
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.
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.
