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 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 vendorneutral 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 other 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 Architectural effort Service boundaries Communication overhead Do you need it? Source: CC/flickr https://www.flickr.com/photos/firstdown/2456119103
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
PULLS TOGETHER OPEN SOURCE INNOVATION Text
INTERLOCKING BROAD CHANGES
THANK YOU!