Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

From Microliths To Microsystems

4,504 views

Published on

Everyone is talking about microservices, and there is more confusion than ever about what the promise of microservices really means and how to deliver on it. To address this we will explore microservices from first principles, distilling their essence and putting them in their true context: distributed systems.

What many people forget is that microservices are distributed and collaborative by nature and only make sense as systems—one collaborator is no collaborator. It is in between the microservices that the most interesting and rewarding, and also challenging, problems arise—enter the world of distributed systems.

Distributed systems are by definition complex, and we system developers have been spoiled by centralized servers for too long to easily understand what this really means. Slicing an existing system into various REST services and wiring them back together again with synchronous protocols and traditional enterprise tools—designed for monolithic architectures—will set us up for failure.

As if that wasn’t enough, we can’t just think about systems of microservices. In order to make each microservice resilient and elastic in and of itself, we have to design each individual microservice as a distributed system—a «microsystem»—architected from the ground up using the reactive principles.

Published in: Engineering

From Microliths To Microsystems

  1. 1. FROM MICROLITHS TO MICROSYSTEMSJONAS BONÉR @JBONER LIGHTBEND
  2. 2. WE HAVE BEEN SPOILED BY THE ALMIGHTY MONOLITH
  3. 3. KNOCK, KNOCK. WHO’S THERE? REALITY
  4. 4. WE CAN'T MAKE THE HORSE FASTER
  5. 5. WE NEED CARS FOR WHERE WE ARE GOING
  6. 6. BUT DON'T JUST DRINK THE THINK FOR YOURSELF
  7. 7. NO ONE WANTS MICROSERVICES IT'S A NECCESSARY EVIL
  8. 8. ARCHITECTURAL CONTEXT OF MICROSERVICES: DISTRIBUTED SYSTEMS
  9. 9. LET'S SAY THAT WE WANT TO SLICE THIS MONOLITH UP
  10. 10. TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS
  11. 11. MICROLITH: SINGLE INSTANCE MICROSERVICE -NOT RESILIENT -NOT ELASTIC
  12. 12. One actor is no actor. Actors come in systems. — Carl Hewitt
  13. 13. MICROSERVICES COME IN SYSTEMS
  14. 14. AS SOON AS WE EXIT THE SERVICE WE ENTER A WILD OCEAN OF NON-DETERMINISM THE WORLD OF DISTRIBUTED SYSTEMS
  15. 15. SYSTEMS NEED TO EXPLOIT REALITY
  16. 16. EMBRACE REALITY AND ITS CONSTRAINTS SHALL SET YOU FREE
  17. 17. INFORMATION HAS LATENCY
  18. 18. The contents of a message are always from the past! They are never “now.” — Pat Helland
  19. 19. WE ARE ALWAYS LOOKING INTO THE PAST
  20. 20. THE COST OF MAINTAINING THE ILLUSION OF AN ABSOLUTE NOW
  21. 21. AS LATENCY GETS HIGHER, THE ILLUSION CRACKS EVEN MORE
  22. 22. In a distributed system, you can know where the work is done or you can know when the work is done but you can’t know both — Pat Helland
  23. 23. STRIVE TO MINIMIZE COUPLING & COMMUNICATION
  24. 24. Words are very unecessary. They can only do harm. Enjoy the silence. — Enjoy the Silence by Martin Gore (Depeche Mode)
  25. 25. Silence is not only golden, it is seldom misquoted. — Bob Monkhouse
  26. 26. WE HAVE TO RELY ON EVENTUAL CONSISTENCY BUT RELAX IT'S HOW THE WORLD WORKS
  27. 27. NO ONE WANTS EVENTUAL CONSISTENCY. IT'S A NECESSARY EVIL. IT'S NOT COOL. IT'S USEFUL.
  28. 28. TWO HELPFUL TOOLS 1. REACTIVE DESIGN 2. EVENTS-FIRST DDD
  29. 29. REACTIVE PROGRAMMING VS REACTIVE SYSTEMS
  30. 30. REACTIVE PROGRAMMING CAN HELP US MAKING THE INDIVIDUAL SERVICE INSTANCE HIGHLY PERFORMANT AND EFFICIENT
  31. 31. REACTIVE SYSTEMS CAN HELP US BUILDING DISTRIBUTED SYSTEMS THAT ARE ELASTIC AND RESILIENT
  32. 32. GOASYNCHRONOUS
  33. 33. ASYNC IO—IS ABOUT NOT BLOCKING THREADS ASYNC COMM—IS ABOUT NOT BLOCKING REQUESTS
  34. 34. GO ASYNCHRONOUS & NON-BLOCKING - MORE EFFICIENT USE OF RESOURCES - MINIMIZES CONTENTION ON SHARED RESOURCES
  35. 35. ALWAYS APPLY BACK-PRESSURE A FAST SYSTEM SHOULD NOT OVERLOAD A SLOW SYSTEM
  36. 36. LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS
  37. 37. WE NEED TO EXTEND OUR MODELS OF COMMUNICATION1. ASYNCHRONOUS MESSAGING (N-M) 2. STREAMING (1-1) 3. SYNCHRONOUS REQUEST/REPLY (1-1)
  38. 38. WE'RE GETTING THERE, BUT WE STILL HAVE A SINGLE INSTANCE MICROSERVICE —NOT SCALABLE —NOT RESILIENT
  39. 39. MICROSERVICES COME AS SYSTEMS
  40. 40. EACH MICROSERVICENEEDS BE DESIGNED AS A DISTRIBUTED SYSTEM A MICROSYSTEM
  41. 41. WE NEED TO MOVE FROM MICROLITHS TO MICROSYSTEMS
  42. 42. SEPARATE THE STATELESS BEHAVIOR FROM THE STATEFUL ENTITYTO SCALE THEM INDIVIDUALLY
  43. 43. SCALING (STATELESS) BEHAVIOR IS EASY
  44. 44. SCALING (STATEFUL) ENTITIES IS HARD
  45. 45. THERE IS NO SUCH THING AS A "STATELESS" ARCHITECTURE IT'S JUST SOMEONE ELSE'S PROBLEM
  46. 46. THE ENTITY CAN BECOME AN ESCAPE ROUTE FROM REALITY. A SAFE ISLAND OF DETERMINISM AND STRONG CONSISTENCY
  47. 47. REACTIVE SYSTEMS HELPS MAKING THE MICROSERVICE (MICROSYSTEM) RESILIENT AND ELASTICALLY SCALABLE LEARN MORE AT REACTIVEMANIFESTO.ORG
  48. 48. REACTIVE SYSTEMS ARE BASED ON ASYNCHRONOUS MESSAGE-PASSING
  49. 49. ALLOWS DECOUPLING IN SPACEAND TIME
  50. 50. ALLOWS FOR LOCATION TRANSPARENCY ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE CORE SOCKET CPU CONTAINER SERVER RACK DATA CENTER SYSTEM
  51. 51. But I'll take my time anywhere. I'm free to speak my mind anywhere. And I'll redefine anywhere. Anywhere I roam. Where I lay my head is home. — Wherever I May Roam by Lars Ulrich, James Hetfield (Metallica)
  52. 52. THE PATH TOWARDS RESILIENCE 1. Decentralized Architecture 2. Bulkheading 3. Replication 4. Failure Detection 5. Supervision ⇒ Self-healing systems
  53. 53. THE PATH TOWARDS ELASTICITY 1. Decentralized Architecture 2. Epidemic Gossip Protocols 3. Self-organization 4. Location Transparency ⇒ Elastic systems
  54. 54. THINK IN TERMS OF CONSISTENCY BOUNDARIES
  55. 55. INSIDE DATA: OUR CURRENT PRESENT (STATE) OUTSIDE DATA: BLAST FROM THE PAST (FACTS) BETWEEN SERVICES: HOPE FOR THE FUTURE (COMMANDS) — PAT HELLAND, DATA ON THE INSIDE VS DATA ON THE OUTSIDE
  56. 56. PRACTICE EVENTS-FIRST DOMAIN-DRIVEN DESIGN
  57. 57. DON'T FOCUS ON THE THINGS—THE NOUNS FOCUS ON WHAT HAPPENS—THE EVENTS
  58. 58. LET THE EVENTS DEFINE THE BOUNDED CONTEXT
  59. 59. EVENTS REPRESENT FACTS
  60. 60. To condense fact from the vapor of nuance — Neal Stephenson, Snow Crash
  61. 61. ...AND WE ARE NOT TALKING ABOUT ALTERNATIVE FACTS
  62. 62. WHAT ARE THE FACTS?
  63. 63. UNDERSTAND HOW FACTS ARE CAUSALLY RELATED HOW FACTS FLOW IN THE SYSTEM
  64. 64. WE NEED TO CONTAIN MUTABLE STATE & PUBLISH FACTS
  65. 65. The truth is the log. The database is a cache of a subset of the log. — Pat Helland
  66. 66. CRUDIS DEAD
  67. 67. FAVOR EVENT LOGGING
  68. 68. THE LOGIS A DATABASE OF THE PAST NOT JUST A DATABASE OF THE PRESENT
  69. 69. EVENT LOGGING AVOIDS THE INFAMOUS OBJECT-RELATIONAL IMPEDENCE MISMATCH
  70. 70. UNTANGLE THE READ & WRITEMODELS WITH CQRS & EVENT SOURCING
  71. 71. BUT WHAT ABOUT TRANSACTIONS?
  72. 72. In general, application developers simply do not implement large scalable applications assuming distributed transactions. — Pat Helland
  73. 73. USE A PROTOCOL OF GUESS. APOLOGIZE. COMPENSATE.
  74. 74. IT'S HOW THE WORLD WORKS
  75. 75. IN SUMMARY 1. Don't build Microliths 2. Microservices come in (distributed) systems 3. Microservices come as (micro)systems 4. Embrace the Reactive principles 5. Embrace Event-first DDD & Persistence 6. Profit!
  76. 76. TRY THE LAGOMMICROSERVICES FRAMEWORK POWERED BY AKKA & PLAY LAGOMFRAMEWORK.COM
  77. 77. LEARN MOREDOWNLOAD MY BOOK FOR FREE AT: BIT.LY/REACTIVE-MICROSERVICES-ARCHITECTURE
  78. 78. THANK YOU

×