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.

Transcript

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