Microservice architecture

5,315 views

Published on

Microservice architecture definition and common characteristics when using this architecture style

Published in: Technology
1 Comment
14 Likes
Statistics
Notes
No Downloads
Views
Total views
5,315
On SlideShare
0
From Embeds
0
Number of Embeds
1,215
Actions
Shares
0
Downloads
121
Comments
1
Likes
14
Embeds 0
No embeds

No notes for slide

Microservice architecture

  1. 1. Hello, my name is ... Xavier Fornés (@xfornesa) http://www.xavierfornes.com
  2. 2. myTaste.com
  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 http://es.memegenerator.net http://martinfowler.com/articles/microservices.html http://www.infoq.com/articles/CCC-Jimmy-Nilsson http://alistair.cockburn.us/Hexagonal+architecture http://davidmorgantini.blogspot.com.es/2013/08/micro-services-introduction. html http://domaindrivendesign.org/ http://yow.eventer.com/yow-2013-1080/practical-considerations-for- 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 ... http://www.slideshare.net/hhamon/silex-meets-soap-rest http://sleep-er.co.uk/blog/2013/Creating-a-simple-REST-application-with-Silex/ https://github.com/vesparny/silex-simple-rest … and so on ...
  41. 41. Thank you Questions? Don’t you prefer a beer instead?

×