My keynote speech from J On The Beach 2016, about microservices and Lightbend's Lagom framework

1. The Future of Services
Jamie Allen
Sr. Director of Global Solutions Architects

2. @jamie_allen
Traditional application architectures
and platforms are obsolete.
Gartner

3. @jamie_allen
• Accelerate teams
• Reduce dependency nightmares
• Increase application throughput
What are we trying to achieve?
Calvin and Hobbes, Bill Waterston

4. @jamie_allen
• Size is irrelevant
“Microservices” is a lousy term
Bing Images

5. @jamie_allen
• At the API
• In our source
• For our data
We want isolation
Wikipedia, Creative Commons, created by DFoerster

6. @jamie_allen
We want realistic data management
• Use CQRS and Event Sourcing, not CRUD
• Transactions, especially distributed, will not work
• Consistency is an anti-pattern at scale
• Distributed locks and shared data will limit you
• Data fabrics break all of these conventions
Think in terms of compensation, not prevention.
Kevin Webber, Lightbend

7. @jamie_allen
We want to ACID v2
• Associativity, not Atomicity
• Commutativity, not Consistency
• Idempotent, not Isolation
• Distributed, not Durable
Wikipedia, Creative Commons, created by Weston.pace

8. @jamie_allen
We want real resilience
• It is merely whether or not something has been handled
• It is only an external view, not internal where the failure has occurred
• Resilience is being able to handle the “why” in a meaningful way
• Threads
• Within One Node
• Across Many Nodes
• Across Many Servers
• Across Data Centers

9. @jamie_allen
We want asynchronous APIs
• Synchronous request/response semantics are expensive
• REST can be asynchronous, but still heavy
• Each call requires a connection
• Best used for external APIs
• Stream-based interactions for inter-service communication where responses
are not required
• Message-based interactions for inter-service communication where
responses are required

10. @jamie_allen
We want immutable deployments
• We can bind a build of our application to a version of our configuration and
always know what is currently running
• You cannot edit configuration and keep running
Dilbert, Scott Adams

11. @jamie_allen
We want to expose a “tip of the iceberg”
• Users see the public API
• The API hides much complexity
MyBluePuzzle.org

12. @jamie_allen
We want Domain Driven Design
• Knowing/understanding it is not necessarily a requirement
• “Solving your pain” is the most important reason for microservices
• In a greenfield project, Bounded Contexts and Aggregate Roots can help
you to decompose the problem

13. @jamie_allen
• Proxying
• Service Discovery
• Stateless aggregation
• Orchestration
• Failure management
• Versioning
We will have additional operational complexity
Complexityandotherbeasts.com

14. @jamie_allen
• Service API
• Persistence API
• Development environment
• Production environment

15. @jamie_allen
• IO and communication
• Streaming between services as a first-class concept
• Higher level of resilience and scalability with no bloc
king
• Service is a Bounded Context in DDD
Lagom Service API

16. @jamie_allen
• Event sourced (deltas) with Cassandra backend by
default
• No object/relational impedance mismatch
• Can always replay to determine current state
• Allows you to learn more from your data later
• Persistent entity is an Aggregate Root in DDD
• Can be overridden for CRUD if you want
Lagom Persistence API

17. @jamie_allen
• Create single project definition in sbt, use runAll, incl
udes:
• In-memory Cassandra with own keyspaces
• A service locator
• A service gateway
• Overload Mode: recompile and redeploy on save
Development Environment

18. @jamie_allen
• Deployment
• Monitoring
• Scaling
• Can test locally with ConductR then push to producti
on
• Launch multiple instances with a single command
Production Environment (Lightbend RP)

19. @jamie_allen
Links
Project Site:
http://www.lightbend.com/lagom
GitHub Repo:
https://github.com/lagom
Documentation:
http://www.lagomframework.com/documentation/1.0.x/Home.h
tml