Microservice architecture
15 likes6,239 views
The document discusses microservice architecture and contrasts it with monolithic applications. It describes characteristics of microservices including componentization via independently deployable services, organizing teams around business capabilities rather than technology, treating products not projects with dedicated teams, using smart endpoints and dumb pipes for communication, decentralized governance and data management, and designing for evolutionary development and failure. The document provides examples of these concepts and references additional resources on microservice architecture.
![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]](https://image.slidesharecdn.com/microservices-140601125219-phpapp02/85/Microservice-architecture-38-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Microservice architecture (20)
Ad
Recently uploaded (20)
Microservice architecture
- 3. Hello, my name is ... Xavier Fornés (@xfornesa) http://www.xavierfornes.com
- 4. myTaste.com
- 5. myTaste - World Wide
- 7. New blog use case
- 8. What’s the problem? Problem ● Shared functionality across two applications Solution ● Duplicate implementation ● Share a library
- 10. What’s the problem? Problem ● Shared functionality across two applications ● Independently deployable Solution ● Duplicate implementation ● Share a library ● Implement a micro-Service
- 11. Hands on... Specialist team (focused on technology layer): ● UI Teams ● Server-side logic teams ● Database teams
- 12. ...
- 13. Conways law
- 14. 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
- 16. Development Build Deploy Maintenance A-Team Ops-Team M-Team Project model
- 17. Develop products
- 18. Development Build Deploy Maintenance A-Team Product model
- 19. It’s about freedom Tip: Use the right tool for the job But… Just because you CAN do something, doesn’t mean you should!
- 20. Service boundaries It’s useful thinking on bounded contexts from DDD Let’s each service manage its own database
- 22. Downsides: Manage updates Shared model ● Use transactions ● Temporal coupling of data Decentralized model ● Transaction less coordination between services ● Compensating operations
- 23. Downside: Allocating responsibility Problems ● No clear boundary responsibilities ● Move responsibilities across components
- 24. 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
- 25. Pipeline
- 26. Design for failure Monitoring To be sure all is working fine Types: ● Architecture elements (# queries to db) ● Business metrics (#users registered)
- 27. Evolutionary design Problems ● Versioning problems ● Evolute monolith core to micro-services ● Service cohesion
- 28. Summary
- 29. Micro-service architecture A no definition: “A particular way of designing software applications as suites of independently deployable services.”
- 30. 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
- 31. 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
- 32. Componentization via services Something independently replaceable & upgradeable Remote calls are expensive Micro-service: ● Own services ● Own domain ● Own database
- 33. Teams organized around Business capabilities Segregation of teams: ● Specialists teams (by technology) ● Cross-functional Application architecture: ● When siloed application architecture ● When cross-functional teams
- 34. Products not projects Team responsible of one product in each step: ● Development ● Build ● Deployment ● Maintenance “You built it, you run it”
- 35. Smart endpoints & dump pipes Communication patterns Avoid chatty communications Unix approach => Well defined services Pipes act as filters
- 36. Decentralized Governance Choose best technology for each problem “It’s about freedom”
- 37. Decentralized Data Management Bounded Contexts Each micro-service with its own database Avoid transactions (distributed trans.) Compensation operations instead
- 38. 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]
- 39. Design for failure Monitoring ● Architecture elements ○ ex: # of database queries ● Business metrics ○ ex: # users registered
- 40. 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
- 42. 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 ...
- 43. Thank you Questions? Don’t you prefer a beer instead?