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 : Reactive microservice framework

2,138 views

Published on

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

Published in: Software

Lagom : Reactive microservice framework

  1. 1. LagomReactive microservices framework #NightClazz @Lagom 12/05/16 Fabrice Sznajderman @fsznajderman
  2. 2. Agenda ● Core concepts ● Lagom framework ● Hands on Lagom
  3. 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. 4. Chapter 1 Core Concepts
  5. 5. Agenda ● Microservices architecture ● CQRS ● Event Sourcing Core concepts
  6. 6. Core concepts Microservices Architecture
  7. 7. Monolithic vs Microservices
  8. 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. 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. 10. What is a microservice? Standalone component
  11. 11. What is a microservice? Isolated
  12. 12. What is a microservice? Own its data
  13. 13. What is a microservice? Located microservice
  14. 14. What is a microservice? Communication by asynchronous message
  15. 15. What is a good microservice ? Answer with 3 questions ...
  16. 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. 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. 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. 19. Anti-pattern ● Adapted use-case? ● Transactionnal ● Distributed monolithic layers ● “Don’t Repeat Yourself” ● Shared data repository
  20. 20. That implies challenges ● Organisational impacts ● Monitoring of services ● Locating service ● Test strategy ● Distributed development environment
  21. 21. Reading Reactive Microservices Architecture by Jonas Boner
  22. 22. CQRS Core concepts
  23. 23. CQRS stands for ● Command ● Query ● Responsability ● Segregation
  24. 24. Traditional approach
  25. 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. 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. 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. 28. CQRS approach
  29. 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. 30. Other architecture
  31. 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. 32. Next CQRS design fits well with Event Sourcing pattern...
  33. 33. Event Sourcing Core concepts
  34. 34. Traditional approah Active record
  35. 35. Traditional approah Active record
  36. 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. 37. Event Sourcing approach ● Don't update the current state of objects ● Save the events that lead to the current state Different approach
  38. 38. Event Sourcing approach ● Complete log of every state change ● Debugability & tracability come easy ● Good performance (commit log) and more … Benefits
  39. 39. ● Complete rebuild ● Temporal query ● Event replay Event Sourcing approach More benefits
  40. 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. 41. ● Command’s name describe an action to do (imperative) ● Event’s name describe an action in the past Event Sourcing approach Remarks
  42. 42. Event Sourcing approach Restore state into model
  43. 43. Event Sourcing approach Deleting an object Update the query side with deletion of bank account.
  44. 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. 45. Lagom Framework Chapter 2
  46. 46. Agenda ● Big picture of Lagom ● Project structure ● My first microservice Lagom framework
  47. 47. Big picture of Lagom
  48. 48. Big picture of Lagom First of all, … Lagom pronounce :
  49. 49. What is Lagom? ● Microservices framework for a system of microservices ● Based on the Reactive principles ● A fully integrated development environment
  50. 50. Which language? ● Core of framework written in Scala ● Developments are in Java ● Scala version migth be available soon
  51. 51. Main features ● Service API ● Persistence API ● Development Environment ● Production Environment
  52. 52. Service API ● Interface as descriptor ● Defined API of exposed services ● Synchronous request/response ● Asynchronous streaming message
  53. 53. Persistence API ● Provides event-sourced persisted entities ● CQRS Read side ● Entry point for events handlers
  54. 54. Development Environment ● One command to start all services ● Hot reload of your code ● Several services provided out of the box ● IDE Integration
  55. 55. Production Environment ● ConductR for production environment ● Scaling ● Deployment ● Monitoring
  56. 56. Communication protocols ● Polyglot systems ● HTTP, WebSocket, JSON are standards ● can consumed ● can be consumed
  57. 57. Component technologies ● Collection of technologies ● Some come from Lightbend ● Others are third-party and open-source
  58. 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. 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. 60. Project Structure with Lagom
  61. 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. 62. Project tree
  63. 63. SBT build file ● Project configuration ● Describe all modules ● Describe all dependencies per module ● Host all parameters for project ○ cassandra ○ service locator ○ etc
  64. 64. Service declaration ● One service is composed of 2 sub- projects ○ API ○ Implementation ● Implementation depends on API
  65. 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. 66. Service imported ● One service could be imported as dependency ● Just declare it and it will start as others
  67. 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. 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. 69. Locator service ● All services register on this locator ● By default, one service locator is started ● It can be started apart
  70. 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. 71. Mapping of one Service
  72. 72. Write a service with Lagom
  73. 73. Demo Here, we will see : ○ Global configuration of project ○ Service Interface - Descriptor ○ Related implementation ○ All stuffs linked with persistence (CQRS-EventSourcing)
  74. 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. 75. Ok, now we can dive into dark side...code! ;)
  76. 76. Thank you! Next …
  77. 77. Hands on! Chapter 3

×