For many years, the gold standard of business strategy has been the mantra “Sustainable competitive advantage.” But the world has changed. Moving forward, the mantra for survival must be “Continuous innovation.” In this talk, I will take the audience inside the architectural foundation of a modern cloud native platform. I’ll walk through the tools they’ll use to deliver on the promise of continuous innovation — tools such as Docker, Lattice, Puppet, and Cloud Foundry. And I’ll show examples of how to use those tools to deliver the speed and portability businesses need to thrive in a cloud native world.

1. Chip Childers | @chipchilders
VP Technology | Cloud Foundry Foundation
The Architecture of Continuous
Innovation

2. Continuous Innovation

3. Application Patterns Are Changing

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

6. • Use declarative formats for setup automation, to minimize time and
cost for new developers joining the project;
• Have a clean contract with the underlying OS, 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.

7. But even that’s not enough…

8. • 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

9. Containers Are Awesome, but Not Enough

10. Cloud Native Application Platform

11. Platforms on Platforms
• 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

12. 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:

13. 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)

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

15. Prescriptive Assembly
CHRONOS
runC
scheduler.next
container.next

16. Prescriptive Assembly
CHRONOS
runC
scheduler.next
gorouter
CloudController Auth
Loggregator
Staging
Buildpacks
BOSH
Service Broker
Diego
Linux
Windows
Docker
etcd
Core
Services
container.next

17. gorouter
CloudController
Auth
Loggregator
Staging
Buildpacks
BOSH
Service Broker
Diego
Linux
Windows
Docker
etcd
Core
Services

18. Let’s talk about Diego
?
?
?

19. ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35. ?
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

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

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

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

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

40. …confusion

41. …confusion
=
?

42. …confusion
=
?

43. …confusion
? ?

44. isolation
?
?
?
?

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

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

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

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

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

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

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

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

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

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

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

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

57. 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
?
?

58. 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
?
?

59. 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
?
?

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

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

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

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

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

65. =?
?
?
?

66. Tasks
LRPs
in
?
?

67. Tasks
LRPs
in Garden
?
?

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

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

70. cf push
?
?

71. app
source
code
Task
staging
cf push?
?

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

73. cf push
?
?
?

74. cf push
LRP
?
?

75. cf push
cflinuxfs2
preloaded rootfs
?
?

76. cf push
cflinuxfs2
preloaded rootfs
download droplet
?
?

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

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

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

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

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

82. cf push
?
?

83. cf push-docker
?
?

84. cf push-docker?
?

85. cf push-docker
docker image
?
?

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

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

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

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

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

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

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

93. ?
?
?

94. ?
(anything) (anything)
?
?

95. ?
?
?

96. cf push-docker
?
?

97. cf push -stack windows
?
?

98. 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
?
?

99. collaborating with Microsoft
Garden-Windows
?
?

100. 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
?
?

101. Garden-Linux Garden-Windows
?
?
?

102. Garden API
?
?

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

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

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

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

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

108. 3 different contexts
?
?

109. 1 cluster
?
?

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

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

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

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

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

116. Cells
BrainBBS
Task or LRP
ReceptorAPI

117. Cells
BrainBBS
Task or LRP
meh
ReceptorAPI

118. Cells
BrainBBS
Task or LRP
gorouter
http traffic
ReceptorAPI

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

121. vagrant up

122. vagrant up
terraform apply

123. vagrant up
terraform apply
ltc create <app>

124. lattice.cf

125. lattice.cf
Local VM

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

127. ?Why
?

128. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks
Services
BOSH

129. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks
Services
BOSH

130. ?
CC
UAA
Diego
Loggregator
Gorouter
Buildpacks
Services
BOSH

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

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

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

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

135. ?
?Why

136. ?
…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…

137. WHEN?

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

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

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

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

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

143. Then what?

144. Placement Constraints
top of backlog post-beta

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

146. TCP Routing

147. Private Docker Registry

148. Support for persistence
(a long term goal)

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

150. Condenser
lightweight buildpacks for Lattice

151. ?
?
?

152. A Cloud Foundry is a place of practice for continuous innovation.
noun pragmatic cathedral
Chip Childers | @chipchilders
VP Technology | Cloud Foundry Foundation