Service-Oriented Architectures

1. Service-Oriented Architectures Andrew Whitaker CSE451

2. Today’s Theme • How do you allow hundreds of developers to work on a single website?

3. Amazon.com: The Beginning • Initially, one web server (Obidos) and one database Internet Obidos Database • Details: Front end consists of a web server (Apache) and “business logic” (Obidos)

4. Amazon: Success Disaster! Use redundancy to scale-up, improve availability Obidos Database Obidos Amazon.com Internet Obidos Load balancer Database Obidos Obidos

5. Obidos • Obidos was a single monolithic C application that comprised most of Amazon.com’s functionality • During scale-up, this model began to break down

6. Problem #1: Branch Management • Merging code across branches becomes untenable HelloWorld.c release development Blue changes depend on Red changes (which may depend on other changes…)

7. Problem #2: Debugging • On a failure, we would like to inspect what happened “recently” • But, the change log contains numerous updates from many groups • Bigger problem: lack of isolation • Change by one group can impact others

8. Problem #3: Linker Failure • Obidos grew so large that standard build tools were failing

9. Service-Oriented Architecture (1) • First, decompose the monolithic web site into a set of smaller modules • Called services • Examples: • Recommendation service • Price service • Catalogue service • And MANY others

10. Sidebar: Modularity • Information hiding (Parnas 1972): The purpose of a module is to hide secrets • Benefits of modularity • Groups can work independently • Less “synchronization overhead” • Ease of change • We are free to change the hidden secrets • Ease of comprehension • Can study the system at a high level of abstraction public interface List { } // This can be an array, a linked-list, // or something else

11. Systems and Information Hiding • There is often a tension between performance and information hiding • In OS’s, performance often wins: struct buffer { // DO NOT MOVE these fields! // They are accessed by inline assembly that // assumes the current ordering. struct buffer* next; struct buffer* prev; int size; … }

12. Service Oriented Architectures (2) • Modularity + a network • Services live on disjoint sets of machines • Services communicate using RPC • Remote procedure call

13. getPrice() Remote Procedure Call • RPC exposes a programming interface across machines: interface PriceService { float getPrice(long uniqueID); } PriceImpl Server Client

14. Shopping Cart Price Catalogue Recommendation SOA, Visualized Website • All services reside on separate machines • All invocations are remote procedure calls

15. Benefits of SOA • Modularity and service isolation • This extends all the way down to the OS, programming language, build tools, etc. • Better visibility • Administrators can monitor the interactions between services • Better resource accounting • Who is using which resources?

16. Amazon as a Platform • SOA allows third-parties to use some (but not all) of the Amazon platform Sleds.com Amazon.com Front-end website Order Processing Shopping Carts Catalogue

17. Performance Issues • A webpage can require dozens of service calls • RPC system must be high performance • Metrics of interest: • Throughput • Latency • Both average and the variance

18. SLAs • Service performance is dictated by contracts called Service Level Agreements • e.g., Service Foo must • Have 4 9’s of availability • Have a median latency of 50 ms • Have a 3 9’s latency of 200 ms

19. Issues • Discovery • Load Balancing