We designed a new framework, made for Microservices. Making it easier for developers to build microservices-based systems – systems that communicate asynchronously, self-heal, scale elastically and remain responsive no matter what bad stuff is happening. And all this without the pain of selecting and mixing components, from a plethora of libraries that were originally built for other things. In this presentation, we reveal this new way for Java developers to not only understand and begin building microservices, but also to seamlessly push them into staging and production

1. Markus Jura
@markusjura
Mircoservices “Just Right”

2. Lagom - [lah-gome]
Adequate, sufficient, just right

3. • Overview
• Developer experience
• Service API
• Persistence & Clustering
• Running in production
Agenda

4. Overview

5. • Reactive
• Built-in resiliency & failure handling patterns
• Developer experience
• No setup of external services
• Intra-service communication just works
• Services automatically reload on code change
• Takes you through to production deployment
Why Lagom?

6. • Java 8
• Play 2.5
• Akka 2.4 (Clustering, Streams, Persistence)
• Cassandra (default data store)
• Jackson (JSON serialization)
• Guice (DI)
Under the hood

7. Developer experience

8. Enough slides,
Demo time

9. Service API

10. Each service definition is split into two sbt projects: api & impl
Anatomy Lagom project
my-lagom-system → Project root
└ helloworld-api → helloworld api project
└ helloworld-impl → helloworld implementation project
└ project → sbt configuration files
└ plugins.sbt → sbt plugins
└ build.sbt → Your project build file

11. Service definition
// this source is placed in your api project
public interface FriendService extends Service {
@Override
default Descriptor descriptor() {
return named("friendservice").withCalls(
namedCall("/api/users", this::createUser)
)
}
ServiceCall<User, String> createUser();
}

12. Service call explained
public interface ServiceCall<Request, Response> {
CompletionStage<Response> invoke(Request request)
}
• ServiceCall is invoked when consuming a service
• JSON is the default serialization format for request/response messages
• There are two kinds of request/response messages
• Strict
• Streamed

13. Strict Messages
default Descriptor descriptor() {
return named("friendservice").withCalls(
namedCall("/api/users", this::createUser)
)
}
ServiceCall<User, String> createUser();
Strict messages are buffered into memory

14. Streamed Messages
default Descriptor descriptor() {
return named("activityservice").withCalls(
pathCall("/activity/:userId", this::stream)
)
}
ServiceCall<NotUsed, Source<Tweet, ?>> stream(String userId);
• Streamed message is of type Source (Akka streams API)
• Back-pressured, asynchronous handling of messages
• Lagom selects transport protocol (currently WebSockets)

15. Remember the Service definition?
// this source is placed in your api project
public interface FriendService extends Service {
@Override
default Descriptor descriptor() {
return named("friendservice").withCalls(
namedCall("/api/users", this::createUser)
)
}
ServiceCall<User, String> createUser();
}

16. Service implementation
import com.lightbend.lagom.javadsl.api.*;
import akka.NotUsed;
import static java.util.concurrent.CompletableFuture.completedFuture;
@Override
public ServiceCall<User, String> createUser() {
return request -> completedFuture("Created user");
}

17. Intra-service communication
public class MyServiceImpl implements MyService {
private final friendService;
@Inject
MyServiceImpl(FriendService friendService) {
this.friendService = friendService;
}
…

18. Intra-service communication
@Override
public ServiceCall<NotUsed, String> addFriend() {
return request -> {
CompletionStage<String> userId =
friendService.createUser(user).invoke()
return userId;
}
}

19. Circuit breakers
• Circuit breaker is used to provide stability and prevent cascading failures
• Services calls interacting with Lagom services are using circuit breakers
by default
• Circuit breakers can be configured
• Each service call can have a separate circuit breaker

20. Persistence & Clustering

21. Service owns its data
FriendService
Friend DB
ChirperService
Chirper DB
ActivityStream
Service

22. Lagom Persistence
Lagom
Persistence
Event
Sourcing
CQRS
implements leads to

23. Persistent Entities
• Persistent Entity corresponds to an
Aggregate Root (DDD)
• Persistent Entities receive commands
• Triggered by a command, Persistent
Entities will change their state
• Example: Add friend, remove friend
FriendService
Peter
Bob
Alice

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

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

26. Lagom Cluster
• 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 Node B
Node C
XBob
Alice
Z
X
Y
Paul
Peter

27. Lagom Persistence
• But how does our data
survive a system crash?
• We log all the state changes!
• Persistent Entities are
recreated on another node
and all state changes are
replayed
Node A Node B
Node C
XBob
Alice
Z
X
Y
Paul
Peter

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

29. Event sourcing: Storing deltas
User
Created
(Alice)
Friend
Added
(Bob)
Friend
Added
(Peter)
Friend
Removed
(Bob)

30. Traditional way
User
(Alice)
Friend
(Peter)
Friend
(Bob)

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

32. Persistent Entity
Data Store
(e.g. Cassandra Cluster)
FriendService
Y
Peter
FriendService
XBob
Alice
FriendService
Y
XY

33. Event Sourcing: Snapshots
1 2 100 101 102 103..
Snapshot

34. • Keep all data in memory
• Optional: Only working set, by using passivation/activation
• Store all state changes as events
• Replay all events to re-create the state
• Optional: Start from snapshot
• Scale out with Lagom Cluster and scalable data store
Event Sourcing with Lagom Persistence

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

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

37. • Derived from event log
• Can be discarded and re-created
• The “book of record” is the event log
• Can be scaled out by creating copies - it’s read only
Read-Side

38. Consistency
FOLLOWERS
userid followedby
Bob Alice
Bob X
Bob Y
Peter Alice
Data Store
(e.g. Cassandra Cluster)
Alice1 - Persistent
Entity
2 - Journal / Event Log
3 - Read Side

39. Consistency
Alice
• Persistent Entities define 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
1 - Persistent
Entity

40. Consistency
• Depending on implementation and
configuration
• Popular choice: Casssandra
• “Tunable consistency”
• Use of quorums ensures consistencyData Store
(e.g. Cassandra Cluster)
2 - Journal / Event Log

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

42. Event Sourcing with Lagom Persistence revisited
• Keep all data in memory!
• Store all state changes as events
• Replay all events of a Persistent Entity to recreate it
• Strong consistency for Persistent Entity (aggregate) and Journal
• Eventual consistency for Read-Side

43. What if I don’t want to use Event Sourcing?
• Don’t use Lagom Persistence
• You can use any data store
• Beware of blocking APIs (JDBC)

44. Production

45. • sbt-native packager produces several packages
• ZIP
• Docker
• RPM
• ConductR bundle
Packaging

46. • Infrastructure need to support Akka clustering
• Deployment tool
• Need to implement Lagom service locator interface
• Should handle node failure scenarios
Production considerations

47. • Akka Cluster support
• Service locator
• Consolidated logging
• Restart services automatically
• Handling network failures
• Rolling updates
• Monitoring support
ConductR

48. ConductR Demo

49. • Maven support
• Message broker integration
• Scala API
• Support for other orchestration tools
• Support for writing integrations tests
• Swagger integration
Next steps

50. • 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

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