Building Microservices - Sam Newman

microservices.md

WIP - Sam Newman - Building Microservices

• Take the SRP approach to services. Small, and focused on doing one thing well.
• The smaller the service the more you maximize the benefits and downsides of microservice architecture.
• Technology Heterogeneity.
• Rewrite in 2 weeks.
• Degrade functionality, don't cascade.
• Ease of deployment, and scaling.
• Small, autonomous teams -> Hard to achieve depending on company size.
• Replaceability.
• Libraries loses tech heterogeneity, and also need to redeploy each service.
• Be worried about what happens between the boxes and be liberal in what happens inside.
• Same monitoring, metrics, and even logging.
• Using REST? Use the same convention for naming and pagination.
• Example service being real world and not just a template.
• Morale and productive destroyed by having a mandated framework thrust upon developers.
• Loose coupling: change one service should not require change to another.
• Avoid chatty communication that leads to tight coupling.
• High cohesion: related behavior to sit together, unrelated elsewhere.
• Bounded context: explicit interface and decide which models to share. "a specific responsibility enforced by explicit boundaries".
• Start with a monolith, divide when the bounded context is stable.
• Avoid premature decomposition.
• What does this context do? What does it need to do that?
• Sync vs async.
• Orchestration vs choreography.
• Networks are not reliable.
• Rest vs RPC -> Stubs
• Retry limit even for amqp.
• Dead letter queue with UI
• DRY: Avoid duplicating system behavior and knowledge.
• Share libraries can create coupling.
• Don't violate DRY on a microservice but be relaxed about violating DRY across services.
• Anemic vs not anemic events. Consider freshness of data and use case.
• Be conservative in what you do, be liberal in what you accept from others, for example: read json fields you need.
• Versioning url and keep the old ones until other services migrate.
• API Composition to reduce chattiness where needed
• Backend for frontend.
• When dealing with third party being complicated, do a facade with friendly API as adapters.
• Split the monolith: Group things that are related, identify bounded context, remove FK keys, replace db interaction with API Calls between packages.
• Beware of domain concept that isn't modeled in the code but implicitly in the database. For example: warehouse and finance read/write to customer table, instead to customer service.
• Eventual consistency instead of transactional boundaries spawned in multiple services.
• Or, use distributed transaction. voting part => yes, then we commit (two phase commit); still have downsides like outages and locks.
• Reporting: projection, event data pump, only deltas. Data pump, everything. ETL work on replica CDC.
• Deploy add CI and practices, check in often, test, fix.
• Test quadrant: acceptance testing (did we built the right thing? - manual/automated) and exploratory (how can I break the system? - manual). Unit test (did we build it right? - automated) and property testing (automated, response time, etc)