Cloud Foundry is an open platform as a service that provides choice for development frameworks, services, and deployment targets. It includes options for using Cloud Foundry on public and private clouds as well as for development on a local machine. Cloud Foundry aims to avoid lock-in by being open source and supporting multiple clouds and frameworks.

1. Introduction to Cloud Foundry
for Spring & Java Developers
Eric BOTTARD
Developer Advocate
@ebottard / ebottard@vmware.com

2. Eric Bottard
Developer Advocate • VMware
t@ebottard
Äericbottard

3. Cloud Stack - Classic Pyramid
Software
as a Service
Platform as a Service
Infrastructure as a Service

4. Cloud Foundry – The Open Platform as a Service
Target a choice of
deployment clouds
Provide a choice of Bind a choice of
development application
frameworks services
github.com/cloudfoundry
CONFIDENTIAL

5. CloudFoundry.COM – Multi-Tenant PaaS Operated by
VMware
CloudFoundry.COM (beta)
Frameworks
Services
vCenter / vSphere
Infrastructure

6. Micro Cloud FoundryTM – Cloud on a Stick
Micro Cloud Foundry
Frameworks
Services
Your Laptop/PC
Single VM instance of
Cloud Foundry
that runs on a developer’s
MAC or PC
CONFIDENTIAL

7. CloudFoundry.ORG – Community Open Source Project
CloudFoundry.ORG
Community Frameworks Contributions
Community Services Contributions
Your Infrastructure
Download Setup Tool Chain & Deploy Behind
Code Environment Scripts Firewall
Cloud
Foundry
BOSH
Apache2
license
CONFIDENTIAL

8. CloudFoundry.ORG – Community Open Source Project
github.com/cloudfoundry
§ .NET x 2 § Memcached
§ PHP § SQL Server
§ JRuby § Neo4j
§ Python § CouchDB
§ Rails 2.x § VirtualBox
§ Clojure § Mono
§ Erlang § Rack
§ Haskell
CONFIDENTIAL

9. Main Risk: Lock In
Welcome 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
CONFIDENTIAL

10. Cloud Foundry - Making Multi-Cloud a Reality
Private Cloud Management and Public Cloud
Distributions Deployment Operators
.COM
Bare metal
CONFIDENTIAL

11. Cloud Foundry: Clouds
§ AppFog.com
• community lead for PHP
• PaaS for PHP
§ Joyent
• community lead for Node.js
§ ActiveState
• community lead for Python, Perl
• Providers of Stackato private PaaS
CONFIDENTIAL

12. Demos

13. VCAP_*
VCAP_APP_HOST = 192.168.1.13
VCAP_APP_PORT = 58121
VCAP_SERVICES =
{
"redis-2.2": [
{
"name": "my-redis-service",
"label": "redis-2.2",
"plan": "free",
"tags": [
"key-value",
"nosql",
"redis-2.2",
"redis"
],
"credentials": {
"hostname": "127.0.0.1",
"host": "127.0.0.1",
"port": 5000,
"password": "ce7b483f-66d1-436d-8aa7-7c33a9ee31ac",
"name": "e740add8-24ce-40f5-94ed-8a2623e0be57"
}
}
],
"postgresql-9.0": [...]
}
13

14. Auto-reconfiguration
§ Works for Spring, Node, Ruby
§ Spring: Uses a BeanFactoryPostProcessor
under the hood
• adds a jar to your app
• modifies web.xml to load the BFPP
• also adds correct jdbc driver jar
§ Only works if no ambiguity (80% of apps)
• One service of a kind
CONFIDENTIAL

15. Production Grade Cloud Foundry Clusters
§ 500 – 5,000 VMs cloudfoundry.com
§ 40+ unique node types
§ 75+ unique software packages
§ 75+ unique environments
§ 2x/week cf.com updates
§ 24x7x365 non-stop operation
§ No-downtime deployments
§ Reliable, robust, repeatable
deployments, updates, capacity
adjustments
§ Small teams manage many
production, staging, stress, qa, dev
instances
Google style problem è Google style solution
CONFIDENTIAL

16. Cloud Foundry BOSH
§ Cloud Foundry BOSH is an open source tool-chain for release
engineering, deployment, and lifecycle management of large scale
distributed services
• Prescriptive way of creating releases and managing systems and services
• It is not a collection of shell scripts, not a pile of Perl
§ Built to deploy and manage production-class, large scale clusters
• Production grade Cloud Foundry clusters: 500+ VMs, 40+ jobs, 75+ packages
• Multi-node, multi-tier, complex clusters: e.g., our Gerrit/Jenkins Cluster
§ Built for devops usage and scale by a crack team of veterans
• A project, not a product: command line interface, YAML, etc.
• Continuous improvement, iterative development, rough edges
github.com/cloudfoundry/bosh
CONFIDENTIAL

