Computational Patterns of the Cloud - QCon NYC 2014

The Cloud has undoubtedly changed the way we think about computing, IT operations, innovation, and entrepreneurship. But what are the computational patterns that have emerged from the pervasiveness of public clouds? What can we leverage to improve our organizations? And what are the challenges that we face going forward?

In this talk, I will introduce you to cloud computing’s paradigms and discuss their applications with practical examples from Engine Yard’s customers, peers, and partners. We will also cover antipatterns and myths. If you are curious about Cloud computing or want to improve your cloud strategy this talk is for you.

NOTE: Open an issue if you want me to explain something in more detail at the accompanying github repo: https://github.com/Randommood/QConNYC2014/

Transcript

1. Computational Patterns of the Cloud QCon NYC 2014
2. Inés Sombra Data Engineer @Randommood ines@engineyard.com
4. Continuous Everything Today’s Agenda Distributed Systems Harvesting Services Reclaimable Resources
5. Reclaimable Resources Pattern 1: Where things start
6. Pre-Cloud Applications We have an application ready for deployment Ticket to request resources ( budgets ) Procurement Roll to production 
 on a hand-crafted server Maintenance Uptime Burden
7. Cloud Applications We have an application ready for deployment Provision servers on demand (via APIs) & 
 deploy to production Maintenance ( for used resources only) Pay Uptime Burden
8. gordolo.engineyard.com Pets vs Cattle vm002.engineyard.com Both are adorbs!
9. Maintain Cloud resources are Reused Consume Provision Release * And things are ”elastic”
10. Our experience + a few stories
11. Everything fails. * At the worst time, for realsies
12. Excel at Process Anticipate failure and plan for it Use postmortems, checklists, retrospectives, and play-books Take them seriously Also know that state can bite
13. Everything is a recipe Infrastructure is maintained as code Resources are used to increase the availability & redundancy of applications “A self service cloud makes impossible things instant” @adrianco
14. Challenges
15. Importance of 
 Monitoring & Benchmarking Know your baseline * Alerting & monitoring are critical Benchmarking is still misunderstood
16. What does 
 healthy mean? Many elements in place to determine health These visualizations fail us. We need better ones Complexity is complex
17. What does 
 healthy mean? Many elements in place to determine health These visualizations fail us. We need better ones Complexity is complex Instance provisioned? IaaS Firewalls set up? IaaS Chef succeeded? PaaS Volumes provisioned? IaaS Process running? Role Replica up? PaaS
18. Resource families match use cases Some awareness is needed Cloud resources are different than hardware- based Capacity planning is tricky
19. Think about cloud resources in fluid terms: compute & release compute with: the cloud as A collection of disposable resources * Awareness is not optional
20. Harvesting Services Pattern 2: We have resources, now let’s leverage services
21. App Design for the cloud Surrender the filesystem 1 Our app becomes an aggregate of services 2 Consume services via APIs 3
22. Service oriented architecture NoSQL Distilled: Fowler & Sadalage My awesome e-commerce site Shopping cart & session data Completed orders Inventory and item pricing Session Storage service K/V Store Order Persistence service Document Store Inventory & Price service RDBMS Nodes and relations service Graph Store Recommendations engine
23. Our experience + a few stories
24. Cloud The monorail that grew UI Provisioning API Billing Partners
25. Cloud The monorail that grew UI Provisioning API Billing Partners ui.engineyard.com Provisioner (Smithy) API (Core) Billing (Johnny Cash) Partners (Tres Fiestas)
26. The coupling that shouldn’t be Cloud UI Provisioning API Billing Partners
27. The coupling that shouldn’t be Provisioner (Smithy) Cloud UI Provisioning API Billing Partners
28. Challenges
29. Operational experience can become 
 siloed Teams built around services Knowledge boundaries Geographical distribution
30. Service 
 dependency and failure planning Difficult to assert health in apps that consume services Each service it’s its own (smaller) failure domain
31. Importance of API design,
 maintenance, & deprecation API design is a core business competency Prioritize maintenance Retirement will happen
32. Think about your app as a: collection of services connected via APIs compute with: Cloud applications leveraging services
33. Distributed Systems Pattern 3: Resources + services make distributed systems as the new norm
34. It’s a clustered world
35. with properties & constraints * Tip: Read `Distributed systems and the end of the API in references Distributed systems exhibit a set of uniformly unintuitive behaviors related to causality, consistency, and availability *
36. Our experience + a few stories
37. Availability & 
 Coordination Failures & latency Degradation Dependencies
38. Find the failing node Stressing Failures and adding automation Serf cluster membership Homegrown stonith
39. Challenges
40. What does it 
 mean to be up? Distributed systems will break in interesting and painful ways Know your dependencies
41. Distributed tracing is necessary Debugging the “it’s slow” problem sucks Inherently complex to simulate & test
42. Awareness of theory Matters @seancribbs
43. Distributed systems are the foundation of our infrastructure & services compute with: Cloud apps forming distributed systems
44. Continuous Everything Pattern 4: cloud systems enable continuity
45. CD and the importance of tests Are they fast? Can we trust them? What coverage do we have? What type of tests? * Don’t ignore their maintenance Tests 
 are critical
46. Our experience + a few stories
47. Our continuous Integration Branches Pull Requests Test suites Merge & deploy
48. Any prod deploy Kicks off a suite Our testing evolution Master PRs Kick off a suite Dredd Tests Systems, boundaries, & integration Stacks OS + Our Image Scenario Live setup + assertions Suite Collection of scenarios
49. Any prod deploy Kicks off a suite Our testing evolution Master PRs Kick off a suite Dredd Tests Systems, boundaries, & integration Stacks OS + Our Image Scenario Live setup + assertions Suite Collection of scenarios Are Dat a bas es ? I nst al l ing B a cki ng Up Re stor ing Setti ng Up Re p li c ation P ro m ot ing Re p li c as Wr ite a b le
50. Challenges
51. Many testing choices. And a random note. Testing is critical and frameworks should help by streamlining choices Automation helps with process & certifications (SOCS2)
52. All planning tools suck Stop thinking that a tool will fix your agile problems Continuous delivery can make flaws in goals & direction obvious. Is your vision clear?
53. Cloud-based apps, resources, and services enable agility compute with: Cloud (resources, apps, services) as continuous * “The bottleneck is never code or creativity; it's lack of clarity.”Scott Berkun
54. Quickly provision resources & release them when they are not needed Reclaimable Resources Leverage services to simplify areas of responsibility in our app Harvesting services Theoretical foundation as a core competency for correctness Distributed Systems The holy grail. Will reshape your company & make everything awesome Continuous Delivery tl;dr this will save you 40 minutes
55. Cloud computing next “…This is how cloud computing will continue to evolve. Developers will worry less about the thousands of machines needed to run their application and more about the design of the application itself.” Eric Brewer
56. Thank you @randommood 
 ines@engineyard.com github.com/Randommood/Qconnyc2014