Talk at the Boston Cloud Foundry Meetup June 2015

Chip Childers - @chipchildersCloud Foundry Foundation

The Making of a

Modern Application Architecture

Chip Childers - @chipchildersCloud Foundry Foundation

The Making of a

Modern Application Architecture

Cloud Native Application

Platform

The Dawn of a New Era

A shift in business matchingthe shift in human behavior

Continuous Innovation

waterscrumfall

PAIR

cloud native applicationsWITH

continuous delivery of business value

Continuous Innovation

Containers Automation Cluster Management

Carrier Networking

Datacenter Networking

Datacenter Operating Systems

Hardware

Virtual Machines

Operating Systems

Application Platforms

Programming Frameworks

Containers

Cloud Native Application Platform

When IaaS and App Platforms Come Together

• 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

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)

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:

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

Application Patterns Are Changing

Microservices are great.Per Martin Fowler they lead to specific

requirements:

rapid provisioningbasic monitoring

rapid application deploymentdevops culture

• Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;

• Have a clean contract with the underlying operating system, 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 Alone Are Not Enough

Cloud Native Application Platform

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

We give you the technology to create the place, and we assemble the wisdom of the community to create the

practices.

Yeah, yeah, get to the technical bit

And now I’ll attempt to impersonate Onsi Fakhouri…

Slides stolen borrowed with permission.

Everybody thank @onsijoe

Let’s talk about Diego

??

?

? DIEGO is

a distributed system that orchestrates containerized

workloads

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS(currently etcd)

?

Cells

Brain

BBS(currently etcd)

scheduler

DIEGOa distributed system that orchestrates containerized workloads

?

Cells

Brain

BBS(currently etcd)

health-monitor

DIEGOa distributed system that orchestrates containerized workloads

? DIEGO runs

one-off taskslong running processes

a distributed system that orchestrates containerized workloads

?Taska unit of workruns at most once

DIEGO runsa distributed system that orchestrates containerized workloads

long running processes

?Task LRPa unit of workruns at most once

N long-running instancesdistributed across cells for HAmonitored & restarted


?

generic, platform independent, abstraction


Task LRP

?

working today


generic, platform independent, abstraction

Task LRP

? DIEGO runsa distributed system that orchestrates containerized workloads

successful abstraction

Task LRP

working today

…confusion

…confusion

=?

…confusion

? ?

…confusion

?

isolation

??

??

isolation

shared resources

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess

F

kernel

tenant 1 tenant 2 tenant 3

??

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

??

isolation

CPU

kernel

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


??

isolation

resource isolation

namespace isolation

CPUpr

oces

s A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


??

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


CPU

??

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


cgroups

CPU

??

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


cgroupspr

oces

s D

proc

ess

E

proc

ess

F

CPU

??

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


??

isolation

kernel

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


ProcessID

??

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


PID 2 3 4 5 6 7

??

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


PID 2 3 4 5 6 7

PID namespace

??

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


PID 2 3 4 2 2 3

PID namespace

??

isolation

resource isolation

namespace isolation

proc

ess

A

proc

ess

B

proc

ess

C

proc

ess

D

proc

ess

E

proc

ess


PID

shared resources

kernel

NetworkMountUser

namespaces

??

??

??

=

isolation

User

Network

cgroups

PID

??

??

?

=

isolation

PID

User

Network

cgroups

??

??

=

isolation

PID

User

Network

cgroups

+

contents

??

??

=

isolation

PID

User

Network

cgroups

+

contents

+

processes

??

??

=??

??

TasksLRPs

in

??

TasksLRPs

in Garden

??

Garden

allows Diego to programmatically say

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

via a platform-agnostic API

??

Garden

allows Diego’s abstractions to be flexible

??

cf push

??

appsourcecode

Task

staging

cf push??

cf push

compiled asset

app + app-specific dependencies

assumes a particular execution context

cflinuxfs2

??

cf push

?

??

cf push

LRP

??

cf push??

cf push

cflinuxfs2

