Yegge

1. Overview

Argument: Google (and others) should use SOA as an engineering discipline.   

What is SOA?
 every API available over the network.  
 No internal interfaces, only external ones.  

How did Amazon apply the idea?
 Decompose website into thousands of primitive services
 Every team runs their service as a standalone product -- including operations
 Every service provides its users an SLA (service level agreement) -- a guarantee about the service response time/availability 

What did Google do instead?
 Architect website into hundreds of primitive services
 Central planning for capacity utilization
 Central operations
 Service users are expected to be well-behaved

Why SOA?

Separate interfaces for external developers => feeble API’s
Need first class API's to attract developers 
Need developers to add value: even google isn’t perfect at building apps
Better for system robustness

2. Lessons

What lessons do you think Amazon learned from running SOA?
(OK to speculate)

1. Automated service registry

2. Every user of an interface is a potential DoS source

3. Only way to tell if a service is up/functional is to use it 
(testing and fault monitoring are identical)

[SLA -- some bound on the performance/availability of a service]

4. SLA’s must be negotiated.  If a service has a resource limit (e.g., 
to protect its other customers), then customers need to know it and 
work around it.

[Corollary: since the only API's are public ones, need an API for negotiating resource usage]

5. Cache failures violate SLAs.  With a cache, system can 
run 10-100x faster than without. Implication is: if cache fails, 
system stops working.

6. Users care about getting an answer quickly.  
Then the job is to make sure the answer delivered quickly was 
the right answer ;-)  

[Early West Wing: Josh says sarcastically there’s a secret plan to 
combat inflation.  So then there needs to be one.]

7. Service evolution: a necessity.  How do they manage this?

Other thoughts?

What implications does the Yegge argument have for university CS research?  

[Possible answer: none.  We don’t build things people use. 
Another answer: embrace SOA.  The only way to compete with the 
Google behemoth is to leverage external users.  You see this 
tension in pretty much every DS project I’ve seen in the past 20 years.
]

Other implications/thoughts?

How would you design a service registry?

How would you design a service registry for service evolution?