Microservice architecture definition and common characteristics when using this architecture style

3. Hello, my name is ...
Xavier Fornés (@xfornesa)
http://www.xavierfornes.com

4. myTaste.com

5. myTaste - World Wide

6. About the content...

7. New blog use case

8. What’s the problem?
Problem
● Shared functionality across two applications
Solution
● Duplicate implementation
● Share a library

9. Our CTO said...

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

15. Cross-functional teams

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

21. Decentralizing data

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

41. 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

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?