This is an introduction of Lagom. It is a framework of microservice edited by lightbend

1. LagomReactive microservices framework
#NightClazz @Lagom
12/05/16
Fabrice Sznajderman
@fsznajderman

2. Agenda
● Core concepts
● Lagom framework
● Hands on Lagom

3. Who I am?
Fabrice Sznajderman
○ Java/Scala/Web developer
■ Java/Scala trainer
■ Co-organizer of Scala IO 2016
■ Contributor on Lagom
● BrownBagLunch.fr

4. Chapter 1
Core
Concepts

5. Agenda
● Microservices architecture
● CQRS
● Event Sourcing
Core concepts

6. Core concepts
Microservices
Architecture

7. Monolithic vs Microservices

8. Monolithic issues
● All features are concentrated
in one app
● One technology used (silver
bullet?)
● Complexity rising over time
● new comers have difficulties to
dive into code base

9. Microservices-based
Architecture
Reactive Microservices Architecture: Design Principles for Distributed Systems - James Boner http:
//www.oreilly.com/programming/free/reactive-microservices-architecture.html
Microservices-Based Architecture is a simple concept: it
advocates creating a system from a collection of small,
isolated services, each of which owns their data, and is
independently isolated, scalable and resilient to
failure.
Services integrate with other services in order to form a
cohesive system that’s far more flexible than the typical
enterprise systems we build today.

10. What is a microservice?
Standalone component

11. What is a microservice?
Isolated

12. What is a microservice?
Own its data

13. What is a microservice?
Located microservice

14. What is a microservice?
Communication by asynchronous message

15. What is a good microservice ?
Answer with 3 questions ...

16. Question 1
Does my service do only one thing?
If you can state a microservice’s full
purpose with a short sentence, your
service is OK!
“This service manages users’
accounts”

17. Question 2
Is my service autonomous?
A service should be responsible
for its own behavior. It shouldn’t
rely on other services to do its
job.
“An autonomous service would accept the
any request regardless of the status of
others services.”

18. Question 3
Does this service own its own data?
A service “owns” data if it is the
sole writer and the sole reader of
the database where the data lives
“Data can be accessed only throught the
service interface, no directly”

19. Anti-pattern
● Adapted use-case?
● Transactionnal
● Distributed monolithic layers
● “Don’t Repeat Yourself”
● Shared data repository

20. That implies challenges
● Organisational impacts
● Monitoring of services
● Locating service
● Test strategy
● Distributed development
environment

21. Reading
Reactive Microservices Architecture by Jonas Boner

22. CQRS
Core concepts

23. CQRS stands for
● Command
● Query
● Responsability
● Segregation

24. Traditional approach

25. Traditional approach
● Using the same model for read
and write
● Read & write have different
needs
○ Representation of data can
take several forms
○ Update side contains
validation rules
● All together rises complexity
● Performance issues

26. Write : Normalization,
consistency, transactional...
Read : Denormalization,
scalability, performance...
Needs between read and write are not the
same.
http://martinfowler.com/bliki/CommandQuerySeparation.html
Facts

27. Command : Change the state of a
system but do not return a value
Queries : Return a result and do
not change the observable state
of the system (are free of side
effects)
Principle is that we divide our model into two
sharply separated categories:
http://martinfowler.com/bliki/CommandQuerySeparation.html
CQRS approach

28. CQRS approach

29. CQRS approah
● Each model are on
○ separate logicals processes
○ separate hardware
● Database :
○ shared
○ unique per model
● Unique model with differente
interfaces
Several manners to implement

30. Other architecture

31. CQRS approah
● Not a silver bullet, every case
doesn’t fit with this CQRS
approach.
● Doesn’t apply CQRS on whole
system, only be used on specific
portions of system (bounded
context - DDD)
Cautions

32. Next
CQRS design fits well with Event
Sourcing pattern...

33. Event
Sourcing
Core concepts

34. Traditional approah
Active record

35. Traditional approah
Active record

36. Traditional approah
● Only final state is captured
● Debugability & tracability not
really easy
● Complexity with mapping O & R
● Performance issue (update)
How we have reached this state?
Active record

37. Event Sourcing approach
● Don't update the current state
of objects
● Save the events that lead to the
current state
Different approach

38. Event Sourcing approach
● Complete log of every state
change
● Debugability & tracability
come easy
● Good performance (commit
log)
and more …
Benefits

39. ● Complete rebuild
● Temporal query
● Event replay
Event Sourcing approach
More benefits

40. ● Commands are going to change the
state (or not)
● Each state change creates an event
● Order of events must be preserved
Event Sourcing approach
How does it works?