17. Key Takeaways
§ PaaS is the application platform for the Cloud era
§ Cloud Foundry is the Industry’s Open PaaS
• Developer agility
• Portability without changes
• Open system
§ What’s next?
• Free Signup: www.cloudfoundry.com (use “cloudtoday” as a promocode)
• Get started: docs.cloudfoundry.com/getting-started.html
• Learn more on the blog: blog.cloudfoundry.com
• Download your Micro Cloud Foundry: my.cloudfoundry.com/micro
• Get the source code: www.cloudfoundry.org
• Follow us: @cloudfoundry
• Watch us: www.youtube.com/cloudfoundry
CONFIDENTIAL

18. Cloud Best Practices
Eric BOTTARD
Developer Advocate
@ebottard / ebottard@vmware.com

19. Eric Bottard
Developer Advocate • VMware
t@ebottard
Äericbottard

20. Agenda
10
DOs &
DON’Ts
in the
CLOUD

21. DISCLAIMER

22. CAPTAIN OBVIOUS! t-shirt available at threadless.com
Design by Nathan Stillie and Joshua Kemble

24. Http Traffic
Latency Matters

25. Where’s the Data Center?

26. Where’s the Data Center?

27. LEARN
Lots of Literature

28. DIAGNOSE
Chrome Dev Tools
YSlow
Google PageSpeed

29. FIX !
Unique (e.g. hash) Paths
Far Future Expires Header
Minification
CSS Sprites
CDN
Spring ResourceHandler Abstraction
WRO4J / RoR Asset Pipeline

30. FileSystem
Just pretend it’s not there

31. Is your File there? Is it Not?

32. Is your File there? Is it Not?

33. IT IS THERE
But...

34. IT’S EPHEMERAL
(disappears on restarts)

35. IT’S NOT SHARED
Either

36. Use Some Persistent
STORAGE

37. Use Some Persistent
STORAGE
• Mongo GridFS

38. Use Some Persistent
STORAGE
• Mongo GridFS
• Database Blob

39. Use Some Persistent
STORAGE
• Mongo GridFS
• Database Blob
• External Blob Service

40. State
It’s Better Not To Have It

41. Try to be
STATELESS

42. Try to be
STATELESS
• Horizontal Scaling

43. Try to be
STATELESS
• Horizontal Scaling
• High Availability

44. Try to be
STATELESS
• Horizontal Scaling
• High Availability
• Zero Downtime Deploy

45. The Usual Suspects

46. The Usual Suspects
6’6”
6’0”
5’6”
5’0”
4’6”
4’0”

47. The Usual Suspects
6’6”
6’0”
5’6”
5’0”
4’6”
4’0”

48. The Usual Suspects
6’6”
6’0”
5’6”
5’0”
4’6”
4’0”

49. The Usual Suspects
6’6”
6’0”
5’6”
5’0”
4’6”
4’0”

50. The Usual Suspects

51. IF there is state
PUSH TO CLIENT
(e.g. Cookie, HTML5 apps)

52. IF there is state
USE CENTRAL SERVICE
(e.g. Redis)

53. IF there is state
MAKE IT PER USER
+ Sticky Sessions

54. Databases
They Have A Right To Evolve Too

55. vmc tunnel (caldecott)
$ vmc tunnel
1: foobar-mq
2: foobar-pg
3: postgresql-handson-cf
Which service instance?> 3
1: none
2: psql
Which client would you like to start?> 2
Opening tunnel on port 10000...

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

57. YOUR CODE IS VERSIONED*
Why isn’t your DB?
* It is, right?

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

59. Don’t Roll your Own!
MIGRATIONS

60. Hotel California
Better Stay Out of It

61. Main Risk: Lock In
Welcome 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

62. Don’t Code to (any) Cloud!

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

64. Don’t Code to (any) Cloud!
§ Auto-Reconfiguration
§ For the Last 5%
• Insulate your Code
• Leverage Frameworks, e.g. Spring Profiles
<?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>

65. Beware of Data!

66. Segregation
All Environments Were Created Equal

67. Dev vs. Test vs. Staging vs. Prod

69. Traditional Cloud
Dev ≠ Staging
Machines Identical
≠ Prod
Manual,
Process Automated
inconsistent
People Dev ≠ Ops Devops

70. Traditional Cloud
Dev ≠ Staging
Machines Identical
≠ Prod
Manual,
Process Automated
inconsistent
People Dev ≠ Ops Devops

71. Traditional Cloud
Dev ≠ Staging
Machines Identical
≠ Prod
Manual,
Process Automated
inconsistent
People Dev ≠ Ops Devops

72. Traditional Cloud
Dev ≠ Staging
Machines Identical
≠ Prod
Manual,
Process Automated
inconsistent
People Dev ≠ Ops Devops

73. One app, Many deploys
Code Build
Deployment
Config

74. One app, Many deploys
of
ONE set
les
deliverab
Code Build
Deployment
Config

75. One app, Many deploys
of
ONE set
les
deliverab
Code Build
Deployment
Config
ploys
MANY de

76. “ Environment Variables [...] unlike custom config
files, or other config mechanisms such as Java
System Properties, are a language- and OS-
agnostic standard
The Twelve Factor App, http://www.12factor.net

77. SOA
This time, it’s for real

