Platform Clouds, Containers, Immutable Infrastructure Oh My!

150
PLATFORM CLOUDS, CONTAINERS, IMMUTABLE INFRA, OH MY! 1 Stuart Charlton

Transcript of Platform Clouds, Containers, Immutable Infrastructure Oh My!

PLATFORM CLOUDS, CONTAINERS,

IMMUTABLE INFRA, OH MY!

1

Stuart Charlton

2

YOUR HOST

2

Stuart Charlton @svrc

Pivotal Software, my dream company

Led IT Ops & Cloud Architectureat a Railway (long story)

Former CTO of an early, tragically executed startup

Assistant in the destruction of the global economy while on Wall Street

ex-BMC, BEA, Rogers, Infusion

PRIOR TO TAKEOFF

• There are many opinions, these are mine

• Some nuance emphasized, some lost

• There will be pictures of nude containers

• There will be digging into Cloud Foundry

3

WHY WE ARE HERE

Software is Hard4

AND YET…

• amazon.com

• Mean time between deployments: 11.6s (in 2011, it’s better now)

• Max deployments in a single hour: 1,079

• Mean hosts receiving a deploy: 10,000

• Max hosts receiving a deploy: 30,000

5

WHY WE ARE HERE• All businesses are software businesses

or losing to one that is

• Demands are getting “impossible” (Mobile, IoT)

• We keep making the same mistakes

• We must deploy at scale quickly and safely

• We (devs/ops) must reclaim our lives from the mess we’ve made

6

THERE’S A LOT OF CONFUSION OUT THERE• Hopefully this talk gives a useful roadmap

• Where do things fit, how things “sort of” work

• Be able to call bullshit on statements like…

• X is going to take over the world

• It’s game over for Y

• This one weird trick is all you need7

CLAIMS• The current trend of the IT industry is to

forcefully eliminate IT operations as we traditionally know it*

• Stop feeding blood to the machines

• Stop sweating over config/change management

• Evolving from toolchains to platforms

• Leverage: Instead of “operating” software, we build and maintain software that operates the software

• *inspired by the professional movements in devops, microservices, continuous delivery; provocative wording borrowed from Todd Underwood (Google) and his PostOps LISA 2013 talk

8

SO?• We all have operating platforms

• Not everyone’s platform is great

• What makes a platform good?

• Patterns and Constraints in Context

• Encourages good architecture

• Opinionated, not free form

• Will you build your own, or join a community? 9

THIS TALK• Let’s design a cloud native platform

• Just these easy steps…

• Interlude: Two philosophies of systems

• Converged and Immutable

• Interlude: What’s in a Container?

• Containers, Docker, Droplets

• Interlude: Schedulers for Fun and Profit

• Cloud Foundry Diego

• Combining this all into Cloud Native Platforms

• Designing for Cloud Native 10

LET’S DESIGN A CLOUD NATIVE PLATFORM

In the time allotted We Hope

11

WHAT PROBLEM ARE WE TRYING TO SOLVE?

12

FOLLOW THE THOUGHT CHAIN

• Some people started solving problem X and then moved to problem Y

13

FOLLOW THE MONEY

• Some people tried to solve problem X, found it hard to sell or get funding, moved to problem Y

• This can occur up or down the value chain

14

2001-2006WE HAVE TOO MANY

SERVERS TO PROVISION, CONFIG,

INSTALL15

1. CONVERGENT CONFIG MANAGEMENT

• Aka “These Scripts Need to Grow Up”

16

Model&Oriented Action&Oriented

• Focused on single server config

2006-2010CLOUDS ARE FORMED, MORE THINGS TO DO

• Assume you have an Infrastructure Cloud

• Servers, Networks, Storage, Disks

• On Demand, Fungible Resources

• Many nuances & details here matter but we need to punt on them today

17

2. CLOUD ORCHESTRATION

• Make the clouds sing

• “I need X disk attached to Y compute on Z network”

18

Cloud Formation / HEATTerraform / BOSH

DAWN OF TIME-2015 “I HATE MY PACKAGE

