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

How many of the challenges of microservices are caused by the fact that the tools we use were designed without microservices in mind? What if we would design a framework, made to build systems composed of microservices from the start? One that has a notion of looking up and using other services built in? That defaults to distributed storage? That has support for dealing with failure on different levels? That lets you get started quickly with a guided, minimalistic approach on your own machine, without pre-installing anything or reading a hundred pages of documentation?

Lightbend designed Lagom, made for microservices from the start. Making it easier for developers to build microservices-based systems that communicate asynchronously, self-heal, scale elastically and remain responsive no matter what bad stuff is happening.

Transcript

1. Lutz Huehnken
 @lutzhuehnken Reactive Microservices
2. Overview
3. Overview
4. 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)
5. Size doesn’t matter (and why it’s called Lagom)
6. 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
7. I call them Uniservices. Roland Kuhn
8. 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
9. Goodbye Microservices, Hello Right-sized Services. https://dzone.com/articles/goodbye-microservices-hello-right-sized-services
10. 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)
11. 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
12. 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
13. Event Sourcing and CQRS
14. Lagom Persistence Lagom Persistence Event Sourcing CQRS implements leads to Not covered: More Domain Driven Design, NoSQL Databases
15. • 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
16. • 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
17. • 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
18. • 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
19. • 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
20. 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
21. Event Sourcing - Storing Deltas User
 Created
 (Alice) Friend
 Added
 (Bob) Friend
 Added
 (Peter) Friend
 Removed
 (Bob)
22. Traditional Way User
 (Alice) Friend
 (Peter) Friend
 (Bob)
23. 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
25. Persistent Entity Data Store (e.g. Cassandra Cluster) FriendService Y Peter FriendService X Bob Alice FriendService Y X Y
26. Event Sourcing - Snapshots 1 2 100 101 102 103 .. Snapshot
27. 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
28. Read-Side UserCreated(Alice) FriendAdded(Bob) FriendAdded(Peter) Alice Bob Peter Alice Bob X Y
29. Read-Side UserCreated(Alice) FriendAdded(Bob) FriendAdded(Peter) FOLLOWERS userid followedby Bob Alice Bob X Bob Y Peter Alice
30. Read side is derived from event log • Events forwarded to read side to build different representations • ElasticSearch • SQL, de-normalized • Stream Processor / Analytics • BI • OLAP • …
31. 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.
33. 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
34. 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
35. 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
36. 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
37. 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
38. 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
39. Reactive
40. Reactive
41. • Asynchronous I/O • Asynchronous communication as first class • WebSocket support • Reactive Streams support • Distributed by default • Built-on Akka Clustering, Sharding, Persistence Reactive
43. Developer Experience
44. • Run all microservices at once • Embedded Cassandra DB • Intra-service communication via service locator • Hot reloading Development tooling
45. • 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
46. Read this book https://www.lightbend.com/reactive- microservices-architecture (free, registration required)