SOA done right: the Amazon strategy
I survived the Google Seattle scalability conference And Seattle's "summer" weather! The conference was titled "The Seattle Conference on Scalability". The Google hosts were wonderful. I met some fellow bloggers and a lot of smart folks from massive scale websites, and some that hope to become massive scale websites.
What is the leading edge of scalability? 1,000,000 node clusters in five years, up from 25,000 node clusters today. Another spoke of 100x current scalability in the next few years. New plumbing to enable 10 GigE to handle massive clusters. Programming tools that enable a few dozen lines of code to put thousands of nodes to work.
Rather than summarize the entire conference in a few paragraphs or pages, which would hardly do it justice, I'm going to hit on some topics of particular interest over the next few days. Today's topic is the Amazon approach to a service oriented architecture (SOA). Werner Vogels and Swami Sivasubramanian presented at length on Amazon's experience.
SOA done right I've been critical of SOA hype because - in a nutshell - SOA isn't based on business metrics. Architects and devs can gush all they want, but until you can show hard business benefits you'll get a wave-off from the bean counters. As you should.
I've also been impressed by Amazon's path to highly scalable SOA because they've made every mistake in the book, starting with a hairball app, moving to a mainframe and finally a fully distributed SOA model.
How distributed? Every Amazon web page calls on at least 150 services. IMHO, the most important statement of the day was when Werner noted that "resource sharing without contracts kills scaling." If your services can't scale, your SOA dreams are DOA.
Bi-lateral talks The contract covers what the service promises against certain demand levels. The key is that both the demand side and the supply side are covered by the contract. This is the simplest level of business metric.
If the service doesn't meet the SLA when the demand exceeds the contract, too bad. As he noted several times, Amazon is all about getting the customer's money. It is a business, and developers are expected to know business requirements.
Decompose the problem So what is the key to scalable services? State management. Saving state to a database guarantees scaling failure. So how do you keep some having to save state? By decomposing the problem so it can be solved with smaller, simpler tools. Simple tools are more scalable.
Databases are dinosaurs I already think that RAID arrays are dinosaurs - a kludge that has outlived its usefulness. Werner made a related point: databases are dinosaurs too. They are difficult to manage, don't scale well and architecturally indistinguishable from their forebears 15 years ago. Also like RAID arrays.
Do you want availability or consistency? SOA has also required new thinking about consistency and availability. It turns out that in Amazon's experience you can either have high availability or strong consistency. You just can't have both at the same time.
My take on why is this: strong consistency means that there is lots of communication among the services, and if the communication doesn't complete, the system has to stop until it does. If consistency is relaxed (or eventual) things keep moving even when services get hinky. Of course there has to be a final review process to remove possible inconsistencies, but in the meantime you've moved the customer to the money moment.
The Storage Bits take Amazon has amassed a wealth of experience in SOA. If you think SOA is worth investing in, you owe it to yourself to listen to what Amazon has to say. At some point the talk will be up on YouTube and you can watch it yourself. I'll post the URL here when I get it.
Comments welcomes of course.