Upload
eric-bottard
View
801
Download
4
Tags:
Embed Size (px)
Citation preview
Cloud Best PracticesEric BOTTARDDeveloper Advocate@ebottard / [email protected]
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