Feedback on Meetic journey to migrate from a monolithic PHP application to a MicroServices architecture using PHP & Symfony. First presented at Symfony Live Paris 2017 in March 2017 by Etienne Broutin, Software Architect @MeeticTech
5. 2013 Reasons for refactoring plan
Unmaintainable code
Duplicates
Untestable
Need elders validation
Unable to monitor
Continue on failure policy
Based on global log volume
8. But new issues
Duplicated business logic
Merge conflicts
Longer tests (40min)
Refactorings started to become more and more difficult
9. We were building a new monolith !
Only 15% of business features
Only 10 developers, target 40
10. Micro-service pros
• Simpler design phase
• Manage refactoring impacts
• Faster feedbacks by software factory
• Faster deployments
• Real ownership by developers, easier upgrades
11. Micro-service cons
• Implementation of interfaces
• Response time
• CPU and network usage
• Time to setup a new application
• Can also become hard to understand
19. Data isolation
Strong and difficult choice But
• brings scalability
• brings visibility
• data consistency
• enables caching
• manage data migration
20. Limits of data isolation
Build a denormalized
database
OLTP
Reactive (event bus)
Batch processing
BI
23. In practice
2/3 of our micro-services
do not depend
on another micro-service
took several
refactorings for that
24. Defining perimeter is the key
Messages Authentication
nickname
business model
account status
Photo Announce Moderation
Photo +
Moderation
Announce +
Moderation
25. Event bus to manage dependency
Event bus
Consumer
Consumer
Profile Mailing Optin
26. get photos
Pattern 1 : Pull data
- performance
- reusability
does have a
photo itself ?can see photos ?
+ hides complexity for clients
+ fast change of business rules
Exposition Layer
Rights Photo
27. Pattern 2 : Push data from client
+ mutualize data fetching - harder to change if multiple clients
send message
Exposition Layer
Rights
Message
conversation
already started ?
can start
a new conversation ?
28. Pattern 3 : Store data
Event bus
read message
Exposition Layer
Message
get visible
messages
Blacklist
+ performance
+ reusable
- long to implement
blacklist added
hide messages
34. Can I use any
framework ?
Any
langage ?
Any database ?
35. Common interface
• REST + JSON
• Naming conventions
• Security
• Common build
• Common deployment chain
36. Don’t waste time : need a common basis
Micro-services chassis
• Security
• Logging
• HTTP Interface
• DB & cache components
37. Share knowledge with non-tech teams
Talkative names
Visibility for project management
profile will be
updated soon
changes on
message are
ready
thanks
41. Hosting concerns
It will overload the network !
It will take time to configure !
We will need much more
servers !
42. Figures
1B calls / day
25ms response time
100 servers
Who calls micro-services ?
Exposition LayerEvent Bus
Micro-services
43. Networking
• Every Micro-services deployed on
each server
• Affinity for inter micro-service call
Have not experienced need for :
• Service isolation
• Network constraints
45. Monitoring Alerting
Elastic Search + Logstash +
Kibana
• Easy to locate errors
• Performance analysis
Monitoring route for every
dependency
GET /profile/{accountId} 11ms 100%
POST /profile/ 42ms 99.992%
...
P
P
50. Feedback on that choice
For Meetic, this architecture was a good choice :
• Symfony helps standardization
• Can scale teams
• Clear implementation of all features
• Answer business needs