Designing Modern Service Architectures

Cloud computing is becoming the primary way large web applications are deployed. The flexibility of these platforms gives us the opportunity to break out of the usual scaling patterns and deliver power precisely where and when we need it. Through practical examples, we'll explore a modern service-oriented application and discover strategies and tools that will help you make the most of the cloud.

Transcript

1. DESIGNING MODERN SERVICE ARCHITECTURES SAMANTHA QUIÑONES ZENDCON 2014, SANTA CLARA, CA
2. Samantha Quiñones @ieatkillerbees http://tembies.com
3. WHY ARCHITECTURE IS IMPORTANT
4. Functionality Solutions must… Solve the problem(s) at hand Not attempt to do to much Be accessible to the user
5. Stability Solutions must withstand… Time… Load… Abuse…
6. Maintainability Solutions must be… Easy to extend… Easy to maintain…
7. Economy Solutions must be cost effective… in development… in infrastructure…
8. CASE STUDY THE 2012 ELECTION
9. Scaling Content Delivery What is a “scalable” application? How do you balance static and dynamic content?
10. Understanding the Problem An application is scalable when response time remains constant when traffic increases or decreases
12. Scalable != Performant Scalability is not the same as highly performing An app that performs equally poorly at any load might technically fit the definition
13. Scaling Can Be Hard Scaling is a very tricky problem Predicting traffic is nearly impossible Scalability must balance responsiveness and cost
14. Uncontrolled Variables
15. Uncontrolled Variables
16. Uncontrolled Variables Even when we think we know what to expect, we're usually wrong
17. Uncontrolled Variables S at S un Mon Tue Wed Thu Fri 0 10000 20000 30000 40000 50000 60000
18. Uncontrolled Variables S at S un Mon Tue Wed Thu Fri 0 100000 200000 300000 400000 500000 600000 700000 800000
19. Everything Is Connected Alternative resources becoming unavailable increases demand on remaining resources
20. Getting Meta This experience is an interesting example of how the systems we design reflect more “organic” ones The news media, in a sense, is one large system Healthy parts of a system compensate for injured parts
21. Elections Are Hard Election results are constantly updated The results need to be parsed and made available with minimal delay When users perceive your results as “behind,” you lose them
22. The Problem with Election Data 3,000 sets of rules (just for Federal Elections) Rules change constantly Primaries are insane. Special Elections are worse. Results have to be ingested, parsed, analyzed, and published in real time
23. And Then It Got Real 725,000 peak concurrent connections 8,000,000 page views/hour 54,000,000 page views total
24. Uncontrolled Variables S at S un Mon Tue Wed Thu Fri 0 100000 200000 300000 400000 500000 600000 700000 800000
25. Get A Little Zen Traffic is something you can't (usually) control Traffic can be factored out Rather than fighting traffic, we can accept it And find inner peace
26. The Usual Approach When traffic is factored out, scaling is easier and cheaper As requests increase, response time stays constant
27. The Usual Approach Hardware-focused N+1 a necessary expense Why IT is often not seen as a “profit center”
28. Scaling Ahead Wastes money Wastes time
29. Scaling Behind Save money at the expense of user experience Frustrating for IT staff to manage Diminishes user experience
31. In The Toolbox Distributed DMBS Caching Computational Amortization
32. Clouding the Cloud Cloud in the Cloud… Massively distributed virtualized computing is beginning to fill the gaps Just like “real” hardware, costs can get out of control
33. It’s Not Perfect
34. New Methods Require New Methods Deploying applications meant for server-closet infrastructures doesn't make sense in the cloud. We need to build software to make maximum use of the platform it's running on.
35. SERVICE- ORIENTED ARCHITECTURE A BRIEF INTRODUCTION
36. Service-Oriented Architecture Evolved in the Enterprise Software world of the 1980s and 1990s CORBA, JINI, and SOAP are technologies born in the first generation of SOA SOA seeks to reduce the cost of highly-complex, high-volume applications
37. No One Likes SOAP
38. Judge Not Networks were slow and unreliable Standards were not widely adopted Bandwidth was expensive System memory was scarce
39. Good Ideas Done Poorly SOA is a logical outgrowth of Modular computing Introduced ideas like loose-coupling and object- orientation to a monolithic, procedural world
40. WHAT IS A SERVICE? A LONG-WINDED AND NEEDLESSLY PEDANTIC EXPLANATION
41. Services are Granular A service is a self-contained application that… performs one function, or a small number of closely-related functions
42. Services are Interfaces Services implement contracts Define legal inputs and outputs
43. Services are Loosely- Coupled Services are not aware of anything outside of themselves Services interact through well-defined interfaces
44. Services are Abstractions Services abstract a small, coherent set of logic or business rules Implementation details are hidden Services within in a single application can be implemented in many different languages and on many different platforms
45. Services are Discoverable Given the address of a service, a consumer should be able to learn how to interact with it WSDLs are giving way to RESTful hypermedia APIs
46. Services are Stateless Services are concerned with inputs and outputs Two identical requests should always result in identical responses
47. Services are Portable Services do not need to live in one “place” in the network Services can move, expand, appear, and disappear Location is irrelevant
48. Services are Composable Services can be “mashed up” to create more complex applications
49. EVERYTHING OLD IS NEW AGAIN AN IDEA BEFORE ITS TIME
50. The Infrastructure Problem Service architectures require a distributed architecture that didn't exist until recently Network speeds need to be sufficient to make protocol overhead less of a concern
51. Discoverability requires Cooperation CORBA and JINI were good solutions to the problem of brokering services. Early methods added more complexity than they relieved Increased developer learning curve slowed adoption.
52. The power was in us all along…
53. HTTP & REST meet SOA HTTP - Nine standard methods, ~40 standard responses Implementations for nearly all platforms and languages REST - A pattern for building stateless web services
54. A MODERN APPLICATION
56. Applications Do A Lot of Nothing Most components of an application spend most of their time idle. The majority of code performs computationally inexpensive operations Copying the whole application means duplicating the architecture needed to run everything, all the time, over and over again
57. A SERVICE ARCHITECTURE
58. Cache Caching is practically a requirement to offset the transactional request overhead Since services are inherently cacheable, caching will offer substantial performance gains
59. Language & Platform Agnosticism Some languages are better suited to some tasks than other The implementation of each task must balance development time, performance, and return on investment
60. Extensibility
61. And Again…
62. No, seriously…
66. Our Little Service, All Grown Up Our mail service is an abstraction, a hostname It can be on a shared server, a dedicated server, a cluster of 100 servers The sum total of work is creating a virtual server, deploying the code to it, and changing a DNS entry.
67. Request Flow Client Public Cache Application Server Service Network Cache Service Application Service
68. Static Content Under High Load Public Cache Public Cache Public Cache Public Cache Public Cache Public Cache App Server App Server Service Network
69. Dynamic Content Under Heavy Load Public Cache Public Cache Public Cache App Server App Server Election Data Service Election Data Service Election Data Service Election Data Service Election Data Service Other Services
70. Fluid Applications Respond in real-time to changing conditions Minimize MTTR due to sudden traffic spikes Minimize cost of adapting to traffic events Services can be turned off as a stop-gap
71. Instrumentation Measure every component of the application Measure constantly Record performance to establish trends
72. Instrumentation
73. Self-Healing Applications Applications can self-provision Respond to unexpected performance problem
74. Precision Creates Economy It's not enough to be a good engineer, you have to be cost effective Minimizing infrastructure costs frees up resources for new projects
75. Contact Information @ieatkillerbees samantha@tembies.com Joind.in: https://joind.in/12098