The distributed-systems tax nobody put in the business case

The business case arrived from the provincial ICT office with a single number on its summary page. Splitting the fictional Magaliesberg Provincial Supplier Desk into separate registration, verification and case services would let each scale on its own, it said, and that would save about R14,000 a month in compute during quiet periods. The steering committee liked the number. Thabo Molefe and Refilwe Dlamini were asked to confirm it.

They did confirm it. The compute saving was plausible. Then they spent two days listing everything the business case had not counted, and the summary page acquired a second number that was larger than the first.

The Magaliesberg Provincial Supplier Desk is a fictional provincial supplier-support platform. All people, figures and rand amounts in this article are illustrative, chosen to show the shape of the calculation, not real prices. This part sets out the costs that come with every new deployable unit and how to put them in a business case.

A tax, not a fee

A fee is paid once. A tax recurs for as long as you hold the thing it is levied on. Most of the cost of a distributed design behaves like a tax: it starts on the day the first service is deployed and continues every month until the service is retired.

Our Agents on the Night Shift episode listed the operating responsibilities a service split creates. This part adds what that episode did not: a price for each line, and the question of who keeps paying it through the budget cycle. Martin Fowler called this recurring cost the microservice premium in 2015. Microsoft's microservices architecture guide (checked on 5 November 2026) lists its sources: more moving parts, harder testing across services, network latency, data consistency, versioning, the need for correlated logging and a mature DevOps culture. Neither source puts a number on it, because the number depends on your workload, your organisation and your prices. That is why your business case has to.

The ledger

The Supplier Desk grouped the tax into four parts. The headings are CloudNala's; the items under them are the ones the team found.

Run. The cost of the services existing. Each service needs a minimum footprint even at zero traffic: typically at least two instances for availability, a load balancer or ingress route, its own database or schema, its own connection pool. Messaging infrastructure appears where calls became events. Traffic between services that used to be a function call may now cross a network boundary and, depending on placement, attract data transfer charges. Smaller units are not automatically cheaper units, a point our article on serverless makes for a different design choice.

Observe. The cost of seeing what the services are doing. More services produce more logs, metrics and traces. Ingest and retention charges grow with volume, and tracing across services, described in Part 3, adds spans for every hop. Dashboards and alerts must be built and kept current for each service. Network resilience, observability and cost shows how quickly that visibility becomes a budget line of its own.

Protect. The cost of securing more boundaries. Each service needs an identity, credentials or certificates that are issued and rotated, network rules, and its own place in vulnerability scanning and penetration-test scope. Service-to-service authentication is new work that did not exist when the call was in-process.

People. The cost that rarely appears in any spreadsheet. More pipelines to maintain. More environments to keep in step, because a test environment now needs every service at a compatible version. Contract tests between services. On-call rotations that must cover more failure domains. Onboarding that takes longer because new engineers must learn how the services interact. Cross-service refactoring that used to be one pull request and is now a coordinated migration.

Putting numbers on it

The team priced each item roughly, in three bands: what the current modular monolith costs, what the proposal would cost, and the difference. The exercise took two days, mostly spent asking colleagues what things actually cost.

The figures are illustrative. The shape is not unusual: the run cost alone ate most of the saving, and the people cost was the largest line. It was also the line the original business case had left blank, because staff time is already budgeted and nobody sends an invoice for it. That does not make it free. It means it comes out of feature work instead. Our article on why architecture decides the bill explains why these choices dominate cloud cost; this ledger is the version for a single architecture decision.

Weigh the tax against the benefit, in the same unit

The original case compared a benefit in rand with no cost at all. The revised case compares like with like.

The test is whether the measured benefit, expressed in the same units and over the same period, exceeds the recurring tax by enough to justify the risk of change. Some benefits are not rand: faster releases for one capability, a smaller blast radius for a security-sensitive component, the ability for a second team to work without waiting. Those are real, and the evidence gate in Part 1 asks for them to be measured. They should be stated as clearly as the costs, not used to wave the costs away.

For the Supplier Desk, there was no such benefit in the proposal. Registration, verification and cases changed together, were owned by the same team, and had no independent scaling problem that a well-tuned single deployment could not handle. The steering committee declined the split and asked instead for the one change that would capture most of the saving: scaling the existing application down outside business hours.

Where the tax is worth paying

The tax is not an argument against services. It is an argument for paying it only where it buys something. The Supplier Desk pays it for notifications, extracted after the evidence in Part 3, because burst isolation protected document upload during closing weeks. That ledger showed a smaller tax, because one service adds less than three, and a clear benefit measured in upload failures avoided.

Signs that the tax is likely to be worth paying:

• One component has a load profile that forces the rest to scale with it, and the extra compute is large relative to the tax.
• One component's failures repeatedly harm unrelated user journeys.
• A security or regulatory boundary requires separate credentials, network paths or administrators.
• A durable second team is measurably blocked by a shared release.

Signs that it is not:

• The benefit is described as "future scale" or "flexibility" with no date or measure.
• The components change together and are owned by one team.
• The saving is in compute alone, and the people line is blank.

A tax must survive the budget cycle

Public-sector budgets are approved year by year, and many private-sector technology budgets behave the same way. A one-off build cost is approved once. A recurring tax must be approved again every year, often by people who were not in the room when the architecture was chosen.

That changes what the business case needs to say. It must show not only the monthly figure, but who will hold that budget line in year two and year three, and what happens if it is cut. For the Supplier Desk, the honest answer for the three-service proposal was uncomfortable: if the observability and on-call lines were cut in a lean year, the services would keep running with less visibility and slower incident response, which is the worst combination for a distributed system. A modular monolith degrades more gracefully under the same cut, because there are fewer things to watch.

This is CloudNala analysis, not a published rule, but it is a question every steering committee can ask: if this budget line disappears in two years, what breaks first?

A business-case template that includes the tax

Every service proposal at the Supplier Desk now carries a one-page appendix with these headings:

1. Benefit claimed, with current evidence and the unit it is measured in.
2. Run tax: minimum footprint, messaging, data transfer.
3. Observe tax: logging, tracing, retention, dashboards.
4. Protect tax: identities, secrets, certificates, scan and test scope.
5. People tax: pipelines, environments, contract tests, on-call, onboarding, refactoring.
6. Net effect, and the review date on which it will be checked.

It is not precise. It does not need to be. A rough ledger that includes every line is far more useful than a precise number that includes one. For costs that change with usage, our cloud cost governance framework covers how to keep the estimate honest after go-live.

Key points

• Most of the cost of a distributed design recurs every month for as long as the services exist.
• Group the tax into run, observe, protect and people, and price every line, even roughly.
• The people line is usually the largest and the one most often left blank.
• Compare benefit and tax in the same units over the same period, and set a review date.
• Pay the tax where it buys isolation, security or team independence you can measure, not for "future scale".

Previous: Part 5, Microservices are an organisational architecture. Next: Part 7, Extract the module with its data. All parts are on the series page.

How CloudNala can help

CloudNala builds the distributed-systems ledger for proposed architecture changes. We price run, observe, protect and people costs against your actual platform and team, compare them with the measured benefit, and give your steering committee a business case that shows both numbers, so that any service you approve is one you can afford to keep.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an Architecture Complexity Review or write to us at consult@cloudnala.co.za