CONTAINERS: DON'T SKEU THEM UP USE MICROSERVICES INSTEAD Gordon - - PowerPoint PPT Presentation

CONTAINERS: DON'T SKEU THEM UP

USE 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 that typically includes an application/service and all of its runtime dependencies Simplified management (plus packaging and orchestration) of a set of tools that have existed within Linux for a long time Portability across diverse environments Isolated through a variety of Linux features

CONTAINERS ISOLATE 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 PETS

Individuals Scale-up Long-lived Monolithic Nursed back to health

A skeuomorph /ˈskjuːəmɔrf/ is a derivative object that retains ornamental design cues from structures that were necessary in the original. Examples include pottery embellished with imitation rivets reminiscent of similar pots made of metal and a software calendar that imitates the appearance of binding on a paper desk calendar.

Wikipedia

THE CASE AGAINST SKEUOMORPHS

SO DON'T DO THAT

CONTAINERS ARE FOR ANTS

Scale-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?

Text Text

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

ISN'T THIS JUST...

Source: TIBCO

IMPORTANT DIFFERENCES

Source: PWC

Lighter-weight communications protocols Improved understanding of functional separation More open source and vendor- neutral philosophies Scale-out infrastructure standardization and automation Alignment with evolving practices such as DevOps

AUTONOMOUS

Data and functionality exposed only through service calls over the network Designed to be externalizable No back-doors

BOUNDED CONTEXT

Avoid having to know too much about the surrounding services Can be modified or updated independently Should be robust in the face of changes to

• ther 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 MIGHT NEED MICROSERVICES

Having trouble coordinating function teams like DBAs and UI engineers Brittle apps. Minor changes cause major breakage Your CICD process is bogged down by big deployments Different teams keep reinventing the wheel (in gratuitously 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 A MICROSERVICE

Cost of migrating existing apps May not need the scale Monoliths may be the first step even for cloud native Containerization has benefits even without microservices 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 DIVERSE WORKLOADS

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 RESOURCE MANAGEMENT

What 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 defining service 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, and health management Persistent storage option

Text

PULLS TOGETHER OPEN SOURCE INNOVATION

INTERLOCKING BROAD CHANGES

THANK YOU!