This document discusses key aspects of cloud native applications and platforms. It notes there is consensus around cloud native traits like containers, microservices, platform independence, and automation. Cloud Foundry is presented as a platform that can deploy and manage cloud native applications by providing automated scaling, routing, service integration, and other capabilities through declarative configuration. The platform handles tasks like detecting application frameworks, linking to services, self-service deployment, routing, versioning, upgrades, scaling, and more through simple commands. This allows developers to focus on their code while the platform manages the complex runtime environment.

1. @chipchilders
Chip Childers, VP Technology
Cloud Foundry Foundation
Going Cloud Native with Cloud Foundry

2. Why does Cloud Native matter?

3. Since 2000, 52% of the Fortune
500 are no longer on the list

4. Continuous Innovation

5. There is a rough consensus on many Cloud Native traits.
Containers as an atomic unit, for example. Micro-services
as the means of both construction and communication.
Platform independence. Multiple language support.
Automation as a feature of everything from build to
deployment. High uptime. Ephemeral infrastructure (cattle
not pets). And so on.
Stephen O’Grady, Redmonk
http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

6. There is a rough consensus on many Cloud Native traits.
Containers as an atomic unit, for example. Micro-services
as the means of both construction and communication.
Platform independence. Multiple language support.
Automation as a feature of everything from build to
deployment. High uptime. Ephemeral infrastructure (cattle
not pets). And so on.
Stephen O’Grady, Redmonk
http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

7. There is a rough consensus on many Cloud Native traits.
Containers as an atomic unit, for example. Micro-services
as the means of both construction and communication.
Platform independence. Multiple language support.
Automation as a feature of everything from build to
deployment. High uptime. Ephemeral infrastructure (cattle
not pets). And so on.
Stephen O’Grady, Redmonk
http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

8. There is a rough consensus on many Cloud Native traits.
Containers as an atomic unit, for example. Micro-services
as the means of both construction and communication.
Platform independence. Multiple language support.
Automation as a feature of everything from build to
deployment. High uptime. Ephemeral infrastructure (cattle
not pets). And so on.
Stephen O’Grady, Redmonk
http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

9. There is a rough consensus on many Cloud Native traits.
Containers as an atomic unit, for example. Micro-services
as the means of both construction and communication.
Platform independence. Multiple language support.
Automation as a feature of everything from build to
deployment. High uptime. Ephemeral infrastructure (cattle
not pets). And so on.
Stephen O’Grady, Redmonk
http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

10. There is a rough consensus on many Cloud Native traits.
Containers as an atomic unit, for example. Micro-services
as the means of both construction and communication.
Platform independence. Multiple language support.
Automation as a feature of everything from build to
deployment. High uptime. Ephemeral infrastructure (cattle
not pets). And so on.
Stephen O’Grady, Redmonk
http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

11. There is a rough consensus on many Cloud Native traits.
Containers as an atomic unit, for example. Micro-services
as the means of both construction and communication.
Platform independence. Multiple language support.
Automation as a feature of everything from build to
deployment. High uptime. Ephemeral infrastructure (cattle
not pets). And so on.
Stephen O’Grady, Redmonk
http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

12. The Cloud Native Advantage:
Simple Patterns
Highly Automated
Scaled with Ease

13. Fast, Safe, Scalable… Pick 3

14. Fast – Focus on Takt Time
Definition: the desired time between units of production output, synchronized
to customer demand
http://www.strategosinc.com/takt_time.htm

15. Safe
A.B.T. - Always Be Testing (automatically)

16. Safe – Runtime Characteristics Matter
• Visibility – Measure all the things. Translate data into knowledge. (see:
OODA loop)
• Fault Isolation – Smaller applications, released independently, isolate the
scope of a fault condition.
• Fault Tolerance – Failures happen (see: Circuit Breaker Pattern / Design
for Failure)
• Autonomic Recovery – Humans have better things to do at night

17. Scale – Prepare (as best you can) to Succeed
• Demand elastic infrastructure
• Separate concerns - Isolated ephemeral services, Solve persistence
independently
• Accept that the scalability of a system can be a series of plateaus

19. “Any organization that designs
a system (defined broadly) will
produce a design whose
structure is a copy of the
organization's communication
structure.
Melvyn Conway, 1967

20. Microservices are great, but they require:
rapid provisioning
basic monitoring
rapid application deployment
devops culture
Martin Fowler

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

23. But even that’s not enough…

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

25. You must be this tall…

26. We’re going to need a platform

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

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

29. Platforms make promises
Constraints are the contract that
allows a platform to keep
promises

30. Here is my source code
Run it on the cloud for me
I do not care how
Cloud Foundry Haiku
Onsi Fakhouri

32. .war .jar
dependencies
libraries
service manifest
App App App
LB
DB
Multi-server run time
environment(s)
.tar.gz
Turning this: Into this:

33. https://blog.appdynamics.com/devops/the-future-of-ops/
Or even this…

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

35. target <mycf>
push <myapp>
create-service <myservice>
bind <myapp> <myservice>
start <myapp>
scale <myapp> -i 100
…
cf
App
DB
LB
App App

36. Where’s the container in this
story?

38. = + +
Contents Processes
?
?
Isolation Rules
PID
User
Network
cgroups cflinuxfs2
What is a “Container”?

39. Let’s talk about Buildpacks / Staging
• Ruby code that detects language,
frameworks, whatnot…
• Compiles the code into executable
binaries (*)
/bin/detect < Am I supposed to run?
/bin/compile < Build the thing
/bin/release < Pass along potential metadata
cflinuxfs2

40. Prescriptive
CHRONOS
scheduler.next
container.next
Assembly

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

42. Prescriptive
CHRONOS
scheduler.next
gorouter
CloudController Auth
Loggregator
Staging
Buildpacks
BOSH
Service Broker
Diego
Garden
etcd
Core
Services
container.next
Assembly
runC

43. Prescriptive Assembly
CHRONOS
scheduler.next
gorouter
CloudController Auth
Loggregator
Staging
Buildpacks
BOSH
Service Broker
Diego
etcd
Core
Services
container.nextrunC

44. That was all about 12 factor
apps…
What about services?

45. CF and Services
- Development infrastructure components
(DBs, Cache, Queue, etc…)
- Loopback to other CF hosted apps
- Reaching out to your “legacy”
- External providers

48. .war .jar
dependencies
libraries
service manifest
App App App
LB
DB
Multi-server run time
environment(s)
.tar.gz
Turning this: Into this:

49. The Cloud Native Advantage:
Simple Patterns
Highly Automated
Scaled with Ease

50. cloudfoundry.org