Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Containers: Don't Skeu Them Up. Use Microservices Instead.

491 views

Published on

from LinuxCon Japan 2016

Skeuomorphism usually means retaining existing design cues in something new that doesn't actually need them. But the basic idea is far broader. For example, containers aren't legacy virtualization with a new spin. They're part and parcel of a new platform for cloud apps including containerized operating systems like Project Atomic, container packaging systems like Docker, container orchestration like Kubernetes and Mesos, DevOps continuous integration and deployment practices, microservices architectures, "cattle" workloads, software-defined everything, management across hybrid infrastructures, and pervasive open source.

In this session, Red Hat's Gordon Haff and William Henry will discuss how containers can be most effectively deployed together with these new technologies and approaches -- including the resource management of large clusters with diverse workloads -- rather than mimicking legacy sever virtualization workflows and architectures.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Containers: Don't Skeu Them Up. Use Microservices Instead.

  1. 1. 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
  2. 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. 3. CONTAINERS ISOLATE WORKLOADS BUT CONTAINERS ARE NOT Server virtualization
  4. 4. WHY SERVER VIRTUALIZATION HAPPENED Mainstream hardware availability Server consolidation Cost reduction (remember dot-bomb?) Minimal change to operational model
  5. 5. VMS ARE PETS Individuals Scale-up Long-lived Monolithic Nursed back to health
  6. 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. 7. THE CASE AGAINST SKEUOMORPHS
  8. 8. SO DON'T DO THAT
  9. 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.flickr.com/photos/pondapple/6502194585
  10. 10. ENTER MICROSERVICES
  11. 11. WHAT ARE MICROSERVICES? TextText http://martinfowler.com/articles/microservices.html
  12. 12. ISN'T THIS JUST... Source: TIBCO
  13. 13. 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
  14. 14. AUTONOMOUS Data and functionality exposed only through service calls over the network Designed to be externalizable No back-doors
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. ON THE OTHER HAND Source: CC/flickr https://www.flickr.com/photos/firstdown/2456119103 Architectural effort Service boundaries Communication overhead Do you need it?
  20. 20. 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
  21. 21. COMMON THREAD: NEED TO RUN AS AN ORCHESTRATED (API-CENTRIC) SYSTEM Source: CC/flickr https://www.flickr.com/photos/42931449 www.planetofsuccess.com/blog/
  22. 22. EVERYONE IS SCALING Not just unicorns and mammoths Three main use cases: Large scale workloads Diverse workloads Complex resource management Source: Google
  23. 23. WE HAVE "BIG" WORKLOADS What scale? A big cluster or many small ones? Throughput? Scheduling frequency? How much availability required? Source: Darth Vader
  24. 24. 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?
  25. 25. WE NEED RESOURCE MANAGEMENT What policies are needed? Compliance Multi-tenancy Dependency management Avoiding repeated failures Persistent volume services Dynamic reservations
  26. 26. 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
  27. 27. BRINGING IT ALL TOGETHER
  28. 28. 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
  29. 29. Text PULLS TOGETHER OPEN SOURCE INNOVATION
  30. 30. INTERLOCKING BROAD CHANGES
  31. 31. THANK YOU!

×