# Compare one deployable application with several operated services

Service boundaries add independent control and operational work. Compare the cost of the problem being solved with the cost of running the split.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Measure the constraint inside the monolith

Identify whether the application is limited by one expensive capability, a slow deployment process or tightly coupled team work. Those are different problems and may not need the same architectural response.

A background image-processing module might need separate scaling, while an order-rule change may simply need a clearer internal contract. Splitting both into services because they are different folders ignores their actual operating needs.

Use workload and change evidence. Record resource use, release frequency and incidents that would plausibly improve with separation.

## Count the new operating units

Each service needs deployment, configuration, identity, monitoring, failure handling and ownership. Network calls introduce timeouts and uncertain results that local calls did not have in the same form.

Include non-production environments and integration testing. A small team can spend substantial time keeping several services compatible before users receive any additional value.

Managed infrastructure can reduce some work, but it does not remove responsibility for contracts, data ownership and recovery. The architecture should name who performs those tasks.

## Compare scaling with realistic demand

A monolith may require scaling the whole application when one module is busy. A separate service can target that load more precisely, but its baseline capacity and communication overhead also count.

Benchmark the intended workload rather than assuming independent scaling always costs less. A rarely used service with dedicated resources can be less economical than a module sharing an existing process.

Consider failure isolation too. A separate process can contain some failures, while a shared downstream dependency may still couple availability. Draw the actual dependency path before claiming isolation benefits.

## Include the migration and recovery cost

Data movement, compatibility windows and rollback planning can dominate the initial effort. A service extraction that changes the authoritative writer needs more than a routing switch.

Compare the expected benefit over a meaningful period with implementation and ongoing ownership. Keep uncertain assumptions visible rather than assigning precise savings to unmeasured improvements.

Choose the smallest architecture that addresses the demonstrated constraint. A modular monolith and a service-based system are both tools. The useful decision explains which operating problem the additional boundary solves and why the team can maintain it.

## Sources

- [Microsoft Learn: common web application architectures](https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures)
- [Martin Fowler: Monolith First](https://martinfowler.com/bliki/MonolithFirst.html)