MANAGER”• Slow, versioning, dependencies, hard to

build, hard to share, etc.

• I know, I’ll build a new package manager!

19

3. VARIOUS UNITS OF SHARE, INSTALL, DEPLOY• There are basically six types

• Deployment Artifact

• OS Package Installer

• OS Container

• Tarball/ZIP

• VM Image

• Composite Release20

WHAT’S IN A PACKAGE STANDARD?

• File System Format

• Metadata

• Build Script

• Registry

• Dependencies

• Metadata

• Processes21

COMPARING PACKAGES

22

Droplet VM Image DockerFile System Tarball Block Tarball deltasMetadata YES OVA YESBuild Script Buildpack Various DockerfileRegistry Droplet Reg Various Docker RegDependencies NOPE NOPE NOPEProcesses YES OVA YES

WHAT DOCKER GOT RIGHT AS A PACKAGE

• Vendor your dependencies

• Make sharing fast (copy-on-write / deltas)

• Make launching fast (OS containers)

• Enable social sharing of full runtimes (Docker hub)

• A cross-distro “swiss army knife” package23

WHAT DROPLETS GOT RIGHT AS A PACKAGE

• Droplets: Heroku / Cloud Foundry

• Vendor your dependencies

• Make updating fast (deltas of your dev artifacts)

• Make launching fast (OS virtualization)

• Awesome developer experience (standard build/deploy in 60 sec that still uses your familiar artifacts) 24

DOCKER IS HERE, LET’S GO HOME?

25

OPEN QUESTIONS• Do you want to run just any Docker image?

• Opaque contents are a nightmare to maintain

• Opaque contents are a nightmare to secure

• Performance with layered Union FS

• Containers are successful in production with theproper constraints

26

INTERLUDE 2:TWO PHILOSOPHIES

• Converged Config Managers were created before clouds were a big deal

• Definitely before containers were a big deal

• Didn’t really have ability to config clouds (they do now)

• Clouds changed some assumptions on how we treat servers

27

TRADITIONAL INFRA

• “collection of pets”

• pet them, hug them, love them, name them after Lord of the Rings characters

• upgrade them when they die

28

CLOUD INFRA

• Fungible, ephemeral minions

• Fast to start up and dispose

29

CONVERGED CONFIG

• Phoenix servers, should be able to re-create

• In practice, lots of silent dependencies

• Day 2? Each evolution requires tinkering on the manifests & scripts

• Constraints, opinions are up to the user

30

IMMUTABLE INFRA• Immutable by contract, not fully

• s/immutable/(disposable | prefabricated)/

• e.g. assume these things never change, and if they do, kill them

• Ops tinkering happens in the build

• Ops pipeline rarely changes,just deploy new stuff

• Use load balancer / router for control 31

BOSH:A PLATFORM FOR COMPOSITE PACKAGES +

DISPOSABLE SERVERS

32

IF A CONTAINER IS A PACKAGE,

WHAT’S IN A CONTAINER?

33

?

?

isolation

?

? isolationshared resources

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

kernel

tenant 1 tenant 2 tenant 3

? isolationshared resources

kernelresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

? isolationCPUkernel

resource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

? isolationresource isolation

namespace isolation

CPU

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

CPU

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

CPU

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

cgroups

CPU

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

cgroupspr

oces

s D

proc

ess

Epr

oces

s F

CPU

? isolationshared resources

kernelresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

? isolation

kernelresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

ProcessID

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

PID namespace

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

PID namespace

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

PID 2 3 4 2 2 3

PID namespace

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

PID

shared resourceskernel

NetworkMountUser

namespaces

?

?

?

? =isolation

User

Network

cgroups

PID

? isolationresource isolation

namespace isolation

proc

ess

Apr

oces

s B

proc

ess

Cpr

oces

s D

proc

ess

Epr

oces

s F

tenant 1 tenant 2 tenant 3

PID 2 3 4 5 6 7

?

?

? =isolation

PIDUser

Network

cgroups

?

? =isolation

PIDUser

Network

cgroups

