Top Banner
Chip Childers | @chipchilders VP Technology | Cloud Foundry Foundation The Architecture of Continuous Innovation
152

The Architecture of Continuous Innovation - OSCON 2015

Aug 14, 2015

Download

Technology

Chip Childers
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: The Architecture of Continuous Innovation - OSCON 2015

Chip Childers | @chipchildersVP Technology | Cloud Foundry Foundation

The Architecture of Continuous

Innovation

Page 2: The Architecture of Continuous Innovation - OSCON 2015

Continuous Innovation

Page 3: The Architecture of Continuous Innovation - OSCON 2015

Application Patterns Are Changing

Page 4: The Architecture of Continuous Innovation - OSCON 2015

Microservices are great.Per Martin Fowler they lead to specific

requirements:

rapid provisioningbasic monitoring

rapid application deploymentdevops culture

Page 5: The Architecture of Continuous Innovation - OSCON 2015
Page 6: The Architecture of Continuous Innovation - OSCON 2015

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

Page 7: The Architecture of Continuous Innovation - OSCON 2015

But even that’s not enough…

Page 8: The Architecture of Continuous Innovation - OSCON 2015

• 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

Page 9: The Architecture of Continuous Innovation - OSCON 2015

Containers Are Awesome, but Not Enough

Page 10: The Architecture of Continuous Innovation - OSCON 2015

Cloud Native Application Platform

Page 11: The Architecture of Continuous Innovation - OSCON 2015

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

Page 12: The Architecture of Continuous Innovation - OSCON 2015

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:

Page 13: The Architecture of Continuous Innovation - OSCON 2015

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)

Page 14: The Architecture of Continuous Innovation - OSCON 2015

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

Page 15: The Architecture of Continuous Innovation - OSCON 2015

Prescriptive Assembly

CH

RO

NO

S

runC

sche

dule

r.nex

t

container.next

Page 16: The Architecture of Continuous Innovation - OSCON 2015

Prescriptive Assembly

CH

RO

NO

S

runC

sche

dule

r.nex

t

gorouter

Clo

ud C

ontr

olle

rAuth

Loggregator

Staging

Buildpacks

BOSH

Service Broker

Diego

LinuxWindowsDocker

etcd

Core Services

container.next

Page 17: The Architecture of Continuous Innovation - OSCON 2015

gorouter

Clo

ud C

ontr

olle

r

Auth

Loggregator

Staging

Buildpacks

BOSH

Service Broker

Diego

LinuxWindowsDocker

etcd

Core Services

Page 18: The Architecture of Continuous Innovation - OSCON 2015

Let’s talk about Diego

??

?

Page 19: The Architecture of Continuous Innovation - OSCON 2015

?

Page 20: The Architecture of Continuous Innovation - OSCON 2015

? DIEGO is

a distributed system that orchestrates containerized

workloads

Page 21: The Architecture of Continuous Innovation - OSCON 2015

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS(currently etcd)

Page 22: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

scheduler

DIEGOa distributed system that orchestrates containerized workloads

Page 23: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

scheduler

DIEGOa distributed system that orchestrates containerized workloads

Page 24: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

scheduler

DIEGOa distributed system that orchestrates containerized workloads

Page 25: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

scheduler

DIEGOa distributed system that orchestrates containerized workloads

Page 26: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

health-monitor

DIEGOa distributed system that orchestrates containerized workloads

Page 27: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

health-monitor

DIEGOa distributed system that orchestrates containerized workloads

Page 28: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

health-monitor

DIEGOa distributed system that orchestrates containerized workloads

Page 29: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

health-monitor

DIEGOa distributed system that orchestrates containerized workloads

Page 30: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

health-monitor

DIEGOa distributed system that orchestrates containerized workloads

Page 31: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

health-monitor

DIEGOa distributed system that orchestrates containerized workloads

Page 32: The Architecture of Continuous Innovation - OSCON 2015

?

Cells

Brain

BBS(currently etcd)

health-monitor

DIEGOa distributed system that orchestrates containerized workloads

