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.

1. FROM
MICROLITHS
TO
MICROSYSTEMSJONAS BONÉR
@JBONER
LIGHTBEND

2. WE HAVE BEEN SPOILED BY
THE ALMIGHTY
MONOLITH

3. KNOCK, KNOCK. WHO’S THERE?
REALITY

4. WE CAN'T MAKE THE HORSE FASTER

5. WE NEED CARS FOR WHERE WE ARE GOING

6. BUT DON'T JUST DRINK THE
THINK FOR YOURSELF

7. NO ONE WANTS
MICROSERVICES
IT'S A NECCESSARY EVIL

8. ARCHITECTURAL CONTEXT OF MICROSERVICES:
DISTRIBUTED SYSTEMS

9. LET'S SAY THAT WE WANT TO
SLICE THIS MONOLITH UP

10. TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS

11. MICROLITH:
SINGLE INSTANCE
MICROSERVICE
-NOT RESILIENT
-NOT ELASTIC

12. One actor is no actor.
Actors come in systems.
— Carl Hewitt

13. MICROSERVICES
COME IN SYSTEMS

14. AS SOON AS WE
EXIT THE SERVICE
WE ENTER A WILD OCEAN OF
NON-DETERMINISM
THE WORLD OF
DISTRIBUTED SYSTEMS

15. SYSTEMS NEED TO
EXPLOIT REALITY

16. EMBRACE REALITY
AND ITS CONSTRAINTS
SHALL SET YOU FREE

17. INFORMATION HAS
LATENCY

18. The contents of
a message are
always from the past!
They are never “now.”
— Pat Helland

19. WE ARE ALWAYS LOOKING INTO THE PAST

20. THE COST OF MAINTAINING THE
ILLUSION
OF AN ABSOLUTE
NOW

21. AS LATENCY GETS HIGHER, THE
ILLUSION CRACKS EVEN MORE

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. STRIVE TO MINIMIZE
COUPLING &
COMMUNICATION

24. Words are very
unecessary.
They can only do harm.
Enjoy the silence.
— Enjoy the Silence by Martin Gore
(Depeche Mode)

25. Silence is not only
golden, it is seldom
misquoted.
— Bob Monkhouse

26. WE HAVE TO RELY ON
EVENTUAL CONSISTENCY
BUT RELAX
IT'S HOW THE WORLD WORKS

27. NO ONE WANTS
EVENTUAL CONSISTENCY.
IT'S A NECESSARY EVIL.
IT'S NOT COOL. IT'S USEFUL.

28. TWO HELPFUL TOOLS
1. REACTIVE DESIGN
2. EVENTS-FIRST DDD

29. REACTIVE PROGRAMMING
VS
REACTIVE SYSTEMS

30. REACTIVE PROGRAMMING CAN HELP US MAKING
THE INDIVIDUAL SERVICE INSTANCE
HIGHLY PERFORMANT AND EFFICIENT

31. REACTIVE SYSTEMS CAN HELP US BUILDING
DISTRIBUTED SYSTEMS THAT ARE
ELASTIC AND RESILIENT

32. GOASYNCHRONOUS

33. ASYNC IO—IS ABOUT NOT BLOCKING
THREADS
ASYNC COMM—IS ABOUT NOT BLOCKING
REQUESTS

34. GO ASYNCHRONOUS &
NON-BLOCKING
- MORE EFFICIENT USE OF RESOURCES
- MINIMIZES CONTENTION ON SHARED
RESOURCES

35. ALWAYS APPLY BACK-PRESSURE
A FAST SYSTEM
SHOULD NOT OVERLOAD
A SLOW SYSTEM

36. LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS

37. WE NEED TO EXTEND OUR MODELS OF
COMMUNICATION1. ASYNCHRONOUS MESSAGING (N-M)
2. STREAMING (1-1)
3. SYNCHRONOUS REQUEST/REPLY (1-1)

39. WE'RE GETTING THERE, BUT WE STILL HAVE A
SINGLE INSTANCE MICROSERVICE
—NOT SCALABLE
—NOT RESILIENT