+contents

?

? =isolation

PIDUser

Network

cgroups

+contents

+processes

?

? =

?Problem 4:How do I run these containers at scale, safely?

Schedulers

?

DIEGO

? DIEGO is

a distributed system that orchestrates containerized workloads

? DIEGO is

a distributed system that orchestrates containerized workloads

? DIEGO is

a distributed system that orchestrates containerized workloads

? DIEGO is

a distributed system that orchestrates containerized workloads

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

scheduler

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

scheduler

? DIEGOa distributed system that orchestrates containerized workloads

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

Cells

Brain

BBS (currently etcd)

health-monitor

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

health-monitor

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

health-monitor

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

health-monitor

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

health-monitor

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

health-monitor

? DIEGOa distributed system that orchestrates containerized workloads

Cells

Brain

BBS (currently etcd)

health-monitor

? DIEGO runsa distributed system that orchestrates containerized workloads

one-off tasks long running processes

? DIEGO runsa distributed system that orchestrates containerized workloads

Task LRPgeneric, platform independent, abstraction

? DIEGO runsa distributed system that orchestrates containerized workloads

Task LRPgeneric, platform independent, abstraction

? DIEGO runsa distributed system that orchestrates containerized workloads

Task LRP

working today

generic, platform independent, abstraction

? DIEGO runsa distributed system that orchestrates containerized workloads

Task LRPsuccessful abstraction

working today

?

TasksLRPs in Garden

?Cloud Foundry Garden

allows you 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

?

cf push haiku

here is my source code

i do not care howrun it on the cloud for me

?

appsourcecode

Task

staging

cf push

? cf push

buildpack compiled assetapp + app-specific dependencies

assumes a particular execution contextcflinuxfs2

? 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

?

cf push-docker

? cf push-docker

? cf push-docker

docker image

? cf push-docker

docker image docker metadata

? cf push-docker

docker image docker metadata

docker registry

}

? cf push-docker

docker image docker metadata

docker registry

}

? ?

? ?

(anything)

? ?

(anything)

? ?

(anything) (anything)

? ?

(anything) (anything)

? ?

? ?

appc

?

cf push-docker

?

cf push -stack windows

?Garden-Windows

resource isolation kernel job object disk quotas

namespace isolation user profiles Host Web Core (an isolated IIS instance)

Garden-Linux

resource isolation cgroups

namespace isolation PID Network User Mount

?

collaborating with Microsoft

Garden-Windows

?

Garden-Windows

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

allows us to build a cf push experience

?

3 different contexts

? 1 cluster

2015+CONTAINER MUD

WRESTLING• Schedulers abound!

• Mesos, Kubernetes, Cloud Foundry Diego

• Deis, Flynn, Dokku, etc

• How does one choose?

116

5. STRUCTURED PLATFORMS AND FRAMEWORKS

• ie. something that will encourage good architecture and operational constraints

• Don’t do undifferentiated heavy lifting

• Be productive right away

• Join a community making these design decisions together 117

Cells

BrainBBS

Rece

ptor

API

Task or LRP

Cells

BrainBBS

Rece

ptor

API

Task or LRP

meh

Cells

BrainBBSRe

cept

or A

PI

Task or LRP

gorouter

http traffic

Cells

BrainBBSRe

cept

or A

PI

Task or LRP

gorouter

http traffic

loggregator

logs

vagrant up

vagrant up

terraform apply

vagrant up

terraform apply

ltc create <app>

lattice.cf

lattice.cf

Local VM

lattice.cf

Local VMAWS Digital Ocean Google Cloud Platform OpenStack (thanks!)

+ BOSH Multi-Tenant API Single Sign On Capacity & Performance Mgt Service Brokerage Service Marketplace

=

CLOUD NATIVE FRAMEWORKS

132

Spring Cloud Services

Config Server Service Registry Circuit Breaker Dashboard

SUMMARY OF PLATFORM CAPABILITIES

• Immutable Infrastructure all the way down

• VMs AND Containers

• BOSH-like management AND container scheduler AND reliable container staging/build