Page 33: The Architecture of Continuous Innovation - OSCON 2015

? DIEGO runs

one-off taskslong running processes

a distributed system that orchestrates containerized workloads

Page 34: The Architecture of Continuous Innovation - OSCON 2015

?Taska unit of workruns at most once

DIEGO runsa distributed system that orchestrates containerized workloads

long running processes

Page 35: The Architecture of Continuous Innovation - OSCON 2015

?Task LRPa unit of workruns at most once

N long-running instancesdistributed across cells for HAmonitored & restarted

DIEGO runsa distributed system that orchestrates containerized workloads

Page 36: The Architecture of Continuous Innovation - OSCON 2015

?

generic, platform independent, abstraction

DIEGO runsa distributed system that orchestrates containerized workloads

Task LRP

Page 37: The Architecture of Continuous Innovation - OSCON 2015

?

generic, platform independent, abstraction

DIEGO runsa distributed system that orchestrates containerized workloads

Task LRP

Page 38: The Architecture of Continuous Innovation - OSCON 2015

?

working today

DIEGO runsa distributed system that orchestrates containerized workloads

generic, platform independent, abstraction

Task LRP

Page 39: The Architecture of Continuous Innovation - OSCON 2015

? DIEGO runsa distributed system that orchestrates containerized workloads

successful abstraction

Task LRP

working today

Page 40: The Architecture of Continuous Innovation - OSCON 2015

…confusion

Page 41: The Architecture of Continuous Innovation - OSCON 2015

…confusion

=?

Page 42: The Architecture of Continuous Innovation - OSCON 2015

…confusion

=?

Page 43: The Architecture of Continuous Innovation - OSCON 2015

…confusion

? ?

Page 44: The Architecture of Continuous Innovation - OSCON 2015

isolation

??

??

Page 45: The Architecture of Continuous Innovation - OSCON 2015

isolation

shared resources

kernel

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

??

Page 46: The Architecture of Continuous Innovation - OSCON 2015

isolation

CPU

kernel

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

??

Page 47: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

CPUpr

oces

s A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

??

Page 48: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

CPU

??

Page 49: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

CPU

??

Page 50: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

cgroups

CPU

??

Page 51: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

cgroupspr

oces

s D

proc

ess

E

proc

ess

F

CPU

??

Page 52: The Architecture of Continuous Innovation - OSCON 2015

isolation

shared resources

kernel

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

??

Page 53: The Architecture of Continuous Innovation - OSCON 2015

isolation

kernel

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

ProcessID

??

Page 54: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

??

Page 55: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

??

Page 56: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

??

Page 57: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

PID namespace

??

Page 58: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

PID namespace

??

Page 59: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

PID 2 3 4 2 2 3

PID namespace

??

Page 60: The Architecture of Continuous Innovation - OSCON 2015

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

Ftenant 1 tenant 2 tenant 3

PID

shared resources

kernel

NetworkMountUser

namespaces

??

Page 61: The Architecture of Continuous Innovation - OSCON 2015

=

isolation

User

Network

cgroups

PID

??

??

Page 62: The Architecture of Continuous Innovation - OSCON 2015

?

=

isolation

PID

User

Network

cgroups

??

??

Page 63: The Architecture of Continuous Innovation - OSCON 2015

=

isolation

PID

User

Network

cgroups

+

contents

??

??

Page 64: The Architecture of Continuous Innovation - OSCON 2015

=

isolation

PID

User

Network

cgroups

+

contents

+

processes

??

??

Page 65: The Architecture of Continuous Innovation - OSCON 2015

=??

??

Page 66: The Architecture of Continuous Innovation - OSCON 2015

TasksLRPs

in

??

Page 67: The Architecture of Continuous Innovation - OSCON 2015

TasksLRPs

in Garden

??

Page 68: The Architecture of Continuous Innovation - OSCON 2015

Garden

allows Diego to programmatically say

“make me a container” “put this in it” “then run this”

via a platform-agnostic API

??

