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.

Microservice architecture


Published on

Microservice architecture definition and common characteristics when using this architecture style

Published in: Technology
  • You can hardly find a student who enjoys writing a college papers. Among all the other tasks they get assigned in college, writing essays is one of the most difficult assignments. Fortunately for students, there are many offers nowadays which help to make this process easier. The best service which can help you is ⇒ ⇐
    Are you sure you want to  Yes  No
    Your message goes here
  • "No code, no mentions, but I promise to publish something on github :)" when and where is the link ?
    Are you sure you want to  Yes  No
    Your message goes here

Microservice architecture

  1. 1. Hello, my name is ... Xavier Fornés (@xfornesa)
  2. 2.
  3. 3. myTaste - World Wide
  4. 4. About the content...
  5. 5. New blog use case
  6. 6. What’s the problem? Problem ● Shared functionality across two applications Solution ● Duplicate implementation ● Share a library
  7. 7. Our CTO said...
  8. 8. What’s the problem? Problem ● Shared functionality across two applications ● Independently deployable Solution ● Duplicate implementation ● Share a library ● Implement a micro-Service
  9. 9. Hands on... Specialist team (focused on technology layer): ● UI Teams ● Server-side logic teams ● Database teams
  10. 10. ...
  11. 11. Conways law
  12. 12. Conways law Any organization that designs a system (defined broadly) will procedure a design whose structure is a copy of the organization’s communication structure. -- Melvyn Conway, 1967
  13. 13. Cross-functional teams
  14. 14. Development Build Deploy Maintenance A-Team Ops-Team M-Team Project model
  15. 15. Develop products
  16. 16. Development Build Deploy Maintenance A-Team Product model
  17. 17. It’s about freedom Tip: Use the right tool for the job But… Just because you CAN do something, doesn’t mean you should!
  18. 18. Service boundaries It’s useful thinking on bounded contexts from DDD Let’s each service manage its own database
  19. 19. Decentralizing data
  20. 20. Downsides: Manage updates Shared model ● Use transactions ● Temporal coupling of data Decentralized model ● Transaction less coordination between services ● Compensating operations
  21. 21. Downside: Allocating responsibility Problems ● No clear boundary responsibilities ● Move responsibilities across components
  22. 22. Communication patterns Change of mentality Problem ● Naive conversion from in-memory method calls to RPC leads to chatty communications ● Remote calls costly Solution ● Coarser-grained communication
  23. 23. Pipeline
  24. 24. Design for failure Monitoring To be sure all is working fine Types: ● Architecture elements (# queries to db) ● Business metrics (#users registered)
  25. 25. Evolutionary design Problems ● Versioning problems ● Evolute monolith core to micro-services ● Service cohesion
  26. 26. Summary
  27. 27. Micro-service architecture A no definition: “A particular way of designing software applications as suites of independently deployable services.”
  28. 28. Monolith apps vs micro-service Single logical executable Three parts: ● Client-site (UI) ● Server-side (app) ● Database (data) Problems: ● One change => Full app deployment ● Good modular structure hard to keep ● Scaling full application
  29. 29. Characteristics Common characteristics: ● Componentization via services ● Organization around Business capabilities ● Products not projects ● Smart endpoints and dump pipes ● Decentralized Governance ● Decentralized Data Management ● Infrastructure automation ● Design for failure ● Evolutionary Design
  30. 30. Componentization via services Something independently replaceable & upgradeable Remote calls are expensive Micro-service: ● Own services ● Own domain ● Own database
  31. 31. Teams organized around Business capabilities Segregation of teams: ● Specialists teams (by technology) ● Cross-functional Application architecture: ● When siloed application architecture ● When cross-functional teams
  32. 32. Products not projects Team responsible of one product in each step: ● Development ● Build ● Deployment ● Maintenance “You built it, you run it”
  33. 33. Smart endpoints & dump pipes Communication patterns Avoid chatty communications Unix approach => Well defined services Pipes act as filters
  34. 34. Decentralized Governance Choose best technology for each problem “It’s about freedom”
  35. 35. Decentralized Data Management Bounded Contexts Each micro-service with its own database Avoid transactions (distributed trans.) Compensation operations instead
  36. 36. Infrastructure automation Deployment should be boring Trust your pipeline: ● Unit & functional tests [dev] ● Acceptance tests [build] ● Integration tests [staging] ● User acceptance tests [UAT] ● Performance tests [Pre-prod]
  37. 37. Design for failure Monitoring ● Architecture elements ○ ex: # of database queries ● Business metrics ○ ex: # users registered
  38. 38. Evolutionary design Versioning problem, as a last resource Monolith core but evolution with micro-services Split components into services Service cohesion => merge services when changing together
  39. 39. Links & bibliography html microservice-architectures-by-sam-newman-1389
  40. 40. What about Silex? Sorry, no time left No code, no mentions, but I promise to publish something on github :) But ... … and so on ...
  41. 41. Thank you Questions? Don’t you prefer a beer instead?