Discussion of the market context for Cloud Foundry and a walkthrough of the Diego project.

1. Chip Childers - @chipchilders
Cloud Foundry Foundation
The Making of a
Modern Application Architecture

2. Chip Childers - @chipchilders
Cloud Foundry Foundation
The Making of a
Modern Application Architecture
Cloud Native Application Platform

3. The Dawn of a New Era

4. A shift in business matching
the shift in human behavior

5. Continuous Innovation

6. waterscrumfall

7. PAIR
cloud native applications
WITH
continuous delivery of business value

8. Continuous Innovation

10. Containers Automation Cluster Management

11. Carrier Networking
Datacenter Networking
Datacenter Operating Systems
Hardware
Virtual Machines
Operating Systems
Application Platforms
Programming Frameworks
Containers

12. Cloud Native Application Platform

13. When IaaS and App Platforms Come Together
• Better SLAs
• Flexibility
• Speed
• Availability
• Faster Time To Market
• Mobile + Data
Services
• Agile and Iterative
• Leverage OSS
• Continuous Delivery
• No Downtime
• Instant scaling
• Consistency &
Automation
App Dev App OpsIaaS

14. Unit of Value
IaaS == Virtual Machine
• Opaque to the system
• Orchestration is post-hoc
• System changes are imperative
(“launch” stuff)
App Platform == Application
• Containers are transparent
• Lifecycle is fully managed
• System changes are
declarative (manifest.yml)

15. Understanding Cloud Native Application Platforms
.war .jar
dependencies
libraries
service manifest
App App App
LB
DB
Multi-server run time
environment(s)
.tar.gz
Turning this: Into this:

16. Removing Developer and Operational Constraints
BUILD
APPLICATION
PUSH FIRST
RELEASE
MAINTAIN
APPLICATION
UPDATE
APPLICATIONS
RETIRE
APPLICATIONS
• Auto-detect frameworks
• Link to App Platform
• Self-service deploy
• Dynamic routing
• A/B versioning
• Live upgrades
• Self-service
removal
• Elastic scale
• Integrated HA
• Log aggregation
• Policy and Auth

17. Application Patterns Are Changing

18. Microservices are great.
Per Martin Fowler they lead to specific requirements:
rapid provisioning
basic monitoring
rapid application deployment
devops culture

20. • Use declarative formats for setup automation, to minimize time and
cost for new developers joining the project;
• Have a clean contract with the underlying operating system, offering
maximum portability between execution environments;
• Are suitable for deployment on modern cloud platforms, obviating the
need for servers and systems administration;
• Minimize divergence between development and production, enabling
continuous deployment for maximum agility;
• And can scale up without significant changes to tooling, architecture,
or development practices.

21. But even that’s not enough…

22. • Role based access to resources: the right
people should be able to do things and the
wrong people shouldn’t
• Run specified bits on demand: take code, put
it together with all the rest of the things it
needs and and get it running
• Coordinate cross service configurations: in a
service oriented world, services need to be
configured to connect with each other
• Route public requests to running bits: the
next big thing needs access to the internet
• Read and write persistent data: data has to
live somewhere
• Add and remove resources: scaling is a great
problem to have, but still
• Isolate resources and failures without
isolation and decoupling, that is one big
distributed single point of failure
• Measure performance/health: can’t manage
what you don’t measure
• Detect and determine failure: sometimes,
things get real… but how do you know
• Recover failures: someone is going to have
to clean this mess
• Work tomorrow: when everything you’ve
thought to be true has been shown not to

23. Containers Alone Are Not Enough

24. Cloud Native Application Platform

26. A Cloud Foundry is a place of practice for continuous innovation.
noun pragmatic cathedral
We give you the technology to create the place, and we
assemble the wisdom of the community to create the practices.

27. Yeah, yeah, get to the technical bit

30. And now I’ll attempt to impersonate Onsi Fakhouri…
Slides stolen borrowed with permission.
Everybody thank @onsijoe

31. Let’s talk about Diego
?
?
?

32. ?

33. ? DIEGO is
a distributed system that orchestrates
containerized workloads

34. ? DIEGO
a distributed system that orchestrates containerized workloads
Cells
Brain
BBS
(currently etcd)

35. ?
Cells
Brain
BBS
(currently etcd)
scheduler
DIEGO
a distributed system that orchestrates containerized workloads

36. ?
Cells
Brain
BBS
(currently etcd)
scheduler
DIEGO
a distributed system that orchestrates containerized workloads

37. ?
Cells
Brain
BBS
(currently etcd)
scheduler
DIEGO
a distributed system that orchestrates containerized workloads

38. ?
Cells
Brain
BBS
(currently etcd)
scheduler
DIEGO
a distributed system that orchestrates containerized workloads

39. ?
Cells
Brain
BBS
(currently etcd)
health-monitor
DIEGO
a distributed system that orchestrates containerized workloads

40. ?
Cells
Brain
BBS
(currently etcd)
health-monitor
DIEGO
a distributed system that orchestrates containerized workloads

41. ?
Cells
Brain
BBS
(currently etcd)
health-monitor
DIEGO
a distributed system that orchestrates containerized workloads

