CONTAINERS: DON'T SKEU THEM UP

Transcription

1 CONTAINERS: DON'T SKEU THEM UP USE MICROSERVICES INSTEAD Gordon Haff, Technology William Henry, DevOps Strategy 14 July 2016

2 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

3 CONTAINERS ISOLATE WORKLOADS BUT CONTAINERS ARE NOT Server virtualization

4 WHY SERVER VIRTUALIZATION HAPPENED Mainstream hardware availability Server consolidation Cost reduction (remember dot-bomb?) Minimal change to operational model

5 VMS ARE PETS Individuals Scale-up Long-lived Monolithic Nursed back to health

6 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

7 THE CASE AGAINST SKEUOMORPHS

8 SO DON'T DO THAT

9 CONTAINERS ARE FOR ANTS Scale-out Short-lived Single-function Component of a larger whole Replacable Less stateful WARNING! OVERSIMPLIFICATION ALERT! Source:

10 ENTER MICROSERVICES

11 WHAT ARE MICROSERVICES? Text

12 ISN'T THIS JUST... Source: TIBCO

13

14 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

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

16 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

17 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

18 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

19 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

20 ON THE OTHER HAND Architectural effort Service boundaries Communication overhead Do you need it? Source: CC/flickr

21 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

22 COMMON THREAD: NEED TO RUN AS AN ORCHESTRATED (API-CENTRIC) SYSTEM Source: CC/flickr

23 EVERYONE IS SCALING Not just unicorns and mammoths Three main use cases: Large scale workloads Diverse workloads Complex resource management Source: Google

24 WE HAVE "BIG" WORKLOADS What scale? A big cluster or many small ones? Throughput? Scheduling frequency? How much availability required? Source: Darth Vader

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

26 WE NEED RESOURCE MANAGEMENT What policies are needed? Compliance Multi-tenancy Dependency management Avoiding repeated failures Persistent volume services Dynamic reservations

27 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

28 BRINGING IT ALL TOGETHER

29 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

30 PULLS TOGETHER OPEN SOURCE INNOVATION Text

31 INTERLOCKING BROAD CHANGES

32 THANK YOU!