Page 69: The Architecture of Continuous Innovation - OSCON 2015

Garden

allows Diego’s abstractions to be flexible

??

Page 70: The Architecture of Continuous Innovation - OSCON 2015

cf push

??

Page 71: The Architecture of Continuous Innovation - OSCON 2015

appsourcecode

Task

staging

cf push??

Page 72: The Architecture of Continuous Innovation - OSCON 2015

cf push

compiled asset

app + app-specific dependencies

assumes a particular execution context

cflinuxfs2

??

Page 73: The Architecture of Continuous Innovation - OSCON 2015

cf push

?

??

Page 74: The Architecture of Continuous Innovation - OSCON 2015

cf push

LRP

??

Page 75: The Architecture of Continuous Innovation - OSCON 2015

cf push

cflinuxfs2

preloaded rootfs

??

Page 76: The Architecture of Continuous Innovation - OSCON 2015

cf push

cflinuxfs2

preloaded rootfs

download droplet

??

Page 77: The Architecture of Continuous Innovation - OSCON 2015

cf push

cflinuxfs2

preloaded rootfs

download droplet

start command

??

Page 78: The Architecture of Continuous Innovation - OSCON 2015

cf push

Droplet LRP{

memory: 128mb,

rootfs: “preloaded:cflinuxfs2”,

setup: <download-droplet>,

run: {metadata}.start-command

}

??

Page 79: The Architecture of Continuous Innovation - OSCON 2015

cf push

Droplet LRP{

memory: 128mb,

rootfs: “preloaded:cflinuxfs2”,

setup: <download-droplet>,

run: {metadata}.start-command

}

??

Page 80: The Architecture of Continuous Innovation - OSCON 2015

cf push

{memory: 128mb,

rootfs: “preloaded:cflinuxfs2”,

setup: <download-droplet>,

run: {metadata}.start-command

}

Droplet LRP

??

Page 81: The Architecture of Continuous Innovation - OSCON 2015

cf push

{memory: 128mb,

rootfs: “preloaded:cflinuxfs2”,

setup: <download-droplet>,

run: {metadata}.start-command

}

Droplet LRP

??

Page 82: The Architecture of Continuous Innovation - OSCON 2015

cf push

??

Page 83: The Architecture of Continuous Innovation - OSCON 2015

cf push-docker

??

Page 84: The Architecture of Continuous Innovation - OSCON 2015

cf push-docker??

Page 85: The Architecture of Continuous Innovation - OSCON 2015

cf push-docker

docker image

??

Page 86: The Architecture of Continuous Innovation - OSCON 2015

cf push-docker

docker image docker metadata

??

Page 87: The Architecture of Continuous Innovation - OSCON 2015

cf push-docker

docker image docker metadata

docker registry

}

??

Page 88: The Architecture of Continuous Innovation - OSCON 2015

Docker LRP

{memory:128mb,

rootfs: “docker://docker-image”,

run: {docker metadata}.start-command

}

cf push-docker??

Page 89: The Architecture of Continuous Innovation - OSCON 2015

cf push-docker

docker image docker metadata

docker registry

}

??

Page 90: The Architecture of Continuous Innovation - OSCON 2015

Docker LRP

{memory:128mb,

rootfs: “docker://docker-image”,

run: {docker metadata}.start-command

}

cf push-docker??

Page 91: The Architecture of Continuous Innovation - OSCON 2015

Docker LRP

{memory:128mb,

rootfs: “docker://docker-image”,

run: {docker metadata}.start-command

}

cf push-docker??

Page 92: The Architecture of Continuous Innovation - OSCON 2015

Docker LRP

{memory:128mb,

rootfs: “docker://docker-image”,

run: {docker metadata}.start-command

}

cf push-docker??

Page 93: The Architecture of Continuous Innovation - OSCON 2015

???

Page 94: The Architecture of Continuous Innovation - OSCON 2015

?

(anything) (anything)

??

Page 95: The Architecture of Continuous Innovation - OSCON 2015

???

Page 96: The Architecture of Continuous Innovation - OSCON 2015

