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
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
22. Downsides: Manage updates
Shared model
● Use transactions
● Temporal coupling of data
Decentralized model
● Transaction less coordination between
services
● Compensating operations
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
26. Design for failure
Monitoring
To be sure all is working fine
Types:
● Architecture elements (# queries to db)
● Business metrics (#users registered)
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
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 ...