The phrase "Service Oriented Architecture" conjures the image of huge unwieldy backend systems, Weblogic servers, WAR publishing services, and giant XML documents full of endless markup. The total hotness in 2004-2005 just when all things Object Orientedness hit its stride, and dictatorial architects wielded enormous diagrams keeping the various APIs under control. It's a nightmarish conflagration of "Java Business Objects" and "Windows Communication Frameworks" and giant SOAP objects with endless decorators.
Awful. But the concept of the service oriented architecture is a fundamentally good one even if enterprises took it and perverted it for their own nefarious uses. Members of the community, trying to get away from the original definition of SOA, have recast the next iteration as "SOA 2.0" or "Web 2.0 with SOA attributes" or "Web 2.0 mashed up with SOA."
SOA, re-imagined for Web 2.0, is:
- A collection of small, light services -- workers or web services -- providing a unified interface to consumers;
- Collections of work broken down into small producer processes;
- Easily divisible systems which horizontally scale.
Instead of having objects in our code, our systems become essentially object oriented because of new and interesting constraints placed by a lack of availability to vertical scaling.
When working with a cloud provider, small is beautiful. Enormous bare metal servers full of infinite RAM and CPUs aren't available and, when they are available, not cost-effective for the long term for any systems beyond the database. Small, light, highly performant web services which inter-operate and provide a coherent API simply functions better in an elastic universe of small virtual machines with limited cores scaling across multiple datacenters on multiple continents.
The cloud architecture community has been avoiding the term SOA (we talk about RESTful services) but this is essentially what they are -- sans the enormous XML documents and broken up in much smaller pieces. Not only does old-school SOA not work in the cloud, but neither does old-school LAMP stacks except for on a highly limited "I only do 10 hits a day" basis.
From the point of view of the cloud, especially AWS, going into a project thinking strongly about how to craft the application so its overall structure is broken into groupings of OO-based services with different scaling characteristics is the name of the game.
SOA is not a 4-letter word in the cloud. But it's not old Java Business Objects and Interfaces, either. Like everything else in a world full of using tiny shards of computing power, we have to rethink our core architecture to take advantage of the new paradigm instead of fighting against it. SOA gets a system to horizontal scale -- and with DNS scale across datacenters -- and that's the name of the game to making things huge in the modern day of 40K concurrent users on a casual day.