40. MICROSERVICES
COME AS SYSTEMS

41. EACH MICROSERVICENEEDS BE DESIGNED AS
A DISTRIBUTED SYSTEM
A MICROSYSTEM

42. WE NEED TO MOVE
FROM MICROLITHS
TO MICROSYSTEMS

43. SEPARATE THE
STATELESS BEHAVIOR
FROM THE
STATEFUL ENTITYTO SCALE THEM INDIVIDUALLY

45. SCALING (STATELESS) BEHAVIOR
IS EASY

46. SCALING (STATEFUL) ENTITIES
IS HARD

47. THERE IS NO SUCH THING AS A
"STATELESS" ARCHITECTURE
IT'S JUST SOMEONE ELSE'S PROBLEM

48. THE ENTITY CAN BECOME AN
ESCAPE ROUTE
FROM REALITY.
A SAFE ISLAND OF
DETERMINISM AND
STRONG CONSISTENCY

50. REACTIVE SYSTEMS
HELPS MAKING THE
MICROSERVICE (MICROSYSTEM)
RESILIENT AND
ELASTICALLY SCALABLE
LEARN MORE AT REACTIVEMANIFESTO.ORG

51. REACTIVE SYSTEMS ARE BASED ON
ASYNCHRONOUS
MESSAGE-PASSING

52. ALLOWS DECOUPLING IN
SPACEAND
TIME

53. ALLOWS FOR LOCATION TRANSPARENCY
ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE
CORE SOCKET CPU
CONTAINER SERVER RACK
DATA CENTER SYSTEM

54. 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)

55. THE PATH TOWARDS RESILIENCE
1. Decentralized Architecture
2. Bulkheading
3. Replication
4. Failure Detection
5. Supervision
⇒ Self-healing systems

56. THE PATH TOWARDS ELASTICITY
1. Decentralized Architecture
2. Epidemic Gossip Protocols
3. Self-organization
4. Location Transparency
⇒ Elastic systems

58. THINK IN TERMS OF
CONSISTENCY BOUNDARIES

59. 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

60. PRACTICE
EVENTS-FIRST
DOMAIN-DRIVEN DESIGN

61. DON'T FOCUS ON THE THINGS—THE NOUNS
FOCUS ON WHAT HAPPENS—THE EVENTS

62. LET THE
EVENTS DEFINE
THE BOUNDED CONTEXT

63. EVENTS REPRESENT FACTS

64. To condense fact from
the vapor of nuance
— Neal Stephenson, Snow Crash

65. ...AND WE ARE NOT TALKING ABOUT
ALTERNATIVE FACTS

66. WHAT ARE THE
FACTS?

67. UNDERSTAND HOW FACTS ARE CAUSALLY RELATED
HOW FACTS FLOW IN THE SYSTEM

68. WE NEED TO
CONTAIN MUTABLE STATE &
PUBLISH FACTS

69. The truth is the log.
The database is a cache
of a subset of the log.
— Pat Helland

70. CRUDIS DEAD

71. FAVOR
EVENT LOGGING

72. THE LOGIS A DATABASE OF THE PAST
NOT JUST A DATABASE OF THE PRESENT

73. EVENT LOGGING AVOIDS THE INFAMOUS
OBJECT-RELATIONAL
IMPEDENCE MISMATCH

74. UNTANGLE THE
READ & WRITEMODELS WITH
CQRS & EVENT SOURCING

76. BUT WHAT ABOUT
TRANSACTIONS?

77. In general,
application developers
simply do not implement
large scalable
applications
assuming distributed
transactions.
— Pat Helland

78. USE A PROTOCOL OF
GUESS.
APOLOGIZE.
COMPENSATE.

79. IT'S HOW THE
WORLD WORKS

80. 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!

81. TRY THE
LAGOMMICROSERVICES
FRAMEWORK
POWERED BY AKKA & PLAY
LAGOMFRAMEWORK.COM

82. LEARN
MOREDOWNLOAD MY BOOK FOR FREE AT:
BIT.LY/REACTIVE-MICROSERVICES-ARCHITECTURE

83. THANK
YOU