the real owner isidentified. If each bounce goes through a team with a 15-minute response time,it can be hours before the right team finally finds out, unless you build a lotof scaffolding and metrics and reporting.- every single one of your peer teams suddenlybecomes a potential DOS attacker. Nobody can make any real forward progress untilvery serious quotas and throttling are put in place in every single service.- monitoring and QA are the same thing. You'dnever think so until you try doing a big SOA. But when your service says"oh yes, I'm fine", it may well be the case that the only thing stillfunctioning in the server is the little component that knows how to say"I'm fine, roger roger, over and out" in a cheery droid voice. Inorder to tell whether the service is actually responding, you have to makeindividual calls. The problem continues recursively until your monitoring isdoing comprehensive semantics checking of your entire range of services anddata, at which point it's indistinguishable from automated QA. So they're acontinuum.- if you have hundreds of services, and your codeMUST communicate with other groups' code via these services, then you won't beable to find any of them without a service-discovery mechanism. And you can'thave that without a service registration mechanism, which itself is anotherservice. So Amazon has a universal service registry where you can find outreflectively (programmatically) about every service, what its APIs are, andalso whether it is currently up, and where.- debugging problems with someone else's code getsa LOT harder, and is basically impossible unless there is a universal standardway to run every service in a debuggable sandbox.That's just a very small sample. There are dozens,maybe hundreds of individual learnings like these that Amazon had to discoverorganically. There were a lot of wacky ones around externalizing services, butnot as many as you might think. Organizing into services taught teams not totrust each other in most of the same ways they're not supposed to trustexternal developers.This effort was still underway when I left to joinGoogle in mid-2005, but it was pretty far advanced. From the time Bezos issuedhis edict through the time I left, Amazon had transformed culturally into acompany that thinks about everything in a services-first fashion. It is now fundamentalto how they approach all designs, including internal designs for stuff thatmight never see the light of day externally.At this point they don't even do it out of fear ofbeing fired. I mean, they're still afraid of that; it's pretty much part ofdaily life there, working for the Dread Pirate Bezos and all. But they doservices because they've come to understand that it's the Right Thing. Thereare without question pros and cons to the SOA approach, and some of the consare pretty long. But overall it's the right thing because SOA-driven designenables Platforms.That's what Bezos was up to with his edict, ofcourse. He didn't (and doesn't) care even a tiny bit about the well-being ofthe teams, nor about what technologies they use, nor in fact any detailwhatsoever about how they go about their business unless they happen to bescrewing up. But Bezos