CONTAINERS:DON'T SKEU THEM UPUSE MICROSERVICES INSTEAD

Gordon Haff, Technology Evangelist, @ghaff, ghaff@redhat.com

William Henry, DevOps Strategy Lead, @ipbabble, whenry@redhat.com

14 July 2016

CONTAINERS ARE

Software packaging concept thattypically includes an application/serviceand all of its runtime dependencies

Simplified management (plus packagingand orchestration) of a set of tools thathave existed within Linux for a long time

Portability across diverse environments

Isolated through a variety of Linuxfeatures

CONTAINERS ISOL ATE WORKLOADS

BUT CONTAINERS ARE NOT

Server virtualization

WHY SERVER VIRTUALIZATION HAPPENED

Mainstream hardware availability

Server consolidation

Cost reduction (remember dot-bomb?)

Minimal change to operational model

VMS ARE PETSIndividuals

Scale-up

Long-lived

Monolithic

Nursed back to health

A skeuomorph /ˈskjuːəmɔrf/ is a derivative objectthat retains ornamental design cues from structuresthat were necessary in the original. Examplesinclude pottery embellished with imitation rivetsreminiscent of similar pots made of metal and asoftware calendar that imitates the appearance ofbinding on a paper desk calendar.

Wikipedia

THE CASE AGAINST SKEUOMORPHS

SO DON'T DO THAT

CONTAINERS AREFOR ANTSScale-out

Short-lived

Single-function

Component of a larger whole

Replacable

Less stateful

WARNING!

OVERSIMPLIFICATION ALERT!

Source: https://www.flickr.com/photos/pondapple/6502194585

ENTER MICROSERVICES

WHAT ARE MICROSERVICES?

TextText

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

ISN'T THIS JUST...

Source: TIBCO

IMPORTANT DIFFERENCES

Source: PWC

Lighter-weight communicationsprotocols

Improved understanding offunctional separation

More open source and vendor-neutral philosophies

Scale-out infrastructurestandardization and automation

Alignment with evolving practicessuch as DevOps

AUTONOMOUS

Data and functionality exposed only throughservice calls over the network

Designed to be externalizable

No back-doors

BOUNDED CONTEXT

Avoid having to know too much about thesurrounding services

Can be modified or updated independently

Should be robust in the face of changes toother services

SMALL

Well-defined function

"Fits in your head"

Owned by a single cross-functional team

Organized around business capabilities(Conway's Law)

Source: Kathy CC/Flickr https://flic.kr/p/b9fFV

SIGNS YOU MIGHTNEED MICROSERVICES

Having trouble coordinating function teams likeDBAs and UI engineers

Brittle apps. Minor changes cause majorbreakage

Your CICD process is bogged down by bigdeployments

Different teams keep reinventing the wheel (ingratuitously different ways)

Hard to experiment

Source: Daniel Pratts CC/flickr https://flic.kr/p/7RE6yc

ADVANTAGES

Easier for teams to pick the right tool for the job

Easier for teams to pick an appropriate release cycle

Easier to build resiliency and scale-out

Easier to do updates and CICD

Potentially more scalable

Easier to do DevOps!

Source: KegRiver CC/flickr https://flic.kr/p/at2Jt2

ON THE OTHER HAND

Source: CC/flickr https://www.flickr.com/photos/firstdown/2456119103

Architectural effort

Service boundaries

Communication overhead

Do you need it?

NOT EVERYTHING IS AMICROSERVICECost of migrating existing apps

May not need the scale

Monoliths may be the first step even for cloudnative

Containerization has benefits even withoutmicroservices

Broader idea of twelve-factor apps

Evolutionary approaches often most practical

Source: Eric Fischer CC/flickr https://www.flickr.com/photos/walkingsf/4622376356E

COMMON THREAD:

NEED TO RUN AS AN ORCHESTRATED(API-CENTRIC) SYSTEM

Source: CC/flickr https://www.flickr.com/photos/42931449 www.planetofsuccess.com/blog/

EVERYONE IS SCALING

Not just unicorns and mammoths

Three main use cases:

Large scale workloads

Diverse workloads

Complex resource management

Source: Google

WE HAVE "BIG" WORKLOADS

What scale?

A big cluster or many small ones?

Throughput?

Scheduling frequency?

How much availability required?

Source: Darth Vader

WE HAVE DIVERSEWORKLOADS

Conventional or cloud native?

What type of workloads?

CI/CD (e.g. Jenkins)

Data analytics (e.g. Spark, Storm)

Batch (e.g. Chronos, Mesos)

Workflows

Containers (e.g. Kubernetes)

Single cluster sharing the workloads?

WE NEED RESOURCEMANAGEMENTWhat policies are needed?

Compliance

Multi-tenancy

Dependency management

Avoiding repeated failures

Persistent volume services

Dynamic reservations

HARD PARTS

Hardest is political/people

How do you test, deploy and manage?

Untangling existing apps and definingservice boundaries for new ones

Clusters and memory at scale

New availability mechanisms

Emergent behaviors

Source: Keith Allison CC/flickr https://flic.kr/p/abGcs9

BRINGING IT ALL TOGETHER

DEVELOPERS GET

Self-service

Multiple interaction models

Polyglot, multi-language support

xPaaS services

Immutable, container-based platform

Automation for application builds, deployments, scaling, andhealth management

Persistent storage option

Text

PULLS TOGETHER OPEN SOURCEINNOVATION

INTERLOCKING BROAD CHANGES

THANK YOU!