This document summarizes a presentation about computational patterns in the cloud. It discusses four key patterns: reclaimable resources, where cloud applications provision resources on demand and release them when not needed; harvesting services, where applications consume external services via APIs rather than maintaining standalone components; distributed systems, where resources and services come together to form distributed systems as the new norm; and continuous everything, where the cloud enables continuous delivery, deployment, and testing practices. The document provides examples and stories about implementing these patterns and discusses challenges organizations may face in adopting cloud-native approaches.

1. Computational
Patterns of the
Cloud
QCon NYC 2014

2. Inés
SombraData 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
ConsumeProvision
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?
PaaSVolumes
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 filesystem1
Our app becomes an
aggregate of services
2
Consume services via APIs3

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 membershipHomegrown 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 Databas es?
Inst al l ing
Ba cki ng Up
Re stor ing
Setti ng Up
Re p li c ation
Pro 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