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
MICROSYSTEMSJONAS BONÉR
@JBONER
LIGHTBEND
WE HAVE BEEN SPOILED BY
THE ALMIGHTY
MONOLITH
KNOCK, KNOCK. WHO’S THERE?
REALITY
WE CAN'T MAKE THE HORSE FASTER
WE NEED CARS FOR WHERE WE ARE GOING
BUT DON'T JUST DRINK THE
THINK FOR YOURSELF
NO ONE WANTS
MICROSERVICES
IT'S A NECCESSARY EVIL
ARCHITECTURAL CONTEXT OF MICROSERVICES:
DISTRIBUTED SYSTEMS
LET'S SAY THAT WE WANT TO
SLICE THIS MONOLITH UP
TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS
MICROLITH:
SINGLE INSTANCE
MICROSERVICE
-NOT RESILIENT
-NOT ELASTIC
One actor is no actor.
Actors come in systems.
— Carl Hewitt
MICROSERVICES
COME IN SYSTEMS
AS SOON AS WE
EXIT THE SERVICE
WE ENTER A WILD OCEAN OF
NON-DETERMINISM
THE WORLD OF
DISTRIBUTED SYSTEMS
SYSTEMS NEED TO
EXPLOIT REALITY
EMBRACE REALITY
AND ITS CONSTRAINTS
SHALL SET YOU FREE
INFORMATION HAS
LATENCY
The contents of
a message are
always from the past!
They are never “now.”
— Pat Helland
WE ARE ALWAYS LOOKING INTO THE PAST
THE COST OF MAINTAINING THE
ILLUSION
OF AN ABSOLUTE
NOW
AS LATENCY GETS HIGHER, THE
ILLUSION CRACKS EVEN MORE
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...
STRIVE TO MINIMIZE
COUPLING &
COMMUNICATION
Words are very
unecessary.
They can only do harm.
Enjoy the silence.
— Enjoy the Silence by Martin Gore
(Depeche Mode)
Silence is not only
golden, it is seldom
misquoted.
— Bob Monkhouse
WE HAVE TO RELY ON
EVENTUAL CONSISTENCY
BUT RELAX
IT'S HOW THE WORLD WORKS
NO ONE WANTS
EVENTUAL CONSISTENCY.
IT'S A NECESSARY EVIL.
IT'S NOT COOL. IT'S USEFUL.
TWO HELPFUL TOOLS
1. REACTIVE DESIGN
2. EVENTS-FIRST DDD
REACTIVE PROGRAMMING
VS
REACTIVE SYSTEMS
REACTIVE PROGRAMMING CAN HELP US MAKING
THE INDIVIDUAL SERVICE INSTANCE
HIGHLY PERFORMANT AND EFFICIENT
REACTIVE SYSTEMS CAN HELP US BUILDING
DISTRIBUTED SYSTEMS THAT ARE
ELASTIC AND RESILIENT
GOASYNCHRONOUS
ASYNC IO—IS ABOUT NOT BLOCKING
THREADS
ASYNC COMM—IS ABOUT NOT BLOCKING
REQUESTS
GO ASYNCHRONOUS &
NON-BLOCKING
- MORE EFFICIENT USE OF RESOURCES
- MINIMIZES CONTENTION ON SHARED
RESOURCES
ALWAYS APPLY BACK-PRESSURE
A FAST SYSTEM
SHOULD NOT OVERLOAD
A SLOW SYSTEM
LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS
WE NEED TO EXTEND OUR MODELS OF
COMMUNICATION1. ASYNCHRONOUS MESSAGING (N-M)
2. STREAMING (1-1)
3. SYNCHRONOUS REQUEST/REP...
WE'RE GETTING THERE, BUT WE STILL HAVE A
SINGLE INSTANCE MICROSERVICE
—NOT SCALABLE
—NOT RESILIENT
MICROSERVICES
COME AS SYSTEMS
EACH MICROSERVICENEEDS BE DESIGNED AS
A DISTRIBUTED SYSTEM
A MICROSYSTEM
WE NEED TO MOVE
FROM MICROLITHS
TO MICROSYSTEMS
SEPARATE THE
STATELESS BEHAVIOR
FROM THE
STATEFUL ENTITYTO SCALE THEM INDIVIDUALLY
SCALING (STATELESS) BEHAVIOR
IS EASY
SCALING (STATEFUL) ENTITIES
IS HARD
THERE IS NO SUCH THING AS A
"STATELESS" ARCHITECTURE
IT'S JUST SOMEONE ELSE'S PROBLEM
THE ENTITY CAN BECOME AN
ESCAPE ROUTE
FROM REALITY.
A SAFE ISLAND OF
DETERMINISM AND
STRONG CONSISTENCY
REACTIVE SYSTEMS
HELPS MAKING THE
MICROSERVICE (MICROSYSTEM)
RESILIENT AND
ELASTICALLY SCALABLE
LEARN MORE AT REACTIVEMANI...
REACTIVE SYSTEMS ARE BASED ON
ASYNCHRONOUS
MESSAGE-PASSING
ALLOWS DECOUPLING IN
SPACEAND
TIME
ALLOWS FOR LOCATION TRANSPARENCY
ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE
CORE SOCKET CPU
CONTAINER SE...
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 l...
THE PATH TOWARDS RESILIENCE
1. Decentralized Architecture
2. Bulkheading
3. Replication
4. Failure Detection
5. Supervisio...
THE PATH TOWARDS ELASTICITY
1. Decentralized Architecture
2. Epidemic Gossip Protocols
3. Self-organization
4. Location Tr...
THINK IN TERMS OF
CONSISTENCY BOUNDARIES
INSIDE DATA: OUR CURRENT PRESENT (STATE)
OUTSIDE DATA: BLAST FROM THE PAST (FACTS)
BETWEEN SERVICES: HOPE FOR THE FUTURE (...
PRACTICE
EVENTS-FIRST
DOMAIN-DRIVEN DESIGN
DON'T FOCUS ON THE THINGS—THE NOUNS
FOCUS ON WHAT HAPPENS—THE EVENTS
LET THE
EVENTS DEFINE
THE BOUNDED CONTEXT
EVENTS REPRESENT FACTS
To condense fact from
the vapor of nuance
— Neal Stephenson, Snow Crash
...AND WE ARE NOT TALKING ABOUT
ALTERNATIVE FACTS
WHAT ARE THE
FACTS?
UNDERSTAND HOW FACTS ARE CAUSALLY RELATED
HOW FACTS FLOW IN THE SYSTEM
WE NEED TO
CONTAIN MUTABLE STATE &
PUBLISH FACTS
The truth is the log.
The database is a cache
of a subset of the log.
— Pat Helland
CRUDIS DEAD
FAVOR
EVENT LOGGING
THE LOGIS A DATABASE OF THE PAST
NOT JUST A DATABASE OF THE PRESENT
EVENT LOGGING AVOIDS THE INFAMOUS
OBJECT-RELATIONAL
IMPEDENCE MISMATCH
UNTANGLE THE
READ & WRITEMODELS WITH
CQRS & EVENT SOURCING
BUT WHAT ABOUT
TRANSACTIONS?
In general,
application developers
simply do not implement
large scalable
applications
assuming distributed
transactions.
...
USE A PROTOCOL OF
GUESS.
APOLOGIZE.
COMPENSATE.
IT'S HOW THE
WORLD WORKS
IN SUMMARY
1. Don't build Microliths
2. Microservices come in (distributed) systems
3. Microservices come as (micro)system...
TRY THE
LAGOMMICROSERVICES
FRAMEWORK
POWERED BY AKKA & PLAY
LAGOMFRAMEWORK.COM
LEARN
MOREDOWNLOAD MY BOOK FOR FREE AT:
BIT.LY/REACTIVE-MICROSERVICES-ARCHITECTURE
THANK
YOU
From Microliths To Microsystems
From Microliths To Microsystems
From Microliths To Microsystems
From Microliths To Microsystems
From Microliths To Microsystems
From Microliths To Microsystems
You’ve finished this document.
Download and read it offline.
Upcoming SlideShare
Go Reactive: Event-Driven, Scalable, Resilient & Responsive Systems
Next
Upcoming SlideShare
Go Reactive: Event-Driven, Scalable, Resilient & Responsive Systems
Next
Download to read offline and view in fullscreen.

26

Share

From Microliths To Microsystems

Download to read offline

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.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

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
  • adax_adarsh

    Jun. 28, 2019
  • RuthVargas1

    Mar. 26, 2019
  • franklinnwa

    Jan. 24, 2019
  • leolencioni

    Jun. 29, 2018
  • alxcho

    Nov. 13, 2017
  • tachesimazzoca

    Sep. 9, 2017
  • truonglvx1

    Jul. 30, 2017
  • yurifl

    Jul. 4, 2017
  • up1

    Jun. 22, 2017
  • Clipping-Path-House

    Jun. 8, 2017
  • VilleNurmi4

    May. 18, 2017
  • sledorze

    Apr. 21, 2017
  • andreysabitov

    Apr. 15, 2017
  • kylesm

    Mar. 19, 2017
  • rafapc

    Mar. 15, 2017
  • YiweiZhang19

    Mar. 14, 2017
  • brunodleite

    Mar. 13, 2017
  • paulslattery1

    Mar. 13, 2017
  • at10ti0n

    Mar. 13, 2017
  • davidbrabant1

    Mar. 12, 2017

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.

Views

Total views

6,182

On Slideshare

0

From embeds

0

Number of embeds

138

Actions

Downloads

157

Shares

0

Comments

0

Likes

26

×