The document discusses the evolution and benefits of containers and microservices in software development. It highlights the distinction between traditional server virtualization and modern containerization, emphasizing the efficiencies of microservices architectures. Key points include the advantages of stateless, scalable design and the need for improved coordination among teams to effectively implement microservices.

1. CONTAINERS:CONTAINERS:
DON'T SKEU THEM UPDON'T SKEU THEM UP
USE MICROSERVICES INSTEADUSE MICROSERVICES INSTEAD
Gordon Haff, Cloud Product Strategy @ghaff
William Henry, DevOps Strategy @ipbabble
7 October 2015

2. CONTAINERS ARECONTAINERS 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.
Isolated through a variety of Linux
features

3. BUT CONTAINERS ARE NOTBUT CONTAINERS ARE NOT
Server virtualization

4. VMS ARE PETSVMS ARE PETS
Individuals
Stateful
Scale-up
Long-lived
Monolithic
Nursed back to health

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

6. THE CASE AGAINST SKEUOMORPHSTHE CASE AGAINST SKEUOMORPHS

7. SO DO N'T D O THATSO DO N'T D O THAT

8. CO NTAINERS AR ECO NTAINERS AR E
FOR ANTSFOR ANTS
Stateless
Scale-out
Short-lived
Single-function
Part of a larger whole
Replacable
S o u rc e : h t t p s : / / w w w. fli c k r .c o m /p h o t o s /p o n d a p p l e/ 6 5 0 2 1 9 4 5 8 5

9. ENTER MICROSERVICESENTER MICROSERVICES

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

11. IS N'T T HIS J UST...IS N'T T HIS J UST...
S o u rc e : T I B C O

13. IMPORTAN T DI FF ER ENCESIMPORTAN T DI FF ER ENCES
S o u rc e : P W C
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. AU TO N O M O U SAU TO N O M O U S
Implementation changes can happen
independently of other services
Data and functionality exposed only
through service calls over the network
Designed to be externalizable
No back-doors

15. SMALLSMALL
Well-defined function
"Fits in your head"
Owned by a single cross-functional team
Organized around business capabilities
(Conway's Law)
S o u rc e : K a t h y C C / F l i c k r h t t p s : / / fli c . k r /p / b 9 f F V

16. S o u rc e : A d r i a n C o c k ro f t , B a t t e r y Ve n t u re s

17. BOUNDED CONTEXTBOUNDED 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

18. S IGNS YOU MIGHTS IGNS YOU MIGHT
NEED MICROSERVICESNEED 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
S o u rc e : D a n i e l P r a t t s C C / fli c k r h t t p s : / / fli c . k r /p / 7 R E 6 y c

19. ADVANTAGESADVANTAGES
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
Easier to do DevOps!
S o u rc e : K e g R i v e r C C / fli c k r h t t p s : / / fli c . k r /p /a t 2 J t 2

20. NOT EVERYTHING IS ANOT EVERYTHING IS A
MICROSERVIC EMICROSERVIC E
Cost of migrating existing apps
Monoliths may be the first step even for cloud
native
Containerization has benefits even without
microservices
Evolutionary approaches often most practical
Common thread is integration and
coordination of services to create a system
S o u rc e : E r i c F i s c h e r C C / fli c k r h t t p s : / / w w w. fli c k r .c o m /p h o t o s / w a l k i n g s f / 4 6 2 2 3 76 3 5 6 E

21. EVERYONE IS SCALINGEVERYONE IS SCALING
Not Infrastructure-as-a-Service (IaaS)
Not just unicorns and mammoths
Three main use cases:
Large scale workloads
Diverse workloads
Complex resource management
S o u rc e : G o o g l e

22. WE NEED TO SCALE!WE NEED TO SCALE!
What scale?
A big cluster or many small ones?
Throughput?
Scheduling frequency?
How much availability required?
S o u rc e : D a r t h Va d e r

23. WE HAVEWE HAVE DIVERSEDIVERSE
WORKLOADSWORKLOADS
Conventional or cloud native?
What type of workloads?
CI/CD (e.g. Jenkins)
Data analytics (e.g. Spark, Storm)
Batch (e.g. Chronos)
Workflows
Containers(e.g. Kubernetes, Swarm, Docker, etc.)
Single cluster sharing the workloads?

24. WE NEED RESOURCEWE NEED RESOURCE
MANAGE M ENTMANAGE M ENT
What policies are needed?
Compliance
Multi-tenancy
Dependency management
Avoiding repeated failures
Persistent volume services
Dynamic reservations

25. HARD PARTSHARD 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
S o u rc e : K e i t h A l l i s o n C C / fli c k r h t t p s : / / fli c . k r /p /a b G c s9

26. PUTTING IT ALL TOGETHERPUTTING IT ALL TOGETHER

27. PA AS IS O N E INTEGRAT IO N PO INTPA AS IS O N E INTEGRAT IO N PO INT

28. TextText
BUT MULTIPLE PACKAGING FORBUT MULTIPLE PACKAGING FOR
DIFFERENT USE CASESDIFFERENT USE CASES

29. THANK YOU!THANK YOU!