Post on 10-May-2015
Embed Size (px)
DESCRIPTIONMicroservice architecture definition and common characteristics when using this architecture style
- 1.Hello, my name is ... Xavier Forns (@xfornesa) http://www.xavierfornes.com
2. myTaste.com 3. myTaste - World Wide 4. About the content... 5. New blog use case 6. Whats the problem? Problem Shared functionality across two applications Solution Duplicate implementation Share a library 7. Our CTO said... 8. Whats the problem? Problem Shared functionality across two applications Independently deployable Solution Duplicate implementation Share a library Implement a micro-Service 9. Hands on... Specialist team (focused on technology layer): UI Teams Server-side logic teams Database teams 10. ... 11. Conways law 12. Conways law Any organization that designs a system (defined broadly) will procedure a design whose structure is a copy of the organizations communication structure. -- Melvyn Conway, 1967 13. Cross-functional teams 14. Development Build Deploy Maintenance A-Team Ops-Team M-Team Project model 15. Develop products 16. Development Build Deploy Maintenance A-Team Product model 17. Its about freedom Tip: Use the right tool for the job But Just because you CAN do something, doesnt mean you should! 18. Service boundaries Its useful thinking on bounded contexts from DDD Lets each service manage its own database 19. Decentralizing data 20. Downsides: Manage updates Shared model Use transactions Temporal coupling of data Decentralized model Transaction less coordination between services Compensating operations 21. Downside: Allocating responsibility Problems No clear boundary responsibilities Move responsibilities across components 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. Pipeline 24. Design for failure Monitoring To be sure all is working fine Types: Architecture elements (# queries to db) Business metrics (#users registered) 25. Evolutionary design Problems Versioning problems Evolute monolith core to micro-services Service cohesion 26. Summary 27. Micro-service architecture A no definition: A particular way of designing software applications as suites of independently deployable services. 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. 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. Componentization via services Something independently replaceable & upgradeable Remote calls are expensive Micro-service: Own services Own domain Own database 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. Products not projects Team responsible of one product in each step: Development Build Deployment Maintenance You built it, you run it 33. Smart endpoints & dump pipes Communication patterns Avoid chatty communications Unix approach => Well defined services Pipes act as filters 34. Decentralized Governance Choose best technology for each problem Its about freedom 35. Decentralized Data Management Bounded Contexts Each micro-service with its own database Avoid transactions (distributed trans.) Compensation operations instead 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. Design for failure Monitoring Architecture elements ex: # of database queries Business metrics ex: # users registered 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. 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. 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. Thank you Questions? Dont you prefer a beer instead?