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