‘Should I make it a Microservice?’
Often when considering, or working with Microservices, we are uncertain whether some component should be a Microservice. This component might be a mailer, price calculator, facebook connector, message queue facade, or anything that seems to benefit from being an autonomous component.
The checklist below means to give a sense of whether you need a Microservice or maybe it’s probably an overkill tool for your needs and you can deploy it as a package or maybe even just another class/object.
Although all the reasons below are valid and essential to consider, take the ‘gamification’ and scoring part with a sense of humor.
Answer all the questions and sum your score
- Start here — Start with zero, add or subtract points based on the questions below
Start with 0️⃣
Move to the next question 👇
2. Different teams: Will a different dedicated team develop this component?
If YES: ➕ add 10 points
Move to the next question 👇
3. Dedicated technology: Is the component likely to be developed using a different programming language?
If YES: ➕ add 20 points
Move to the next question 👇
4. Simplicity: When not extracted out, do things get too complex to “fit in your head”?
If YES: ➕ add 10points
Move to the next question 👇
5. Failure isolation: Should and can this component stay alive and provide value when its collaborators crashed?
If YES: ➕ add 7 points
Move to the next question 👇
6. Operational complexity: Do you already have a Microservice infrastructure?
If YES: ➕ add 5 points
Move to the next question 👇
8. Granular deployment: Is this functionality likely to be updated at a different pace than other components so you can update it without the need to update its collaborators?
If YES: ➕ add 12 points
Move to the next question 👇
9. Stateful service: Does it expose API, DB or any other stateful activity?
If YES: ➕ add 3 points
Move to the next question 👇
10. Ubiquitous language: Is this functionality represents an isolated product domain like a stand-alone feature or having a dedicated product manager?
If YES: ➕ add 3 points
Move to the next question 👇
11. Independent scale: Is this component’s traction is likely to be different than others and might need to scale independently?
If YES: ➕ add 20 points
Move to the next question 👇
12. Dedicated infrastructure: Does the component deserver a unique hardware spec like GPU or extensive RAM support?
If YES: ➕ add 20 points
Move to the next question 👇
13. Change protection: Might this component get replaced sometime soon by another implementation, for example by a 3rd party product?
If YES: ➕ add 3 points
Move to the next question 👇
14. Avoid chatty flow: Is this functionality invoked multiple times during each flow (e.g. log, trace, etc)?
If YES: ➖ subtract(!) 20 points
Move to calculate your results 👇
🗒️ Results — should it be a Microservice?
0–5 points
😂 Seriously? a function might be enough to satisfy your needs
5–10
🤦♂️ Oh No. Don’t be a drama queen, read about package managers, modules and other leaner isolation techniques
10–15
🤔 Hmm. If you don’t already have a Microservice infrastructure the ROI is likely to be negative
15–20
👍 Maybe. The value doesn’t seem critical — at least keep the overhead low
20–30
👌 Probably yes, mostly if it’s not your first Microservice
30–50
✌ Oh yes! This component by itself is a good reason to move toward a Microservice architecture
Final wording
Obviously, the scoring is just a nice game which shouldn’t be taken too seriously 😀
I’m curious, did the score made sense? feel free to suggest improvements
Stay in touch
Node.js best practices — 79 best practices for a robust Node application