cf push-docker

??

Page 97: The Architecture of Continuous Innovation - OSCON 2015

cf push -stack windows

??

Page 98: The Architecture of Continuous Innovation - OSCON 2015

Garden-Windows

resource isolationkernel job objectdisk quotas

namespace isolationuser profilesHost Web Core(an isolated IIS instance)

Garden-Linux

resource isolationcgroups

namespace isolationPIDNetworkUserMount

??

Page 99: The Architecture of Continuous Innovation - OSCON 2015

collaborating with Microsoft

Garden-Windows

??

Page 100: The Architecture of Continuous Innovation - OSCON 2015

Garden-Windows

provides a container experience for Windows 2012that will only get better with Windows 2016

allows us to build a cf push experience

??

Page 101: The Architecture of Continuous Innovation - OSCON 2015

Garden-Linux Garden-Windows

?

??

Page 102: The Architecture of Continuous Innovation - OSCON 2015

Garden API

??

Page 103: The Architecture of Continuous Innovation - OSCON 2015

.net LRP

{memory: 128mb,

rootfs: “preloaded:windows2012R2”,

setup: <download-application>

run: {metadata}.start-command}

??

Page 104: The Architecture of Continuous Innovation - OSCON 2015

.net LRP

{memory: 128mb,

rootfs: “preloaded:windows2012R2”,

setup: <download-application>

run: {metadata}.start-command}

??

Page 105: The Architecture of Continuous Innovation - OSCON 2015

.net LRP

{memory: 128mb,

rootfs: “preloaded:windows2012R2”,

setup: <download-application>

run: {metadata}.start-command}

??

Page 106: The Architecture of Continuous Innovation - OSCON 2015

.net LRP

{memory: 128mb,

rootfs: “preloaded:windows2012R2”,

setup: <download-application>

run: {metadata}.start-command}

??

Page 107: The Architecture of Continuous Innovation - OSCON 2015

.net LRP

{memory: 128mb,

rootfs: “preloaded:windows2012R2”,

setup: <download-application>

run: {metadata}.start-command}

??

Page 108: The Architecture of Continuous Innovation - OSCON 2015

3 different contexts

??

Page 109: The Architecture of Continuous Innovation - OSCON 2015

1 cluster??

Page 110: The Architecture of Continuous Innovation - OSCON 2015

CloudController

DEA

cf push

stage

DEA

DEA

DEArun

? Current CF Architecture (Simplified)

Page 111: The Architecture of Continuous Innovation - OSCON 2015

CloudControllercf push

stage

run

app-specific generic

?

Page 112: The Architecture of Continuous Innovation - OSCON 2015

CloudControllercf push

stage

run

CCBridge

Cells

BrainBBS

Rec

epto

r AP

I

?

Page 113: The Architecture of Continuous Innovation - OSCON 2015

CloudController

CCBridge

generic consumer

? Cells

BrainBBS

Rec

epto

r AP

I

Page 114: The Architecture of Continuous Innovation - OSCON 2015

CloudController

CCBridge

BrainBBS

generic consumer

other consumers?

? Cells

BrainBBS

Rec

epto

r AP

I

Page 115: The Architecture of Continuous Innovation - OSCON 2015
Page 116: The Architecture of Continuous Innovation - OSCON 2015

Cells

BrainBBS

Task or LRP

Rec

epto

r AP

I

Page 117: The Architecture of Continuous Innovation - OSCON 2015

Cells

BrainBBS

Task or LRP

meh Rec

epto

r AP

I

Page 118: The Architecture of Continuous Innovation - OSCON 2015

Cells

BrainBBS

Task or LRP

gorouter

http traffic

Rec

epto

r AP

I

Page 119: The Architecture of Continuous Innovation - OSCON 2015

Cells

BrainBBS

Task or LRP

gorouter

http traffic

loggregator

logs

Rec

epto

r AP

I

Page 120: The Architecture of Continuous Innovation - OSCON 2015
Page 121: The Architecture of Continuous Innovation - OSCON 2015

