Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices 101 - The Big Why?

C9e1b2b91046079487e45be472f30021?s=47 Yamen Sader
September 03, 2014

Microservices 101 - The Big Why?

Exploring the drivers behind the Microservices hype, and defining the prerequisites in architecture and infrastructure needed before contemplating this path.

Presented at the first Sydney Microservices Meetup - Small Talk.


Yamen Sader

September 03, 2014

More Decks by Yamen Sader

Other Decks in Programming


  1. Microservices   101 The  Big  Why?

  2. Yamen   Sader Sixtree   Co-­‐Founder   Principal  Consultant  

    Hacker   ! @yaamehn   #microservices
  3. We  Are  Here

  4. 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
  5. 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
  6. 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
  7. Woah Independent Limited Independent High Cohesion Low Coupling High Cohesion

  8. Horizontal  layering   (alone)  is  evil

  9. 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
  10. 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
  11. UI Logic Data MUD UI Logic Data

  12. CONGRATULATIONS! You  have  a  Monolith

  13. 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
  14. 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
  15. 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
  16. 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 Customer Product Billing System
  17. System Billing The  Trap Customer Product UI 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
  18. System Billing The  Prerequisite Customer Product UI Can  you  design

     your  system   without  sharing  the   database?   (This  is  the  hardest  part)
  19. And  now,  for  my  next   trick…

  20. Billing Customer Product UI

  21. 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
  22. UI DistribuHon  &  Scale  Becomes  Possible But not necessarily desirable…

    Customer Product Billing
  23. 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
  24. No  Man’s  Land Domain System Organisation Note: Organisational boundaries tend

    to be far more complex (domains align with business, systems align with IT, organisations cut across both)
  25. Microservices  Defined The  confluence  of  boundaries   between  the  Domain

     Architecture,   the  System  and  OrganisaHonal   Structure This is the only new thing
  26. Microservices  Land Domain System Organisation This is the basis of

    alignment between Microservices and DevOps maturity
  27. Drawing  the  rest  of  the  owl

  28. Let’s  Take  a  Ride

  29. First  Law  of  DistribuHon Don’t

  30. Domain  Architecture Customer Product Billing Draw  the  boxes   Low

     rate  of  change
  31. Micro  Architecture AngularJS MongoDB JEE Oracle NodeJS Ninjas Build  the

     boxes   High  rate  of  change
  32. Macro  Architecture Monitoring Data  ReplicaHon
 Messaging UI  IntegraHon ?

    Service  Discovery Deployment ReporHng Distributed  Tracing  &  ExcepHon  Handling
  33. 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!
  34. The  (micro)  elephant  in   the  room

  35. None
  36. 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  agreed Decentralised  data   management Infrastructure  is   automated Design  for  failure 100  to  1000  lines  to  code EssenHal Why? Why??!???!?
  37. This is not a microservice

  38. 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
  39. 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