133

SUMMARY OF PLATFORM CAPABILITIES

• Layer 7 Dynamic Routing/Load Balancing(Layer 3 is nice too)

• Log Aggregation

• Multi-Tenant API

• Authentication & Authorization134

SUMMARY OF PLATFORM CAPABILITIES

• Capacity Management (Metrics Stream)

• Application Performance Management (Response Times)

• Service Discovery, Brokerage & Marketplace

• Multi-Tenant API

• Authentication & Authorization

• Cloud Native Frameworks 135

THE CHOICE

• Build all that from tools

• Hope you get the right constraints & patterns nailed

• Adopt a structured platform

• Fill any gaps with toolchain136

DESIGNING FORCLOUD NATIVE

• 12 Factor

• Microservices

• Support Services

• Discovery, Config, Circuit Breaking

137

12 FACTORS:A CONTRACT

138

•One Codebase/Many Deploys

•Explicit Isolated Dependencies

•Config via Environment

•Attached Backing Services

•Dev/Prod Parity

•Separate Build/Release/Run

•Ephemeral Processes

•Export Services via Port Bindings

•Scale Out via Processes

•Disposable Instances

•Logs == Event Streams

•Admin Tasks == Processes

Factors for the Developer Factors for App Architecture

MONOLITHIC ARCHITECTURE

139

Relational Database

Data Access

Service

HTML JavaScript MVC

Service

Monolithic ApplicationBrowser

MONOLITHIC ARCHITECTURES

• Modularity Dependent Upon Language / Frameworks

• Change Cycles Tightly Coupled

• Inefficient Scaling

• Can Be Intimidating to New Developers

• Obstacle to Scaling Development

• Requires Long-Term Commitment to Technical Stack 140

MICROSERVICES

141

…HTTP

HTTP

HTTP

HTTP

HTTP

HTTP

AMQPAMQP

Relational DB

Key/Value Store

Graph DB

MICROSERVICES

• Services Oriented Architecture AND Services-Oriented Delivery

• Modularity Based on Bounded Contexts

• Enable Frequent Deploys, Efficient Scaling

• Individual Components Less Intimidating to New Developers

• Enables Scaling of Development…142

CONWAY’S LAW

143

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

http://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities

SPAN SILOS WITH MICROSERVICES

144

Data Access

Service

HTML JavaScript MVC

Service

UI S

pecialists

Middlew

are S

pecialists

DB

As

Business C

apability

Business C

apability

Business C

apability

Siloed Functional Teams

http://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities

Siloed Application Architectures

Cross- functional Teams

Microservice Architectures

PARTITIONING

• By Noun (e.g. product info service)

• By Verb (e.g. shipping service)

• Single Responsibility Principle(http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle)

145

YOU MUST BE THIS TALL •RAPID PROVISIONING

•BASIC MONITORING

•RAPID APPLICATION DEPLOYMENT

•DEVOPS CULTURE

146

http://martinfowler.com/bliki/MicroservicePrerequisites.html

https://www.flickr.com/photos/gusset/3723961589

ONE PIECECONTINUOUS FLOW

147

Product Mgr UX Dev QA DBA Sys

AdminNet

AdminStorage Admin

BUSINESS CAPABILITY TEAMS USING MICROSERVICES

PLATFORM OPERATIONS TEAM

Self Service

API

SUMMARY• The current trend of the IT industry is to forcefully eliminate IT

operations as we traditionally know it

• Cloud Native Applications

• Microservices, Continuously Delivered on a Platform

• Lots of experimentation between the DIY and Structured approach

• Do it Yourself - Evolution of the toolchain approach

• Structured - Community centered around sharing an architecture codebase & culture

• Cloud Foundry is currently the most successful structured platform

• Many DIY pieces are growing fast in popularity (Docker, K8S, etc)148

GET THE BOOKS

149

WITH THANKS

150

This presentation includes content / inspiration by:

Matt Stine Andrew Clay Shafer

Onsi Fakouri + many others @ Pivotal + Todd Underwood @ Google