vagrant up

Page 122: The Architecture of Continuous Innovation - OSCON 2015

vagrant up

terraform apply

Page 123: The Architecture of Continuous Innovation - OSCON 2015

vagrant up

terraform apply

ltc create <app>

Page 124: The Architecture of Continuous Innovation - OSCON 2015

lattice.cf

Page 125: The Architecture of Continuous Innovation - OSCON 2015

lattice.cf

Local VM

Page 126: The Architecture of Continuous Innovation - OSCON 2015

lattice.cf

Local VM

AWSDigital OceanGoogle Cloud PlatformOpenStack

Page 127: The Architecture of Continuous Innovation - OSCON 2015

?Why

?

Page 128: The Architecture of Continuous Innovation - OSCON 2015

?

CCUAADiegoLoggregatorGorouterBuildpacksServicesBOSH

Page 129: The Architecture of Continuous Innovation - OSCON 2015

?

CCUAADiegoLoggregatorGorouterBuildpacksServicesBOSH

Page 130: The Architecture of Continuous Innovation - OSCON 2015

?

CCUAADiegoLoggregatorGorouterBuildpacksServicesBOSH

Page 131: The Architecture of Continuous Innovation - OSCON 2015

?

CCUAADiegoLoggregatorGorouterBuildpacksServicesBOSH

single-tenant

Page 132: The Architecture of Continuous Innovation - OSCON 2015

?

CCUAADiegoLoggregatorGorouterBuildpacks*ServicesBOSH

dockersingle-tenant

Page 133: The Architecture of Continuous Innovation - OSCON 2015

?

CCUAADiegoLoggregatorGorouterBuildpacks*ServicesBOSH

BYOSdocker

single-tenant

Page 134: The Architecture of Continuous Innovation - OSCON 2015

?

CCUAADiegoLoggregatorGorouterBuildpacks*ServicesBOSH

no rolling upgradesBYOSdocker

single-tenant

Page 135: The Architecture of Continuous Innovation - OSCON 2015

?

?Why

Page 136: The Architecture of Continuous Innovation - OSCON 2015

?

…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…

Page 137: The Architecture of Continuous Innovation - OSCON 2015

WHEN?

Page 138: The Architecture of Continuous Innovation - OSCON 2015

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

Page 139: The Architecture of Continuous Innovation - OSCON 2015

Diego is running in production on PWSManaging ~5% of the load

Page 140: The Architecture of Continuous Innovation - OSCON 2015

Diego is in beta while we

validate performance at O(~100s) of cells

secure Diego’s internal components

Page 141: The Architecture of Continuous Innovation - OSCON 2015

Start using it alongside the DEAs now and give us feedback

Page 142: The Architecture of Continuous Innovation - OSCON 2015

Diego should be out of beta within Q3(probably)

Page 143: The Architecture of Continuous Innovation - OSCON 2015

Then what?

Page 144: The Architecture of Continuous Innovation - OSCON 2015

Placement Constraintstop of backlog post-beta

Page 145: The Architecture of Continuous Innovation - OSCON 2015

cf ssh <app/index>working now, CLI support on the way

shell access, port forwarding, scp

Page 146: The Architecture of Continuous Innovation - OSCON 2015

TCP Routing

Page 147: The Architecture of Continuous Innovation - OSCON 2015

Private Docker Registry

Page 148: The Architecture of Continuous Innovation - OSCON 2015

Support for persistence(a long term goal)

Page 149: The Architecture of Continuous Innovation - OSCON 2015

Container-Container networking(a long term goal)

Page 150: The Architecture of Continuous Innovation - OSCON 2015

Condenserlightweight buildpacks for Lattice

Page 151: The Architecture of Continuous Innovation - OSCON 2015

??

?

Page 152: The Architecture of Continuous Innovation - OSCON 2015

A Cloud Foundry is a place of practice for continuous innovation. noun pragmatic cathedral

Chip Childers | @chipchildersVP Technology | Cloud Foundry Foundation