CONTAINERS:CONTAINERS:DON'T SKEU THEM UPDON'T SKEU THEM UPU S E M I C R O S E RV I C E S I N S T E A DU S E M I C R O S E RV I C E S I N S T E A D

Gordon Haf f, Cloud Product Strategy @ghaf f

Wil l iam Henry, DevOps Strategy @ipbabble

7 October 2015

C O N TA I N E R S A R EC O N TA I N E R S A R E

Software packaging concept thattypical ly includes anapplication/service and al l of itsruntime dependencies

Simplified management (pluspackaging and orchestration) of a setof tools that have existed within Linuxfor a long time.

Isolated through a variety of Linuxfeatures

B U T C O N TA I N E R S A R E N OTB U T C O N TA I N E R S A R E N OT

Server virtualization

V M S A R E P E T SV M S A R E P E T SIndividuals

Stateful

Scale-up

Long-l ived

Monolithic

Nursed back to health

A skeuomorph / ˈskjuːəmɔrf/ is a derivative objectthat retains ornamental design cues fromstructures that were necessary in theoriginal. Examples include pottery embellishedwith imitation rivets reminiscent of similar potsmade of metal and a software calendar thatimitates the appearance of binding on a paper deskcalendar.

Wikipedia

T H E C A S E AG A I N S T S K E U O M O R P H ST H E C A S E AG A I N S T S K E U O M O R P H S

S O D O N ' T D O T H ATS O D O N ' T D O T H AT

C O N TA I N E R S A R EC O N TA I N E R S A R EF O R A N T SF O R A N T S

Stateless

Scale-out

Short-l ived

Single-function

Part of a larger whole

Replacable

S o u r c 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

E N T E R M I C R O S E RV I C E SE N T E R M I C R O S E RV I C E S

W H AT A R E M I C R O S E RV I C E S ?W H AT A R E M I C R O S E RV I C E S ?

TextText

http ://mar t infowler .com/ar t ic les/microserv ices .html

I S N ' T T H I S J U S T. . .I S N ' T T H I S J U S T. . .

S o u r c e : T I B C O

I M P O R TA N T D I F F E R E N C E SI M P O R TA N T D I F F E R E N C E S

S o u r c e : P W C

Lighter-weight communicationsprotocols

Improved understanding offunctional separation

More open source and vendor-neutral philosophies

Scale-out infrastructurestandardization and automation

Alignment with evolvingpractices such as DevOps

A U TO N O M O U SA U TO N O M O U S

Implementation changes can happenindependently of other services

Data and functionality exposed onlythrough service cal ls over the network

Designed to be externalizable

No back-doors

S M A L LS M A L L

Well-defined function

"Fits in your head"

Owned by a single cross-functional team

Organized around business capabil it ies(Conway's Law)

S o u r c 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

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

B O U N D E D C O N T E X TB O U N D E D C O N T E X T

Avoid having to know too much about thesurrounding services

Can be modified or updated independently

Should be robust in the face of changes toother services

S I G N S YO U M I G H TS I G N S YO U M I G H TN E E D M I C R O S E RV I C E SN E E D M I C R O S E RV I C E S

Having trouble coordinating function teamslike DBAs and UI engineers

Britt le apps. Minor changes cause majorbreakage

Your CICD process is bogged down by bigdeployments

Dif ferent teams keep reinventing the wheel ( ingratuitously dif ferent ways)

Hard to experiment

S o u r c 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

A DVA N TAG E SA DVA N TAG E S

Easier for teams to pick the right tool for the job

Easier for teams to pick an appropriate release cycle

Easier to build resi l iency and scale-out

Easier to do updates and CICD

Easier to do DevOps!

S o u r c 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

N OT E V E RY T H I N G I S AN OT E V E RY T H I N G I S AM I C R O S E RV I C EM I C R O S E RV I C ECost of migrating existing apps

Monoliths may be the first step even for cloudnative

Containerization has benefits even withoutmicroservices

Evolutionary approaches often most practical

Common thread is integration andcoordination of services to create a system

S o u r c 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 7 6 3 5 6 E

E V E RYO N E I S S C A L I N GE V E RYO N E I S S C A L I N G

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 r c e : G o o g l e

W E N E E D TO S C A L E !W E N E E D TO S C A L E !

What scale?

A big cluster or many small ones?

Throughput?

Scheduling frequency?

How much availabil ity required?

S o u r c e : D a r t h Va d e r

W E H AV E W E H AV E D I V E R S ED I V E R S EW O R K L OA D SW O R K L OA D S

Conventional or cloud native?

What type of workloads?

C I/CD (e .g . Jenk ins) Data ana ly t ics (e .g . Spark , Storm) Batch (e .g . Chronos) Workflows Conta iners(e .g . Kubernetes , Swarm, Docker , etc . )

Single cluster sharing the workloads?

W E N E E D R E S O U R C EW E N E E D R E S O U R C EM A N AG E M E N TM A N AG E M E N TWhat policies are needed?

Compliance

Multi-tenancy

Dependency management

Avoiding repeated fai lures

Persistent volume services

Dynamic reservations

H A R D PA R T SH A R D PA R T S

Hardest is polit ical/people

How do you test, deploy and manage?

Untangling existing apps and definingservice boundaries for new ones

Clusters and memory at scale

New availabil ity mechanisms

Emergent behaviors

S o u r c 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 s 9

P U T T I N G I T A L L TO G E T H E RP U T T I N G I T A L L TO G E T H E R

PA A S I S O N E I N T E G R AT I O N P O I N TPA A S I S O N E I N T E G R AT I O N P O I N T

TextText

B U T M U LT I P L E PAC K AG I N G F O RB U T M U LT I P L E PAC K AG I N G F O RD I F F E R E N T U S E C A S E SD I F F E R E N T U S E C A S E S

THANK YOU!THANK YOU!