Lagom at hybris Reactive Software Munich Meetup, April 13, 2016

Slide 1

Slide 1 text

Lutz Huehnken  @lutzhuehnken Reactive Microservices

Slide 2

Slide 2 text

Overview

Slide 3

Slide 3 text

Overview

Slide 4

Slide 4 text

What are those opinions? • Use context bounds as boundaries for services! (Domain Driven Design) • The event log is the book of record! (Event Sourcing) • Separate the read and write sides! (CQRS) • Microservices, too, need to be elastic and resilient! (Reactive) • Developer experience matters! (The Lagom development setup)

Slide 5

Slide 5 text

Size doesn’t matter (and why it’s called Lagom)

Slide 6

Slide 6 text

All this hype about microservices makes me sad. And not about the concept, but about the name. As I wrote before, “micro” in “microservices” means absolutely nothing. What is worse, it confuses everybody. Again and again I see people focusing on “micro” and falling into nanoservices trap. Eugene Kalenkovich

Slide 7

Slide 7 text

I call them Uniservices. Roland Kuhn

Slide 8

Slide 8 text

The Self-contained System (SCS) approach is an architecture that focuses on a separation of the functionality into many independent systems, making the complete logical system a collaboration of many smaller software systems. http://scs-architecture.org

Slide 9

Slide 9 text

Goodbye Microservices, Hello Right-sized Services. https://dzone.com/articles/goodbye-microservices-hello-right-sized-services

Slide 10

Slide 10 text

Right-Sized Service doesn't really roll off the tongue, does it? Being Swedish I would prefer Lagomservice. Björn Antonsson (on a Lightbend internal mailing list)

Slide 11

Slide 11 text

Lagom (pronounced [ˈlɑ ̀ ːɡɔm]) is a Swedish word meaning "just the right amount". The Lexin Swedish-English dictionary defines lagom as "enough, sufficient, adequate, just right". https://en.wikipedia.org/wiki/Lagom

Slide 12

Slide 12 text

The ideas in Eric Evan’s Domain-Driven Design are very useful to us in finding sensible boundaries for our services. Sam Newman, „Building Microservices“, p. 38

Slide 13

Slide 13 text

Event Sourcing and CQRS

Slide 14

Slide 14 text

Lagom Persistence Lagom Persistence Event Sourcing CQRS implements leads to Not covered: More Domain Driven Design, NoSQL Databases

Slide 15

Slide 15 text

• We implement our aggregate roots as Persistent Entities • Persistent Entities will receive commands • Triggered by a command, Persistent Entities will change their state • Example: Add a friend, remove a friend FriendService Peter Bob Alice Persistent Entities

Slide 16

Slide 16 text

• Lagom allows you to scale out by forming a cluster of nodes • Nodes can be added and removed dynamically Node A Lagom Cluster Node B Node C Node D join

Slide 17

Slide 17 text

• Lagom allows you to scale out by distributing your Persistent Entities in the cluster Node A Lagom Cluster Node B Node C X Bob Alice Z X Y Paul Peter

Slide 18

Slide 18 text

• We have now moved from a CRUD approach to a Memory Image approach • We keep all* our data in memory! • See http:// martinfowler.com/bliki/ MemoryImage.html (*) or a working set, actors can be passivated and activated as needed Node A Lagom Cluster Node B Node C X Bob Alice Z X Y Paul Peter

Slide 19

Slide 19 text

• But how does our data survive a system crash? • We log all the state changes!  Node A Lagom Persistence Node B Node C X Bob Alice Z X Y Paul Peter

Slide 20

Slide 20 text

Event Sourcing - storing deltas • Every state change is materialized in an Event • All events are stored in an Event Log • Current state is constructed by replaying all events

Slide 21

Slide 21 text

Event Sourcing - Storing Deltas User  Created  (Alice) Friend  Added  (Bob) Friend  Added  (Peter) Friend  Removed  (Bob)

Slide 22

Slide 22 text

Traditional Way User  (Alice) Friend  (Peter) Friend  (Bob)

Slide 23

Slide 23 text

