Computational Patterns of the Cloud - QCon NYC 2014

Computational Patterns of the

CloudQCon NYC 2014

Inés Sombra

Data Engineer

@Randommood

ines@engineyard.com

Continuous Everything

Today’s Agenda

Distributed Systems

Harvesting Services

Reclaimable Resources

Reclaimable ResourcesPattern 1: Where things start

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

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

gordolo.engineyard.com

Pets vs Cattle

vm002.engineyard.com

Both are

adorbs!

Maintain

Cloud resources are Reused

ConsumeProvision

Release

* And things are ”elastic”

Our experience + a few stories

Everything fails.

* At the worst time, for realsies

Excel at ProcessAnticipate failure

and plan for itUse postmortems, checklists, retrospectives, and play-books

Take them seriously

Also know that state can bite

Everything is a recipeInfrastructure is maintained as code

Resources are used to increase the availability & redundancy of applications

“A self service cloud makes

impossible things instant”

@adrianco

Challenges

Importance of Monitoring & Benchmarking

Know your baseline *

Alerting & monitoring are critical

Benchmarking is still misunderstood

What does healthy mean?

Many elements in place to determine health

These visualizations fail us. We need better ones

Complexity is complex

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

Resource families match use casesSome awareness is needed

Cloud resources are different than hardware-based

Capacity planning is tricky

Think about cloud resources in fluid

terms: compute & release

compute with: the cloud as A collection of disposable resources

* Awareness is not optional

Harvesting ServicesPattern 2: We have resources, now let’s leverage services

App Design for the cloud

Surrender the filesystem1

Our app becomes an aggregate of services

2

Consume services via APIs3

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

Our experience + a few stories

Cloud

The monorail that grewUI

Provisioning

API

Billing

Partners

Cloud

The monorail that grewUI

Provisioning

API

Billing

Partners

ui.engineyard.com

Provisioner (Smithy)

API (Core)

Billing (Johnny Cash)

Partners (Tres Fiestas)

The coupling that shouldn’t be

Cloud

UI

Provisioning

API

Billing

Partners

The coupling that shouldn’t be

Provisioner (Smithy)

Cloud

UI

Provisioning

API

Billing

Partners

Challenges

Operational experience can become siloedTeams built around services

Knowledge boundaries

Geographical distribution

Service dependency and failure planning

Difficult to assert health in apps that consume services

Each service it’s its own (smaller) failure domain

Importance of API design,maintenance, & deprecationAPI design is a core business competency

Prioritize maintenance

Retirement will happen

Think about your app as a: collection

of services connected via APIs

compute with: Cloud applications leveraging services

Distributed SystemsPattern 3: Resources + services make distributed systems

as the new norm

It’s a clustered world

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 *

Our experience + a few stories

Availability & Coordination

Failures & latency

Degradation

Dependencies

Find the failing node

Stressing Failures and

adding automation

Serf cluster membershipHomegrown stonith

Challenges

What does it mean to be up?

Distributed systems will break in interesting and painful ways

Know your dependencies

Distributed tracing is necessary

Debugging the “it’s slow” problem sucks

Inherently complex to simulate & test

Awareness of theory Matters

@seancribbs

Distributed systems are the foundation of our infrastructure

& services

compute with: Cloud apps forming distributed systems

Continuous EverythingPattern 4: cloud systems enable continuity

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

Our experience + a few stories

Our continuous Integration

Branches

Pull Requests

Test suites

Merge & deploy

Any prod deploy

Kicks off a suite

Our testing evolutionMaster

PRsKick off a

suite

Dredd TestsSystems,

boundaries, & integration

StacksOS + Our

Image

ScenarioLive setup + assertions

SuiteCollection of

scenarios

Any prod deploy

Kicks off a suite

Our testing evolutionMaster

PRsKick off a

suite

Dredd TestsSystems,

boundaries, & integration

StacksOS + Our

Image

ScenarioLive setup + assertions

SuiteCollection of

scenarios

A r e D a t a b a s e s ?

I n s t a l l i n g

B a c k i n g U p

R e s t o r i n g

S e t t i n g U p R e p l i c a t i o n

P r o m o t i n g R e p l i c a s

W r i t e a b l e

Challenges

Many testing choices. And a random note.Testing is critical and frameworks should help by streamlining choices

Automation helps with process & certifications (SOCS2)

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?

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

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;drthis will save

you 40 minutes

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

Thank you@randommood ines@engineyard.com

github.com/Randommood/Qconnyc2014