Free calculator · Engineering
Are you ready for microservices? A 13-question assessment
Answer thirteen questions about team size, release independence, delivery, observability and data. The assessment scores Need and Readiness out of 100, caps Readiness when core practices are missing, flags distributed-monolith risk and recommends a monolith, a modular monolith or incremental extraction.
How this is calculated
Each answer scores points. Need and Readiness are each the points scored as a share of the points available, out of 100. A gate caps Readiness when core practices are missing, a separate check flags distributed-monolith risk, and the two scores together choose one of four recommendations.
Step by step
- Need: headcount (0–4 points), teams that must release independently (0–3) and main motivation (0–3), out of 10 points, scaled to 100 and rounded.
- Readiness: ten questions worth 0–2 points each, out of 20 points, scaled to 100 and rounded. Fewer cross-module changes and less database sharing score higher.
- Gate: if deploys are manual, logs and metrics aren't centralised, or there is no tracing, Readiness is capped at 49.
- Distributed-monolith risk: flagged when modules share database tables and 50% or more of changes touch more than one module.
- Recommendation: Need below 40 keeps a well-structured monolith; 40 to 59 suggests a modular monolith, extracting only a proven hotspot; 60 or more with Readiness below 60 suggests a modular monolith first while closing the gaps; 60 or more with Readiness of 60 or more suggests incremental strangler-fig extraction.
- Gaps: every Readiness answer below full marks becomes a next step, with the gate practices listed first.
Default assumptions
Assumptions marked adjustable can be changed in the calculator; the others are fixed parts of the model.
| Assumption | Default | Sources |
|---|---|---|
| Readiness cap without automated deploys, central logs and metrics, or tracing | 49 out of 100 | |
| Need below which a well-structured monolith is recommended | 40 out of 100 | |
| Need at which extracting services is worth considering | 60 out of 100 | |
| Readiness needed before strangler-fig extraction | 60 out of 100 | |
| Share of cross-module changes that, with a shared database, flags a distributed monolith | 50% |
What this doesn’t model
- The questions and point values are a structured judgement, not a validated survey instrument; two teams with the same scores can still differ.
- It doesn't weigh cost, hiring, compliance or the business case for change.
- Answers are self-reported and cover the whole system; a single hotspot may justify a service even when the overall scores don't.
- Thresholds are cut-offs this tool sets to encode the cited guidance; they are not taken from a study.
Sources
- Martin Fowler, Microservice prerequisites (28 Aug 2014). Accessed . Rapid provisioning, basic monitoring and rapid application deployment, with developers and operations working closely together.
- Martin Fowler, MonolithFirst (3 Jun 2015). Accessed . Microservices carry overhead that slows teams on simpler applications; service boundaries are hard to get right at the start, so begin with a monolith.
- Martin Fowler, Strangler Fig (22 Aug 2024). Accessed . Build new components beside the old system and move behaviour across gradually, instead of a single rewrite.
- Sam Newman (O'Reilly), Monolith to Microservices. Accessed . Covers when microservices are a bad idea, the strangler fig pattern and decomposing the database.
- Sam Newman (O'Reilly), Building Microservices, 2nd edition. Accessed .
- Matthew Skelton and Manuel Pais (IT Revolution), Team Topologies (2019). Accessed . Team cognitive load as a design principle; a second edition followed in 2025.
- DORA, Capabilities: loosely coupled teams. Accessed . Teams can deploy, test and change their design without depending on other teams; adopting microservices does not by itself achieve this.
Last reviewed by the QuantmHill engineering team. Found an error?
Link to or cite this tool
Writing about this topic? Link to the calculator or cite it. Its method, defaults and sources are all on this page, so readers can check the numbers.
Embed this calculator
You can put this calculator on your own site for free. Paste the code below where it should appear. It loads the same calculator in a frame, with a link back to this page for the full method and sources.
The credit line links to this page with the anchor text “QuantmHill”. You may edit it, add rel="nofollow" or remove it — the calculator works the same either way. Add ?theme=light or ?theme=dark to the iframe address to fix its colour scheme; otherwise it follows the visitor's system setting.
Add this once per page, after the iframe, if you want the frame to grow and shrink with the calculator instead of using the fixed height above. It accepts messages from quantmhill.com only and resizes only the frame that sent them.
Frequently asked questions
Two scores out of 100. Need comes from 3 questions on engineering headcount, how many teams must release independently and why you are considering microservices. Readiness comes from 10 questions on on-call ownership, domain boundaries, cross-module changes, deployment, contract tests, logging, tracing, platform experience and database sharing.
Because some practices come first. If deploys are manual, logs and metrics aren't collected in one place, or requests can't be traced across components, Readiness can't reach the level at which the tool recommends extracting services. Martin Fowler's Microservice Prerequisites names rapid deployment and basic monitoring among the things to have before running microservices.
A system split into services that still have to change and release together, usually because they share database tables. The tool flags the risk when modules share tables and at least half of your changes touch more than one module, since splitting along those lines would keep the coupling and add network calls.
Because that is where the evidence points for most teams. Martin Fowler's MonolithFirst argues that microservices add overhead and that service boundaries are hard to get right early. A monolith with enforced module boundaries gives you most of the structure and keeps the option to extract services once a real need appears.
The cut-offs of 40 and 60 for Need, 60 for Readiness and the cap of 49 are set by this tool, not taken from a study. They encode the ordering the cited sources argue for: the practices before the services, and the need before either. The methodology shows how every answer is scored.
Want an engineer to check your numbers?
Send us your inputs and the decision you're weighing. We'll reply within one business day with an honest read on whether we can help.