41. ● Command’s name describe an action
to do (imperative)
● Event’s name describe an action in
the past
Event Sourcing approach
Remarks

42. Event Sourcing approach
Restore
state into model

43. Event Sourcing approach
Deleting an object
Update the query side with deletion of
bank account.

44. Event Sourcing approach
Snapshot
● Several events will be created
● Restore all events to reach one state
might be expensive
● To avoid this, we use a snapshot

45. Lagom
Framework
Chapter 2

46. Agenda
● Big picture of Lagom
● Project structure
● My first microservice
Lagom framework

47. Big picture
of Lagom

48. Big picture of Lagom
First of all, … Lagom pronounce :

49. What is Lagom?
● Microservices framework for a
system of microservices
● Based on the Reactive principles
● A fully integrated development
environment

50. Which language?
● Core of framework written in
Scala
● Developments are in Java
● Scala version migth be available
soon

51. Main features
● Service API
● Persistence API
● Development Environment
● Production Environment

52. Service API
● Interface as descriptor
● Defined API of exposed services
● Synchronous request/response
● Asynchronous streaming
message

53. Persistence API
● Provides event-sourced
persisted entities
● CQRS Read side
● Entry point for events handlers

54. Development Environment
● One command to start all
services
● Hot reload of your code
● Several services provided out of
the box
● IDE Integration

55. Production Environment
● ConductR for production
environment
● Scaling
● Deployment
● Monitoring

56. Communication protocols
● Polyglot systems
● HTTP, WebSocket, JSON are
standards
● can consumed
● can be consumed

57. Component technologies
● Collection of technologies
● Some come from Lightbend
● Others are third-party and
open-source

58. Component technologies
● Java 8 (& Scala)
● Immutables
● SBT
● Jackson
● Cassandra
● Play framework
● Guice
● Akka : Persistence, Pub/Sub,
cluster
● Akka Stream : Streaming part
● SLF4J & Logback

59. ● Asynchronous & non blocking as
default
● Distributed persistence : ES /
CQRS as default
● Circuit breaker (as default)
● Productivity for developers :
Expressive service interface
Design philosophy

60. Project
Structure
with Lagom

61. Activator
activator sampleProject lagom-java
● Engine provided by Lightbend
● Create project from template
● Template name for Lagom: lagom-java
● Activator must be installed apart
● Generated a new project :

62. Project tree

63. SBT build file
● Project configuration
● Describe all modules
● Describe all dependencies per module
● Host all parameters for project
○ cassandra
○ service locator
○ etc

64. Service declaration
● One service is composed of 2 sub-
projects
○ API
○ Implementation
● Implementation depends on API

65. SBT build file
organization in ThisBuild := "sample.helloworld"
// the Scala version that will be used for cross-
compiled libraries
scalaVersion in ThisBuild := "2.11.7"
lazy val helloworldApi = project("helloworld-api")
.settings(
version := "1.0-SNAPSHOT",
libraryDependencies += lagomJavadslApi
)
lazy val helloworldImpl = project("helloworld-impl")
.enablePlugins(LagomJava)
.settings(
version := "1.0-SNAPSHOT",
libraryDependencies ++= Seq(
lagomJavadslPersistence,
lagomJavadslTestKit
)
)
.settings(lagomForkedTestSettings: _*)
.dependsOn(helloworldApi)

66. Service imported
● One service could be imported as
dependency
● Just declare it and it will start as others

67. Launch services
● One command to launch all Lagom’s
service : sbt runAll
● Several services are launched
○ Cassandra
○ Service locator
○ service gateway
○ All services that you declared

68. Launch one service
● One command to launch one Lagom’s
service : sbt project_name/run
● no more services are launched
● One service Locator must be available
apart.

69. Locator service
● All services register on this locator
● By default, one service locator is started
● It can be started apart

70. Cassandra embedded
● One instance of Cassandra is started by
default
● It can be unactivate if no persistence is
required
● It can be started apart
● Cassandra’s client can be used to
explore tables

71. Mapping of one Service

72. Write a
service
with Lagom

73. Demo
Here, we will see :
○ Global configuration of project
○ Service Interface - Descriptor
○ Related implementation
○ All stuffs linked with persistence (CQRS-EventSourcing)

74. Just an information !
● 5 days ago, the API has change !!!
ServiceCall<Id,Request, Response>
interface ServiceCall<Request, Response> {
CompletionStage<Response> invoke(Request request);
//others methods
}

75. Ok, now we can dive into dark side...code! ;)

76. Thank you!
Next …

77. Hands on!
Chapter 3