‘Should I make it a Microservice?’

Yoni Goldberg
3 min readOct 27, 2019

--

‘Hmm I’m not sure whether to make this orange one a Microservice or maybe just keep it simple as a package’?

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

  1. 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

Follow me on Twitter ⭐️

Node.js best practices — 79 best practices for a robust Node application

45+ JavaScript testing best practices

--

--

Yoni Goldberg
Yoni Goldberg

Written by Yoni Goldberg

Software Architect, Node.JS Specialist. Consultant, blogger, conference speaker, open source contributor — author of the largest Node.js best practices guide

Responses (2)