cloud best practices

Cloud Best PracticesEric BOTTARDDeveloper Advocate@ebottard / ebottard@vmware.com

Developer Advocate • VMware

t@ebottardÄericbottard

Eric Bottard

Agenda

10 in theCLOUD

DOsDON’Ts

&

DISCLAIMER

Http TrafficLatency Matters

Where’s the Data Center?

LEARNLots of Literature

DIAGNOSEChrome Dev Tools

YSlowGoogle PageSpeed

FIX !Unique (e.g. hash) Paths

Far Future Expires HeaderMinification

CSS SpritesCDN

Spring ResourceHandler AbstractionWRO4J / RoR Asset Pipeline

FileSystemJust pretend it’s not there

Is your File there? Is it Not?

IT IS THEREBut...

IT’S EPHEMERAL(disappears on restarts)

IT’S NOT SHAREDEither

Use Some Persistent

STORAGE• Mongo GridFS• Database Blob

• External Blob Service

StateIt’s Better Not To Have It

Try to be

STATELESS• Horizontal Scaling• High Availability

• Zero Downtime Deploy

6’6”

6’0”

5’6”

5’0”

4’6”

4’0”

The Usual Suspects

IF there is state

PUSH TO CLIENT(e.g. Cookie, HTML5 apps)

IF there is state

USE CENTRAL SERVICE(e.g. Redis)

IF there is state

MAKE IT PER USER+ Sticky Sessions

DatabasesThey Have A Right To Evolve Too

vmc tunnel (caldecott)$ vmc tunnel

1: foobar-mq2: foobar-pg3: postgresql-handson-cfWhich service instance?> 3

1: none2: psqlWhich client would you like to start?> 2

Opening tunnel on port 10000...

HUMAN.EQUALS(ERROR)(when they simply don’t forget)

YOUR CODE IS VERSIONED*Why isn’t your DB?

* It is, right?

DON’T ROLL YOUR OWN!(and beware of clusters)

Don’t Roll your Own!

MIGRATIONS

Hotel CaliforniaBetter Stay Out of It

Main Risk: Lock InWelcome to the hotel california

Such a lovely place

Such a lovely face

Plenty of room at the hotel california

Any time of year, you can find it here

Last thing I remember, I was

Running for the door

I had to find the passage back

To the place I was before

’relax,’ said the night man,

We are programmed to receive.

You can checkout any time you like,

But you can never leave!

-the Eagles

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"...>

<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">

<constructor-arg ref="mongoDbFactory" /> </bean>

<beans profile="default"> <mongo:db-factory id="mongoDbFactory"

dbname="test" host="127.0.0.1" port="27017" username="foo" password="bar" />

</beans>

<beans profile="cloud"> <cloud:mongo-db-factory id="mongoDbFactory" service-name="myBoundServiceName" /> </beans></beans>

Don’t Code to (any) Cloud!§ Auto-Reconfiguration

§ For the Last 5%• Insulate your Code

• Leverage Frameworks, e.g. Spring Profiles

Beware of Data!

SegregationAll Environments Were Created Equal

Dev vs. Test vs. Staging vs. Prod

Traditional Cloud

Machines Dev ≠ Staging ≠ Prod Identical

Process Manual, inconsistent Automated

People Dev ≠ Ops Devops

One app, Many deploys

Build

Config

Code

Deployment

MANY deploys

ONE set ofdeliverables

“The Twelve Factor App, http://www.12factor.net

Environment Variables [...] unlike custom config files, or other config mechanisms such as Java System Properties, are a language- and OS-agnostic standard

S O AThis time, it’s for real

Do your current apps look like this?

Tomcat

MySQLBrowser Apache.war

“ SOA is like Adam Sandler’s career:Do one thing, and do it well.

Rob Spectre, Developer Evangelism, Twilio

Another way to look at itcut -d" " -f1 < access.log | sort | uniq -c | sort -rn | less

Chances are they will soon look like this..

MySQL

DesktopBrowser

Tomcat

users.war

Tomcat

search.war

Tomcat

orders.war

MongoNativeMobile

App

HTML5 Mobile

App

Node.jsFront End

Message Buse.g. RabbitMQ

Communication

SYNCH vs. ASYNCHe.g. HTTP vs. AMQP

FORMATXML, JSON, PBuffers, Thrift

LOW TECHDatabase + cron

When To Do It?

EARLY ONYAGNI?Slows Progress

NOWWould be a Good Time

LATER ONNow You Need ItHard To Refactor

Spring Integration§ Pipes & Filters Architecture

§ Promotes Loose Coupling• Handles the Plumbing for you

§ Declarative Model

§ Internal & External Messaging

DeployDo It Early & Do It Often

CONTINUOUS INTEGRATIONAutomatic builds, tests

CONTINUOUS DELIVERYCI + automatic deploy

IT’S OKIf it’s not PROD

Automate!<build> <plugins> <plugin> <groupId>org.cloudfoundry</groupId> <artifactId>maven-cf-plugin</artifactId> <version>1.0.0.M4-SNAPSHOT</version> <configuration> <server>mycloudfoundry-instance</server> <target>http://api.cloudfoundry.com</target> <appname>spring-integration-rocks</appname> <url>spring-int-rocks.cloudfoundry.com</url> <memory>1024</memory> <services> <service> <name>mysql-test</name> <vendor>mysql</vendor> </service> <service> <name>mongodb-test</name> <vendor>mongodb</vendor> </service> </services> </configuration> </plugin> </plugins></build>

⊕

ScaleYour own Way

Every app is

DIFFERENT• CPU• RAM• DISK• Bugs

Write your own logic

Use system-level metrics

as well as

business-relatedinfo

$vmc stats myappinstance #0 cpu 0.0% of 2 cores memory 191.6M of 512M disk 15.0M of 2G

http://www.sxc.hu/photo/1128191

Write your own logic

Use Inter-process scaling

$vmc scale myapp \ --instances 3 --memory 1G

as well as

intra-process(thread pools)

UpgradeWith Zero Downtime

Blue/Green Deployment$vmc app awesome awesome: running platform: spring on java usage: 512M × 1 instance urls: awesome.cloudfoundry.com services: postgresql-db

Users LB / Proxy

Version N Version N

Blue/Green Deployment

$vmc push --name awesome_v2 \ --url awesome_secret.cloudfoundry.com

Users LB / Proxy

Version N Version N

Version N+1 Version N+1

Blue/Green Deployment$vmc unmpap awesome awesome.cloudfoundry.com$vmc map awesome_v2 awesome.cloudfoundry.com

Users LB / Proxy

Version N Version N

Version N+1 Version N+1

Variations

1.Have some

(privileged) population

use N+1

2.then roll out

CanaryRelease

Variations

1.Have some share of

the population try

a different version

2.then decide

A|B Testing

What about db changes?

BEFORECode @ Version N

firstnameidPerson

lastnameaddress

TRANSITIONCode @ Version N & N+1

firstnameidPerson

lastnameaddress

person_ididAddress

cityzipcodestreet

country

AFTERCode @ Version N+2

firstnameidPerson

lastnameperson_ididAddress

cityzipcodestreet

country

MIGRATIONS

Limit your Http TrafficThere is no File System

Strive for StatelessnessAutomate your DB Migrations

Avoid Vendor Lock-inTreat all envs as Identical

It’s all about Loose CouplingUse Frequent DeploymentsTargeted and Custom Scaling

Upgrade with Zero Downtime

Thank YouEric Bottard

Developer Advocate • VMware

t@ebottardÄericbottard

ebottard@vmware.com