Microservices 101 - The Big Why?

Microservices  101

The  Big  Why?

Yamen  Sader

Sixtree  Co-­‐Founder  

Principal  Consultant  Hacker  !

@yaamehn  #microservices

We  Are  Here

System

Why  Are  We  Here?

• TradiHonal  3-­‐Her  ‘architecture’  to  build  ‘systems’  

• But  what  is  an  architecture?  

• And  what  is  a  system?

UI

Logic

Data

Architecture

• Defining  the  boundaries  between  components  (modularisaHon)  to  

• minimise  dependencies  between  components  (coupling)  and  

• maximise  cohesiveness  within  components  

!

• Equips  us  to  deal  with  CHANGE

High Cohesion

Low Coupling

High Cohesion

System• A  unit  of  deployment  and/or  development  and/or  (most  likely)  purchase  or  commissioning  

• Independent  of  other  systems  

• UI  and  persistence  

• Development  and  evoluHon  

• OperaHons  

• Frameworks  and  languages  

• Underlying  runHme  ‘process’  

• Limited  interacHon  with  other  systems

Independent

Limited

Independent

Woah

Independent

Limited

Independent

High Cohesion

Low Coupling

High Cohesion

Horizontal  layering  (alone)  is  evil

System

Early  ObjecHves

• This  is  the  natural  way  to  start  building  systems  

• Easy  to  develop  

• Homogenous  

• Small  number  of  concerns,  so  highly  cohesive  

• ‘Simple’

UI

Logic

Data

System

Over  Time• New  funcHonal  concepts  and  concerns  are  added  

• Has  no  concept  of  the  ‘funcHonal  separaHon’  of  concerns  

• Only  decouples  technical  concerns  

• But  technical  concerns  change  the  least  o^en!  

• How  does  this  architecture  evolve  as  a  ‘system’  grows  over  Hme?

UI

Logic

Data

UI

Logic

Data

MUD

UI

Logic

Data

CONGRATULATIONS!You  have  a  Monolith

System

Please  Don’t  Ever  Change• You  know  you  have  a  monolith  if  change  is  slow  and  terrifying  

• It’s  slow  and  terrifying  because:  

• Each  layer  has  very  low  cohesion  (covers  many  concerns)  

• Each  layer  depends  on  the  layer  below  it  (albeit  abstracted)  very  significantly  

• The  ‘unit  of  change’  requires  too  big  of  a  ‘unit  of  understanding’  (doesn’t  fit  in  your  head)

UI

Logic

Data

Other  Concerns• Long  term  commitment  to  technology  stack  

• Difficult  to  onboard  new  developers  

• Slow  and  overloaded  development  environment  

• Slow  applicaHon  startup  

• Difficult  to  conHnuously  test  and  deploy  

• Very  difficult  to  scale  applicaHon  horizontally  

• Difficult  to  scale  development  

• Difficult  to  idenHfy  boelenecks  and  issues  

• Very  difficult  to  cleanly  integrate  with  other  systems

System

The  First  Step

• Admit  that  this  horizontal  layering  is  insufficient  past  a  certain  scale  (mulHple  funcHonal  concerns  in  a  fast-­‐changing  environment)  

• The  layers  must  create  boundaries  that  meet  the  principles  of  architecture  (modules  with  high  cohesion  and  low  coupling)

UI

Logic

Data

VerHcal  (Domain)  Slices

• This  is  MUCH  beeer  

• A  change  is  much  more  likely  to  affect  a  single  slice  

• This  can  be  VERY  difficult  to  do  correctly

Custom

er

Produc

t

Billin

g

System

System

Billin

g

The  TrapCustom

er

Produc

tUI

Data

Yes!  Great  benefit  to  having  a  single,  cohesive  user  interface

OK,  let’s  trust  everyone  to  respect  these  boundaries

ReferenHal  integrity  and  transacHons  reintroduce  coupling

System

Billin

g

The  PrerequisiteCustom

er

Produc

tUI

Can  you  design  your  system  without  sharing  the  

