The value of embracing microservices, containers, and continuous delivery is powerful only when brought together in logical, scalable, and portable ways. When used incorrectly it’s increasingly easy to make things much worse for you and your team, and do it at scale.
For example, while microservices can be used to effectively isolate functionality, increase the speed of delivery, and help scale your team it can also be a way to inefficiently duplicate functionality and create single points of failure.
I’ll share anti-patterns and corresponding best practices based on my experience building application infrastructure and platforms, as well as the applications which are deployed to them.
This Presentation is from Gordon Haff and William Henry at LinuxCon Japan 2016
Where to Learn More About FDO _ Richard at FIDO Alliance.pdf
Containers: Don't Skeu Them Up, Use Microservices Instead
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. 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
4. WHY SERVER VIRTUALIZATION HAPPENED
Mainstream hardware availability
Server consolidation
Cost reduction (remember dot-bomb?)
Minimal change to operational model
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
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
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 https://flic.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/flickr https://flic.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/flickr https://flic.kr/p/at2Jt2
20. ON THE OTHER HAND
Source: CC/flickr https://www.flickr.com/photos/firstdown/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 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
22. COMMON THREAD:
NEED TO RUN AS AN ORCHESTRATED
(API-CENTRIC) SYSTEM
Source: CC/flickr https://www.flickr.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)
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 https://flic.kr/p/abGcs9