preloaded rootfs

??

cf push

cflinuxfs2

preloaded rootfs

download droplet

??

cf push

cflinuxfs2

preloaded rootfs

download droplet

start command

??

cf push

Droplet LRP{

memory: 128mb,

rootfs: “preloaded:cflinuxfs2”,

setup: <download-droplet>,

run: {metadata}.start-command

}

??

cf push

{memory: 128mb,

rootfs: “preloaded:cflinuxfs2”,

setup: <download-droplet>,

run: {metadata}.start-command

}

Droplet LRP

??

cf push

??

cf push-docker

??

cf push-docker??

cf push-docker

docker image

??

cf push-docker

docker image docker metadata

??

cf push-docker


docker registry

}

??

Docker LRP

{memory:128mb,

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

run: {docker metadata}.start-command

}

cf push-docker??

cf push-docker


docker registry

}

??

Docker LRP

{memory:128mb,

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

run: {docker metadata}.start-command

}

cf push-docker??

?

(anything) (anything)

??

?

appc

??

cf push-docker

??

cf push -stack windows

??

Garden-Windows

resource isolationkernel job objectdisk quotas

namespace isolationuser profilesHost Web Core(an isolated IIS instance)

Garden-Linux

resource isolationcgroups

namespace isolationPIDNetworkUserMount

??

collaborating with Microsoft

Garden-Windows

??

Garden-Windows

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

allows us to build a cf push experience

??

Garden-Linux Garden-Windows

?

??

Garden API

??

.net LRP

{memory: 128mb,

rootfs: “preloaded:windows2012R2”,

setup: <download-application>

run: {metadata}.start-command}

??

3 different contexts

??

1 cluster??

CloudController

DEA

cf push

stage

DEA

DEA

DEArun

? Current CF Architecture (Simplified)

CloudControllercf push

stage

run

app-specific generic

?

CloudControllercf push

stage

run

CCBridge

Cells

BrainBBS

Rec

epto

r AP

I

?

CloudController

CCBridge

generic consumer

? Cells

BrainBBS

Rec

epto

r AP

I

CloudController

CCBridge

BrainBBS

generic consumer

other consumers?

? Cells

BrainBBS

Rec

epto

r AP

I

Cells

BrainBBS

Task or LRP

Rec

epto

r AP

I

Cells

BrainBBS

Task or LRP

meh Rec

epto

r AP

I

Cells

BrainBBS

Task or LRP

gorouter

http traffic

Rec

epto

r AP

I

Cells

BrainBBS

Task or LRP

gorouter

http traffic

loggregator

logs

Rec

epto

r AP

I

vagrant up

vagrant up

terraform apply

vagrant up

terraform apply

ltc create <app>

lattice.cf

lattice.cf

Local VM

lattice.cf

Local VM

AWSDigital OceanGoogle Cloud PlatformOpenStack

?Why

?

?

CCUAADiegoLoggregatorGorouterBuildpacksServicesBOSH

?

CCUAADiegoLoggregatorGorouterBuildpacksServicesBOSH

single-tenant

?

CCUAADiegoLoggregatorGorouterBuildpacks*ServicesBOSH

dockersingle-tenant

?


BYOSdocker

single-tenant

?


no rolling upgradesBYOSdocker

single-tenant

?

?Why

?

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

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

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

Diego is in beta while we

validate performance at O(~100s) of cells

secure Diego’s internal components

Start using it alongside the DEAs now and give us feedback

Diego should be out of beta within Q3(probably)

Then what?

Placement Constraintstop of backlog post-beta

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

shell access, port forwarding, scp

TCP Routing

Private Docker Registry

Support for persistence(a long term goal)

Container-Container networking(a long term goal)

Condenserlightweight buildpacks for Lattice

That was Diego…

??

?

cloudfoundry.org : @chipchilders

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

Talk at the Boston Cloud Foundry Meetup June 2015

Technology

Transcript of Talk at the Boston Cloud Foundry Meetup June 2015