database?  

(This  is  the  hardest  part)

And  now,  for  my  next  trick…

Billin

g

Custom

er

Produc

t

UI

Once  reliance  on  a  shared  database  between  

components  is  removed,  the  system  boundary  becomes  

arbitrary  !

i.e.,  you  can  choose  the  most  appropriate  system  boundary

UI

DistribuHon  &  Scale  Becomes  Possible

But not necessarily desirable…

Custom

er

Produc

t

Billin

g

Conway’s  Law

OrganizaHons  which  design  systems  …  are  constrained  to  produce  designs  which  are  copies  of  the  communicaHon  structures  of  these  organizaHons  

—  M  Conway

Boundary

Boundary

Monolith

Monolith

No  Man’s  LandDomain System Organisation

Note: Organisational boundaries tend to be far more complex (domains align with business, systems align with IT, organisations cut across both)

Microservices  Defined

The  confluence  of  boundaries  between  the  Domain  Architecture,  the  System  and  OrganisaHonal  

Structure

This is the only new thing

Microservices  LandDomain System Organisation

This is the basis of alignment between Microservices and DevOps maturity

Drawing  the  rest  of  the  owl

Let’s  Take  a  Ride

First  Law  of  DistribuHon

Don’t

Domain  Architecture

Customer Product Billing

Draw  the  boxes  Low  rate  of  change

Micro  Architecture

AngularJS MongoDB

JEE Oracle

NodeJS Ninjas

Build  the  boxes  High  rate  of  change

Macro  Architecture

Monitoring

Data  ReplicaHon ProtocolsMessaging

UI  IntegraHon

?Service  Discovery

Deployment

ReporHng

Distributed  Tracing  &  ExcepHon  Handling

The  Hard  Bits• UI  IntegraHon  &  SSO  

• Data  IntegraHon  &  DuplicaHon  

• Monitoring  

• Deployment  &  Management  

• Service  RegistraHon  &  Discovery  

• Developer  Tooling  

• Distributed  ParHHoning  

• (No)  TransacHons  

• ReporHng  

• Data  MigraHon  

• Protocols  &  Standards  

• Distributed  Tracing  &  Error  Handling  

• Resiliency

And  many  more!

The  (micro)  elephant  in  the  room

My  Opinion

hep://www.sixtree.com.au/arHcles/2014/microservices-­‐characterised/

Services  with  uniform  interfaces

Small  with  a  single  responsibility Containerless

Organised  “verHcally”  along  business  capabiliHes

Loose  coupling,  favouring  choreography  over  

orchestraHon Decentralised  governance  where  only  the  interfaces  

are  agreedDecentralised  data  

management

Infrastructure  is  automated

Design  for  failure

100  to  1000  lines  to  code

EssenHal Why? Why??!???!?

This is not a microservice

I  guess  it  is  easier  to  use  a  new  name  (Microservices)  rather  than  say  that  this  is  what  SOA  actually  meant  –  re  hep://t.co/gvhxDfDWLG     —  Arnon  Rotem-­‐Gal-­‐Oz  (@arnonrgo)           March  16,  2014

Further  Reading• Master  Reading  List:  hep://www.maesHne.com/microservices  

• The  Big  MoHvaHon:  hep://www.infoq.com/presentaHons/Breaking-­‐the-­‐Monolith  

• Asking  Why:  hep://genehughson.wordpress.com/2012/07/15/most_important_quesHon/  

• On  Architecture:  hep://genehughson.wordpress.com/2012/04/04/architecture-­‐versus-­‐design/  

• Great  Series:  hep://www.Hgerteam.dk/category/soa/microservices/  

• Life  Beyond  Distributed  TransacHons:  hep://www.ics.uci.edu/~cs223/papers/cidr07p15.pdf  

• Distributed  Big  Balls  of  Mud:  hep://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html  

• Reality:  heps://rclayton.silvrback.com/failing-­‐at-­‐microservices  

• Our  Thoughts:  hep://www.sixtree.com.au/arHcles/tag/microservices.html