Often when working with Microservices we consider ‘promoting’ a certain component into a Microservice. This comes with a remarkable operational price (additional codebase, DB instance, monitoring, etc) hence By default we should strive for the simple solution – use classes, modules, packages or any other stateless component type. If this is still not sufficient, before opting for the fancy solution (Microservice) we might run our decision through a checklist that suggests whether this is necessary. The questionnaire checklist below means to remind all the reasons when to use Microservices and when to avoid. Goes without saying that the scoring gamification below doesn’t aim to provide empiric answers rather just to spice up the checklist
Answer and sum your score
- Start here – Start with zero, add or subtract points based on the questions belowStart with 0 points
- Different teams: Will the new component be developed by a separate team?If yes – add 10 points
- Dedicated technology: Is the component likely to be developed using a different programming language?If yes – add 20 points
- Simplicity: When not extracted out, do things get too complex to “fit in your head”?If yes – 10 point
- Failure isolation: Should and can this component stay alive and provide value when its collaborators crashed?
If yes – 7 points
- Operational complexity: Do you already have a Microservice infrastructure?
If no – subtract 5 points
- Granular deployment: Is this functionality likely be updated at a different pace than others without the need to update its collaborators?If yes – add 12 points
- Stateful service: Does it expose API, DB or any other stateful activity??If yes, add 3 points
- 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
- Independent scale: Is this component’s traction is likely to be different than others and might need to scale independently?If yes – add 8 points
- Dedicated infrastructure: Does the component deserver a unique hardware spec like GPU or extensive RAM support?If yes – add 20 points
- Change protection: Might this component get replaced sometime soon by another implementation, for example by a 3rd party product?If yes – add 3 points
- Avoid chatty flow: Is this functionality invoked multiple times during each flow (e.g. log, trace, etc)?If yes – subtract 10 points
Results – is it 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