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 whether you need a Microservice or maybe it’s probably an overkill tool for your needs.
Although all the reasons below are valid and important to consider, take the ‘gamification’ and scoring part with a sense of humor.
Answer all the questions and sum your score
1. Start with zero, add or subtract points based on the questions below
|
1 2 3 |
Start with Zero Move to the next question ? |
2. Different teams: Will the new component be developed by a separate team?
|
1 2 3 |
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?
|
1 2 3 |
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”?
|
1 2 3 |
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?
|
1 2 3 |
If YES: ➕ add 7 points Move to the next question ? |
6. Operational complexity: Do you already have a Microservice infrastructure?
|
1 2 3 |
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?
|
1 2 3 |
If YES: ➕ add 12 points Move to the next question ? |
9. Stateful service: Does it expose API, DB or any other stateful activity?
|
1 2 3 |
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?
|
1 2 3 |
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?
|
1 2 3 |
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?
|
1 2 3 |
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?
|
1 2 3 |
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)?
|
1 2 3 |
If YES: ➖ substract(!) 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
✌ Absolutely, this is 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