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

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

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.flickr.com/photos/pondapple/6502194585

10. ENTER MICROSERVICES

11. WHAT ARE MICROSERVICES?
TextText
http://martinfowler.com/articles/microservices.html

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

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

31. INTERLOCKING BROAD CHANGES

32. THANK YOU!