TL;DR notes from articles I read today.
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
Forget monoliths versus microservices. Cognitive load is what matters
- As psychologist John Sweller describes it, cognitive load is the total mental effort in working memory. It can be intrinsic (aspects fundamental to the task), extraneous (relating to the environment the task is done in), and germane (aspects needing special attention for learning or higher performance).
- You should aim to minimize intrinsic load (with training, technologies, hiring, pair programming, etc.) and eliminate the extraneous load of boring or superfluous tasks to allow more space for germane cognitive load, or value-added thinking.
- Prevent a software system from growing beyond the cognitive load of the team responsible for it. Explicitly define platforms and components to reduce extraneous load too.
- Create well-defined interaction patterns among the team. Also, minimize inter-team dependencies.
- Rather than small, cross-functional product or feature teams, build independent stream-aligned teams (based on a line of business, or market segment or specific geography, for example) that can analyze, test, build, release and monitor changes largely without affecting other teams.
- Build the thinnest viable platform for each team, with the smallest set of APIs, documentation, and tools to accelerate their work.
Full post here, 9 mins read
Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().
Latest comments (2)
Netflix architecture is amazing to study, especially when it comes to distributed systems. Their engineering blog is fantastic and has taught me so much.
I've also gotten a ton out of the highscalability blog - here's one of their posts on what happens when you press play on Netflix
Thanks for the link to the Netflix post on HighScalability! It was a great read. Their engineering blog is very informative and makes for a great read on Distributed Systems.