Based on Microservices presentation by Martin Fowler recorded at GOTO Berlin 2014.
- Components (= independently upgradable, replaçable) communicating through services (instead of libs for monoliths)
- Organized around business capabilities
- Smart endpoints and dumb pipes. Routing logic is managed by end-points
- Decentralized data management. Each Microservice manages its own data
- Infrastructure automation. Automatic delivery, Continuous deployment and monitoring tools are necessary
- Designed for failure. You have to design thinking about faults and unavailibility of one or many Microservices
- Evolutive design
- SOA, different definitions for different people. For some of them, this means ESB. But ESB are not compatible with third Microservices common caracteristic.
- MicroServices ⊂ SOA. Microservices architecture is a subset of SOA.
- Allows different technologies per components
- Component internal evolution minimise impacts compared to a functionnality or module evolution within a Monolith
- Different Microservices deployed on different machines compared to a Monolith cluster. If Microservice A is more loaded than B, A can be scaled horizontally but not B
- Feature teams organization (Catalog, order management, ...) compared to teams organized by technologies (DBA, .Net Devs, ...)
- No unique database mess which leads to hard model refactoring, deadlocks between different functionalities.
- Platform / Technologies best suited for a specific Microservice
- Simplicity
- Consistence
- Inter-module refactoring
- Partial deployment
- Avaibility (If A Microservice fails, users still can use a fonctionnality managed by B, with a design for failure)
- Preserve modularity
- Platform / Technology best suited
- Rapid provisioning (rapid environment set-up)
- Basic monitoring
- Rapid applications deployment
- Devops culture