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.

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


Published on

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.

Published in: Software
  • Login to see the comments

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

  1. 1. Lutz Huehnken
 @lutzhuehnken Reactive Microservices
  2. 2. Overview
  3. 3. Overview
  4. 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. 5. Size doesn’t matter (and why it’s called Lagom)
  6. 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. 7. I call them Uniservices. Roland Kuhn
  8. 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.
  9. 9. Goodbye Microservices, Hello Right-sized Services.
  10. 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. 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".
  12. 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. 13. Event Sourcing and CQRS
  14. 14. Lagom Persistence Lagom Persistence Event Sourcing CQRS implements leads to Not covered: More Domain Driven Design, NoSQL Databases
  15. 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. 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. 17. • Lagom allows you to scale out by distributing your Persistent Entities in the cluster Node A Lagom Cluster Node B Node C XBob Alice Z X Y Paul Peter
  18. 18. • We have now moved from a CRUD approach to a Memory Image approach • We keep all* our data in memory! • See http:// MemoryImage.html (*) or a working set, actors can be passivated and activated as needed Node A Lagom Cluster Node B Node C XBob Alice Z X Y Paul Peter
  19. 19. • But how does our data survive a system crash? • We log all the state changes!
 Node A Lagom Persistence Node B Node C XBob Alice Z X Y Paul Peter
  20. 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. 21. Event Sourcing - Storing Deltas User
 (Alice) Friend
 (Bob) Friend
 (Peter) Friend
  22. 22. Traditional Way User
 (Alice) Friend
 (Peter) Friend
  23. 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
  24. 24. Persistent Entity Data Store (e.g. Cassandra Cluster) FriendService Y Peter FriendService XBob Alice FriendService Y XY
  25. 25. Event Sourcing - Snapshots 1 2 100 101 102 103.. Snapshot
  26. 26. 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
  27. 27. Read-Side UserCreated(Alice) FriendAdded(Bob) FriendAdded(Peter) Alice Bob Peter Alice Bob X Y
  28. 28. Read-Side UserCreated(Alice) FriendAdded(Bob) FriendAdded(Peter) FOLLOWERS userid followedby Bob Alice Bob X Bob Y Peter Alice
  29. 29. 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 • …
  30. 30. 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.
  31. 31. Consistency FOLLOWERS userid followedby Bob Alice Bob X Bob Y Peter Alice Data Store (e.g. Cassandra Cluster) Alice1 - Actor 2 - Journal / Event Store 3 - Read Side
  32. 32. Consistency Alice1 - 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. Reactive
  38. 38. Reactive
  39. 39. • Asynchronous I/O • Asynchronous communication as first class • WebSocket support • Reactive Streams support • Distributed by default • Built-on Akka Clustering, Sharding, Persistence Reactive
  40. 40. Developer Experience
  41. 41. • Run all microservices at once • Embedded Cassandra DB • Intra-service communication via service locator • Hot reloading Development tooling
  42. 42. • Getting started: • Examples: • Contribute: • Communicate: •!forum/lagom-framework • • Lightbend Proof of Concept Program: Try it out
  43. 43. Read this book microservices-architecture (free, registration required)