Cloud foundry: The Platform for Forging Cloud Native Applications
-
Upload
chip-childers -
Category
Technology
-
view
1.017 -
download
3
Transcript of Cloud foundry: The Platform for Forging Cloud Native Applications
@chipchilders
Chip Childers, VP Technology
Cloud Foundry Foundation
The Platform for Forging Cloud Native
Applications
Since 2000, 52% of the Fortune
500 are no longer on the list
Continuous Innovation
Right-sizing digital innovation
Focused on cycle time optimization
Smaller teams and faster tools
Continuous
Integration
Continuous
Deployment
Continuous
Innovation
Continuous
Integration
Continuous
Deployment
Continuous
Innovation
waterscrumfall
Continuous
Integration
Continuous
Deployment
Continuous
Innovation
“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
Two-pizza teams
Silo-breaking
Ephemeral
Scalable
Agile
Microservices
Containers
12-Factor Applications
Microservices are great, but they require:
rapid provisioning
basic monitoring
rapid application deployment
devops culture
Per Martin Fowler
• 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.
But even that’s not enough…
• 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
Containers Are Awesome, but Not Enough
We’re going to need a platform
Is BASH a platform?
Is config mgmt with $YOURFAVTOOL?
Borg
Mesos
Cloud
Foundry
Omega
Kubernetes
cgroups
Docker
OCI
rkt/appc
LXC
Carrier Networking
Datacenter Networking
Datacenter Operating Systems
Hardware
Virtualization
Operating Systems
Application Platforms
Programming Frameworks
ContainersOpen Container
Initiative
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)
Platforms make promises
Constraints are the contract that
allows a platform to keep
promises
Here is my source code
Run it on the cloud for me
I do not care how
Cloud Foundry Haiku
Onsi Fakhouri
.war .jar
dependencies
libraries
service manifest
App App App
LB
DB
Multi-server run time environment(s)
.tar.gz
Turning this: Into this:
• 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
target <mycf>
push <myapp>
create-service <myservice>
bind <myapp> <myservice>
start <myapp>
scale <myapp> -i 100
…
cf
App
DB
LB
App App
Where’s the container in this
story?
Prescriptive
CH
RO
NO
S
sch
edu
ler.
nex
t
container.next
Assembly
Prescriptive
CH
RO
NO
S
sch
edu
ler.
nex
t
container.next
Assembly
runC
Prescriptive
CH
RO
NO
S
sch
edu
ler.
nex
t
gorouter
Clo
ud
Co
ntr
olle
rAuth
Loggregator
Staging
Buildpacks
BOSH
Service Broker
Diego
Garden
etcd
Core
Services
container.next
Assembly
runC
Prescriptive Assembly
CH
RO
NO
S
sch
edu
ler.
nex
t
gorouter
Clo
ud
Co
ntr
olle
rAuth
Loggregator
Staging
Buildpacks
BOSH
Service Broker
Diego
etcd
Core
Services
container.nextrunC
= + +
Contents Processes
??
Isolation Rules
PID
User
Network
cgroups cflinuxfs2
Anatomy of a cf push (abridged)
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
That was all about 12 factor
apps…
What about services?
.war .jar
dependencies
libraries
service manifest
App App App
LB
DB
Multi-server run time environment(s)
.tar.gz
Turning this: Into this:
Demo time!
The Cloud Native Advantage:
Simple Patterns
Highly Automated
Scaled with Ease
A platform is a promise that the products will function in ways beyond what’s “written on the box”; that the product is extensible and has value provided by an ecosystem bigger than the original vendor.
Horace Dediu, 2011http://www.asymco.com/2011/02/25/the-platform-as-a-promise/
We’re rebalancing the system towards user-driven
roadmaps and control of the upstream project.
We’re building support for specific industry
clusters in Financial Services, Industrial IoT, and
Telecommunications.
We’re focusing on certification to guarantee
portability of apps across clouds.
Make it lasting and durable.
Build the ecosystem of opportunity.
cfsummit.com
@chipchilders
Learn more at cloudfoundry.org
Thanks.