Event Sourcing - benefits • No object-relational impedance mismatch • Bullet-proof auditing and historical tracing • Support future ways of looking at data • Performance and scalability • Testability

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Persistent Entity Data Store (e.g. Cassandra Cluster) FriendService Y Peter FriendService X Bob Alice FriendService Y X Y

Slide 26

Slide 26 text

Event Sourcing - Snapshots 1 2 100 101 102 103 .. Snapshot

Slide 27

Slide 27 text

Event Sourcing with Lagom Persistence • Keep all data in memory! • Optional: Only working set, by using passivation/ activation • Store all state changes as events • Replay all events of an actor to recreate it • Optional: Start from snapshot • Scale out with Lagom Cluster and scalable data store

Slide 28

Slide 28 text

Read-Side UserCreated(Alice) FriendAdded(Bob) FriendAdded(Peter) Alice Bob Peter Alice Bob X Y

Slide 29

Slide 29 text

Read-Side UserCreated(Alice) FriendAdded(Bob) FriendAdded(Peter) FOLLOWERS userid followedby Bob Alice Bob X Bob Y Peter Alice

Slide 30

Slide 30 text

Read side is derived from event log • Events forwarded to read side to build diﬀerent representations • ElasticSearch • SQL, de-normalized • Stream Processor / Analytics • BI • OLAP • …

Slide 31

Slide 31 text

Read side cont’d • Read side can be discarded and re- created. • The „book of record“ is the event log. • Read side can be scaled out by creating copies - it’s read only. • Btw, you can get a status for an identified entity on the write side, too.

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

Consistency FOLLOWERS userid followedby Bob Alice Bob X Bob Y Peter Alice Data Store (e.g. Cassandra Cluster) Alice 1 - Actor 2 - Journal / Event Store 3 - Read Side

Slide 34

Slide 34 text

Consistency Alice 1 - Actor • A Persistent Entities defines an Aggregate Root • Aggregate Root is the Transactional Boundary • Strong consistency within an Aggregate Root • Commands are executed sequentially on the latest state • No limit to scalability

Slide 35

Slide 35 text

Consistency Data Store (e.g. Cassandra Cluster) 2 - Journal / Event Store • Depending on implementation / configuration • Popular choice: Cassandra • „Tunable Consistency“ • Proper use of quorum ensures consistency

Slide 36

Slide 36 text

Consistency FOLLOWERS userid followedby Bob Alice Bob X Bob Y Peter Alice 3 - Read Side • Will not be updated immediately, but deferred • Not much different from queries in interactive applications

Slide 37

Slide 37 text

Event Sourcing with Lagom Persistence revisited • Keep all data in memory! • Store all state changes as events • Replay all events of an actor to recreate it • Strong consistency for Actor (aggregate) and Journal • Eventual Consistency for Read Side

Slide 38

Slide 38 text

If you really, really don’t want to use Event Sourcing • Don’t use Lagom Persistence • You can use whatever data store you like • Beware of blocking APIs (JDBC..) • For Cassandra, you can use the CassandraSession from the Persistence module

Slide 39

Slide 39 text

Reactive

Slide 40

Slide 40 text

Reactive

Slide 41

Slide 41 text

• Asynchronous I/O • Asynchronous communication as first class • WebSocket support • Reactive Streams support • Distributed by default • Built-on Akka Clustering, Sharding, Persistence Reactive

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

Developer Experience

Slide 44

Slide 44 text

• Run all microservices at once • Embedded Cassandra DB • Intra-service communication via service locator • Hot reloading Development tooling

Slide 45

Slide 45 text

• Getting started: lightbend.com/lagom • Examples: lightbend.com/activator/templates • Contribute: https://github.com/lagom • Communicate: • https://groups.google.com/forum/#!forum/lagom-framework • https://gitter.im/lagom/lagom • Lightbend Proof of Concept Program: lightbend.com/company/contact Try it out

Slide 46

Slide 46 text

Read this book https://www.lightbend.com/reactive- microservices-architecture (free, registration required)

Slide 47

Slide 47 text

No content