Containers: Don't Skeu Them Up, Use Microservices Instead
- 1. CONTAINERS: DON'T SKEU THEM UP USE MICROSERVICES INSTEAD Gordon Haff, Technology Evangelist, @ghaff, [email protected] William Henry, DevOps Strategy Lead, @ipbabble, [email protected] 14 July 2016
- 2. CONTAINERS ARE Software packaging concept that typically includes an application/service and all of its runtime dependencies Simpliļ¬ed 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: https://www.ļ¬ickr.com/photos/pondapple/6502194585
- 12. ISN'T THIS JUST... Source: TIBCO
- 14. 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
- 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 modiļ¬ed or updated independently Should be robust in the face of changes to other services
- 17. SMALL Well-deļ¬ned function "Fits in your head" Owned by a single cross-functional team Organized around business capabilities (Conway's Law) Source: Kathy CC/Flickr https://ļ¬ic.kr/p/b9fFV
- 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/ļ¬ickr https://ļ¬ic.kr/p/7RE6yc
- 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/ļ¬ickr https://ļ¬ic.kr/p/at2Jt2
- 20. ON THE OTHER HAND Source: CC/ļ¬ickr https://www.ļ¬ickr.com/photos/ļ¬rstdown/2456119103 Architectural effort Service boundaries Communication overhead Do you need it?
- 21. NOT EVERYTHING IS A MICROSERVICE Cost of migrating existing apps May not need the scale Monoliths may be the ļ¬rst step even for cloud native Containerization has beneļ¬ts even without microservices Broader idea of twelve-factor apps Evolutionary approaches often most practical Source: Eric Fischer CC/ļ¬ickr https://www.ļ¬ickr.com/photos/walkingsf/4622376356E
- 22. COMMON THREAD: NEED TO RUN AS AN ORCHESTRATED (API-CENTRIC) SYSTEM Source: CC/ļ¬ickr https://www.ļ¬ickr.com/photos/42931449 www.planetofsuccess.com/blog/
- 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) Workļ¬ows 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 deļ¬ning service boundaries for new ones Clusters and memory at scale New availability mechanisms Emergent behaviors Source: Keith Allison CC/ļ¬ickr https://ļ¬ic.kr/p/abGcs9
- 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. Text PULLS TOGETHER OPEN SOURCE INNOVATION
- 32. THANK YOU!