42. ?
Cells
Brain
BBS
(currently etcd)
health-monitor
DIEGO
a distributed system that orchestrates containerized workloads

43. ?
Cells
Brain
BBS
(currently etcd)
health-monitor
DIEGO
a distributed system that orchestrates containerized workloads

44. ?
Cells
Brain
BBS
(currently etcd)
health-monitor
DIEGO
a distributed system that orchestrates containerized workloads

45. ?
Cells
Brain
BBS
(currently etcd)
health-monitor
DIEGO
a distributed system that orchestrates containerized workloads

46. ?
Cells
Brain
BBS
(currently etcd)
health-monitor
DIEGO
a distributed system that orchestrates containerized workloads

47. ? DIEGO runs
one-off tasks
long running
processes
a distributed system that orchestrates containerized workloads

48. ?
Task
a unit of work
runs at most once
DIEGO runs
a distributed system that orchestrates containerized workloads
long running
processes

49. ?
Task LRP
a unit of work
runs at most once
N long-running instances
distributed across cells for HA
monitored & restarted
DIEGO runs
a distributed system that orchestrates containerized workloads

50. ?
generic, platform independent, abstraction
DIEGO runs
a distributed system that orchestrates containerized workloads
Task LRP

51. ?
generic, platform independent, abstraction
DIEGO runs
a distributed system that orchestrates containerized workloads
Task LRP

52. ?
working today
DIEGO runs
a distributed system that orchestrates containerized workloads
generic, platform independent, abstraction
Task LRP

53. ? DIEGO runs
a distributed system that orchestrates containerized workloads
successful abstraction
Task LRP
working today

54. …confusion

55. …confusion
=
?

56. …confusion
? ?

57. …confusion
?

58. isolation
?
?
?
?

59. isolation
shared resources
processA
processB
processC
processD
processE
processF
kernel
tenant 1 tenant 2 tenant 3
?
?

60. isolation
shared resources
kernel
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
?
?

61. isolation
CPU
kernel
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
?
?

62. isolation
resource isolation
namespace isolation
CPU
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
?
?

63. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
CPU
?
?

64. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
CPU
?
?

65. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
cgroups
CPU
?
?

66. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
cgroups
processD
processE
processF
CPU
?
?

67. isolation
shared resources
kernel
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
?
?

68. isolation
kernel
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
ProcessID
?
?

69. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
PID 2 3 4 5 6 7
?
?

70. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
PID 2 3 4 5 6 7
?
?

71. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
PID 2 3 4 5 6 7
?
?

72. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
PID 2 3 4 5 6 7
PID namespace
?
?

73. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
PID 2 3 4 5 6 7
PID namespace
?
?

74. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
PID 2 3 4 2 2 3
PID namespace
?
?

75. isolation
resource isolation
namespace isolation
processA
processB
processC
processD
processE
processFtenant 1 tenant 2 tenant 3
PID
shared resources
kernel
Network
Mount
User
namespaces
?
?

76. ?
?
?
?

77. =
isolation
User
Network
cgroups
PID
?
?
?
?

78. =
isolation
PID
User
Network
cgroups
?
?
?
?

79. =
isolation
PID
User
Network
cgroups
+
contents
?
?
?
?

80. =
isolation
PID
User
Network
cgroups
+
contents
+
processes
?
?
?
?

81. =?
?
?
?

82. Tasks
LRPs
in
?
?

83. Tasks
LRPs
in Garden
?
?

84. Garden
allows Diego to programmatically say
“make me a container” “put this in it” “then run this”
via a platform-agnostic API
?
?

85. Garden
allows Diego’s abstractions to be flexible
?
?

86. cf push
?
?

87. app
source
code
Task
staging
cf push?
?

88. cf push
compiled asset
app + app-specific dependencies
assumes a particular execution context
cflinuxfs2
?
?

89. cf push
?
?
?

90. cf push
LRP
?
?

91. cf push?
?

92. cf push
cflinuxfs2
preloaded rootfs
?
?

93. cf push
cflinuxfs2
preloaded rootfs
download droplet
?
?

94. cf push
cflinuxfs2
preloaded rootfs
download droplet
start command
?
?

95. cf push
Droplet LRP
{
memory: 128mb,
rootfs: “preloaded:cflinuxfs2”,
setup: <download-droplet>,
run: {metadata}.start-command
}
?
?

96. cf push
Droplet LRP
{
memory: 128mb,
rootfs: “preloaded:cflinuxfs2”,
setup: <download-droplet>,
run: {metadata}.start-command
}
?
?

97. cf push
{
memory: 128mb,
rootfs: “preloaded:cflinuxfs2”,
setup: <download-droplet>,
run: {metadata}.start-command
}
Droplet LRP
?
?

98. cf push
{
memory: 128mb,
rootfs: “preloaded:cflinuxfs2”,
setup: <download-droplet>,
run: {metadata}.start-command
}
Droplet LRP
?
?

99. cf push
?
?

100. cf push-docker
?
?

101. cf push-docker?
?

102. cf push-docker
docker image
?
?

103. cf push-docker
docker image docker metadata
?
?