78. Do your current apps look like this?
Tomcat
.war
Browser Apache MySQL

80. “ SOA is like Adam Sandler’s career:
Do one thing, and do it well.
Rob Spectre, Developer Evangelism,
Twilio

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

82. Chances are they will soon look like this..
Tomcat
search.
war
Desktop
Browser
Tomcat
Native users.
Node.js Message Bus war Mongo
Mobile
Front End e.g. RabbitMQ
App
HTML5
Mobile
App
Tomcat
orders.
war MySQL

83. Communication

84. SYNCH vs. ASYNCH
e.g. HTTP vs. AMQP

85. FORMAT
XML, JSON, PBuffers, Thrift

86. LOW TECH
Database + cron

87. When To Do It?

88. EARLY ON
YAGNI?
Slows Progress

89. NOW
Would be a Good Time

90. LATER ON
Now You Need It
Hard To Refactor

91. Spring Integration
§ Pipes & Filters Architecture
§ Promotes Loose Coupling
• Handles the Plumbing for you
§ Declarative Model
§ Internal & External Messaging

92. Deploy
Do It Early & Do It Often

94. CONTINUOUS INTEGRATION
Automatic builds, tests

95. CONTINUOUS DELIVERY
CI + automatic deploy

96. IT’S OK
If it’s not PROD

97. 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>

98. Scale
Your own Way

99. Every app is
DIFFERENT

100. Every app is
DIFFERENT
• CPU

101. Every app is
DIFFERENT
• CPU
• RAM

102. Every app is
DIFFERENT
• CPU
• RAM
• DISK

103. Every app is
DIFFERENT
• CPU
• RAM
• DISK
• Bugs

104. Write your own logic
http://www.sxc.hu/photo/1128191

105. Write your own logic
Use system-level metrics
http://www.sxc.hu/photo/1128191

106. Write your own logic
Use system-level metrics
$vmc stats myapp
instance #0
cpu 0.0% of 2 cores
memory 191.6M of 512M
disk 15.0M of 2G
http://www.sxc.hu/photo/1128191

107. Write your own logic
Use system-level metrics
$vmc stats myapp
instance #0
cpu 0.0% of 2 cores
memory 191.6M of 512M
disk 15.0M of 2G
as well as
business-related
info
http://www.sxc.hu/photo/1128191

108. Write your own logic
Use Inter-process scaling

109. Write your own logic
Use Inter-process scaling
$vmc scale myapp
--instances 3
--memory 1G

110. Write your own logic
Use Inter-process scaling
$vmc scale myapp
--instances 3
--memory 1G
as well as
intra-process
(thread pools)

111. Upgrade
With Zero Downtime

112. Blue/Green Deployment

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

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

115. Blue/Green Deployment
Version N Version N
Users LB / Proxy

116. Blue/Green Deployment
$vmc push --name awesome_v2
--url awesome_secret.cloudfoundry.com
Version N Version N
Users LB / Proxy

117. Blue/Green Deployment
$vmc push --name awesome_v2
--url awesome_secret.cloudfoundry.com
Version N Version N
Users LB / Proxy
Version N+1 Version N+1

118. Blue/Green Deployment
Version N Version N
Users LB / Proxy
Version N+1 Version N+1

119. Blue/Green Deployment
$vmc unmpap awesome awesome.cloudfoundry.com
$vmc map awesome_v2 awesome.cloudfoundry.com
Version N Version N
Users LB / Proxy
Version N+1 Version N+1

120. Blue/Green Deployment
$vmc unmpap awesome awesome.cloudfoundry.com
$vmc map awesome_v2 awesome.cloudfoundry.com
Version N Version N
Users LB / Proxy
Version N+1 Version N+1

121. Blue/Green Deployment
$vmc unmpap awesome awesome.cloudfoundry.com
$vmc map awesome_v2 awesome.cloudfoundry.com
Version N Version N
Users LB / Proxy
Version N+1 Version N+1

122. Variations
Canary
Release

123. Variations
1.Have some
(privileged) population Canary
use N+1 Release

124. Variations
1.Have some
(privileged) population Canary
use N+1 Release
2.then roll out

125. Variations
A|B
Testing

126. Variations
1.Have some share of
the population try A|B
a different version Testing

127. Variations
1.Have some share of
the population try A|B
a different version Testing
2.then decide

128. What about db
changes?

129. BEFORE
Code @ Version N
Person
id
firstname
lastname
address

130. TRANSITION
Code @ Version N & N+1
Person Address
id id
firstname person_id
lastname street
address zipcode
city
country

131. AFTER
Code @ Version N+2
Person Address
id id
firstname person_id
lastname street
zipcode
city
country

132. MIGRATIONS

133. Limit your Http Traffic
There is no File System
Strive for Statelessness
Automate your DB Migrations
Avoid Vendor Lock-in
Treat all envs as Identical
It’s all about Loose Coupling
Use Frequent Deployments
Targeted and Custom Scaling
Upgrade with Zero Downtime

134. Thank You
Eric Bottard
Developer Advocate • VMware
t@ebottard
Äericbottard
ebottard@vmware.com