Adopting microservices at Netflix: lessons for architectural design
- Create a separate data store for each microservice and let the responsible team choose the DB that best suits the service. To keep different DBs in sync and consistent, add a master data management tool to find and fix inconsistencies in the background.
- Use the immutable infrastructure principle to keep all code in a given microservice at a similar level of maturity and stability. So, if you need to add or rewrite code for a service, it is best to create a new microservice, iterate and test it until bug-free and efficient, and then merge back once it is as stable as the original.
- You want to introduce a new microservice, file or function to be easy, not dangerous. Do a separate build for each microservice, such that it can pull in component files from the repository at the appropriate revision level. This means careful checking before decommissioning old versions in the codebase as different microservices may pull similar files at different revision levels.
- Treat servers, especially those running customer-facing code, as stateless and interchangeable members of a group for easy scaling. Avoid ‘snowflake’ systems where you depend on individual servers for specialized functions.
Full post here, 7 mins read