104. cf push-docker
docker image docker metadata
docker registry
}
?
?

105. Docker LRP
{
memory:128mb,
rootfs: “docker://docker-image”,
run: {docker metadata}.start-command
}
cf push-docker?
?

106. cf push-docker
docker image docker metadata
docker registry
}
?
?

107. Docker LRP
{
memory:128mb,
rootfs: “docker://docker-image”,
run: {docker metadata}.start-command
}
cf push-docker?
?

108. Docker LRP
{
memory:128mb,
rootfs: “docker://docker-image”,
run: {docker metadata}.start-command
}
cf push-docker?
?

109. Docker LRP
{
memory:128mb,
rootfs: “docker://docker-image”,
run: {docker metadata}.start-command
}
cf push-docker?
?

110. ?
?
?

111. ?
(anything) (anything)
?
?

112. ?
?
?

113. ?
appc
?
?

114. cf push-docker
?
?

115. cf push -stack windows
?
?

116. Garden-Windows
resource isolation
kernel job object
disk quotas
namespace isolation
user profiles
Host Web Core
(an isolated IIS instance)
Garden-Linux
resource isolation
cgroups
namespace isolation
PID
Network
User
Mount
?
?

117. collaborating with Microsoft
Garden-Windows
?
?

118. Garden-Windows
provides a container experience for Windows 2012
that will only get better with Windows 2016
allows us to build a cf push experience
?
?

119. Garden-Linux Garden-Windows
?
?
?

120. Garden API
?
?

121. .net LRP
{
memory: 128mb,
rootfs: “preloaded:windows2012R2”,
setup: <download-application>
run: {metadata}.start-command
}
?
?

122. .net LRP
{
memory: 128mb,
rootfs: “preloaded:windows2012R2”,
setup: <download-application>
run: {metadata}.start-command
}
?
?

123. .net LRP
{
memory: 128mb,
rootfs: “preloaded:windows2012R2”,
setup: <download-application>
run: {metadata}.start-command
}
?
?

124. .net LRP
{
memory: 128mb,
rootfs: “preloaded:windows2012R2”,
setup: <download-application>
run: {metadata}.start-command
}
?
?

125. .net LRP
{
memory: 128mb,
rootfs: “preloaded:windows2012R2”,
setup: <download-application>
run: {metadata}.start-command
}
?
?

126. 3 different contexts
?
?

127. 1 cluster
?
?

128. Cloud
Controller
DEA
cf push
stage
DEA
DEA
DEA
run
? Current CF Architecture (Simplified)

129. Cloud
Controllercf push
stage
run
app-specific generic
?

130. Cloud
Controllercf push
stage
run
CC
Bridge
Cells
BrainBBS
ReceptorAPI
?

131. Cloud
Controller
CC
Bridge
generic consumer
?
Cells
BrainBBS
ReceptorAPI

132. Cloud
Controller
CC
Bridge
BrainBBS
generic consumer
other consumers?
?
Cells
BrainBBS
ReceptorAPI

134. Cells
BrainBBS
Task or LRP
ReceptorAPI

135. Cells
BrainBBS
Task or LRP
meh
ReceptorAPI

136. Cells
BrainBBS
Task or LRP
gorouter
http traffic
ReceptorAPI

137. Cells
BrainBBS
Task or LRP
gorouter
http traffic
loggregator
logs
ReceptorAPI

139. vagrant up

140. vagrant up
terraform apply

141. vagrant up
terraform apply
ltc create <app>

142. lattice.cf

143. lattice.cf
Local VM

144. lattice.cf
Local VM
AWS
Digital Ocean
Google Cloud Platform
OpenStack

145. ?Why
?

146. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks
Services
BOSH

147. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks
Services
BOSH

148. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks
Services
BOSH

149. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks
Services
BOSH
single-tenant

150. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks*
Services
BOSH
docker
single-tenant

151. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks*
Services
BOSH
BYOS
docker
single-tenant

152. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks*
Services
BOSH
no rolling upgrades
BYOS
docker
single-tenant

153. ?
?Why

154. ?
…is a useful low-barrier solution to real-world
problems
…makes exploring Diego easy
…is a softer onramp to the CF tech stack
…allows us to efficiently prototype new ideas for
Diego’s future
Lattice…

155. WHEN?

156. “rewrite the DEA”
Diego’s scope is much more than

157. Diego is running in production on PWS
Managing ~5% of the load

158. Diego is in beta while we
validate performance at O(~100s) of cells
secure Diego’s internal components

159. Start using it alongside the DEAs now
and give us feedback

160. Diego should be out of beta within Q3
(probably)

161. Then what?

162. Placement Constraints
top of backlog post-beta

163. cf ssh <app/index>
working now, CLI support on the way
shell access, port forwarding, scp

164. TCP Routing

165. Private Docker Registry

166. Support for persistence
(a long term goal)

167. Container-Container networking
(a long term goal)

168. Condenser
lightweight buildpacks for Lattice

169. That was Diego…
?
?
?

170. cloudfoundry.org : @chipchilders
A Cloud Foundry is a place of practice for continuous innovation.
noun pragmatic cathedral