About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Size a hosted application from measured demand and the service requirements you intend to support. Decide which resources are shared, which are separately allocated and which guarantees the underlying platform can actually enforce. A usage limit is not a reservation, and a separate virtual machine is not automatically a guarantee of end-to-end performance.
Dedicated customer environments can simplify some operational boundaries. Shared pools can use capacity more efficiently when demands do not coincide. Neither design removes the need to measure bottlenecks, enforce appropriate controls and validate the promised outcome.
Use precise capacity terms
Record what each configured value means for the actual platform:
| Term | Question to answer |
|---|---|
| Allocation | What resource is assigned or exposed to this workload? |
| Reservation or guarantee | What minimum is actually protected, under which conditions? |
| Limit | What maximum consumption is permitted, and how is excess handled? |
| Quota | What quantity is allowed, such as stored bytes or objects? |
| Observed performance | What does the application deliver under the measured workload? |
These are planning distinctions. Product-specific names and enforcement vary, so check vendor documentation before interpreting a setting. A storage prefix can separate object names without imposing a hard capacity quota. A cap can stop one workload growing without guaranteeing that it receives capacity promptly when shared dependencies are busy.
NIST SP 800-145 describes cloud resource pooling across consumers. It does not promise that every consumer can use its theoretical peak simultaneously, nor specify an individual application's performance commitment.
Measure the work that drives demand
Purchased user licences are only a starting point. Our recommended measurements include concurrent active work, request mix, batch jobs, report complexity, data growth and the timing of integration traffic. Record response-time distributions and errors alongside resource use so that an apparently idle component does not hide a dependency bottleneck.
Look for correlated peaks. Several Australian customers may run payroll, end-of-month reporting or business-opening tasks at similar times. Customers in different time zones can still overlap through overnight imports and global integrations. Use observations from the intended workload; do not assume geographic separation creates complementary demand.
Microsoft's multitenant data guidance explicitly discusses noisy neighbours and overlapping tenant usage. It also describes tradeoffs among shared stores, sharding and separate databases. These are design options, not a benchmark for your application.
Compare the whole dependency path
For each important transaction, identify application compute, database work, storage operations, network dependencies and external services. Separate per-customer VMs can still contend on a shared database, storage service or downstream API.
When a customer needs stronger isolation, locate the constrained resource before purchasing more capacity. More web CPU will not resolve every database lock or downstream service limit. Use diagnostic evidence to choose the change, then verify the business transaction rather than declaring success from the new resource allocation alone.
Decide how the service handles excess demand: queueing, bounded rejection, controlled throttling or a separately agreed capacity increase. Explain these behaviours to customers where they affect the service contract. “Unlimited” should not hide a finite operational boundary.
An illustrative pool calculation
Suppose three synthetic workloads each reach a measured peak of 20 capacity units in a chosen test metric. The individual peak sum is 60 units. That arithmetic does not establish the shared pool size: the concurrent combined peak might be lower, or all three could coincide.
The useful next step is to measure combined demand over representative conditions, including the workload mix and timing. Add the capacity needed for the agreed failure or maintenance scenario, then verify response and error targets at that condition. These numbers are invented solely to explain the calculation; they are not a platform benchmark or sizing recommendation.
Do not mix incompatible units or assume a linear relationship between resource use and response time. Near saturation, queueing and dependency behaviour can change. Treat the candidate size as something to validate with a controlled workload, not an answer derived from averaging CPU alone.
Choose the operating model
| Requirement or observation | Design question |
|---|---|
| Independent customer maintenance | Does the deployment separate every component that must change independently? |
| Persistent contention from one workload | Can workload controls resolve it, or is a separate resource needed? |
| Highly variable demand | Can the platform scale in time, and what happens while it scales? |
| Strict customer performance requirement | What measured evidence and enforceable controls support it? |
| Many small deployments | Can provisioning, patching and monitoring be operated economically? |
Avoid a universal customer-count threshold for dedicated versus pooled hosting. Compare infrastructure costs, operating effort, support load, required headroom and the actual price model. A shared pool may reduce idle capacity while introducing engineering and monitoring costs that must also be included.
If the offer combines a protected minimum with shared burst capacity, validate both parts. State the burst conditions and excess-demand behaviour rather than marketing the burst ceiling as permanently reserved throughput.
Keep a capacity decision record
Record the workload description, observation period, known gaps, proposed allocation, limits and required service outcome. Include the result of a controlled validation, if one was actually performed, and the signals that trigger reassessment.
Revisit the decision after material application changes, new integrations or growth in data and usage. Choose a threshold with operational lead time so a capacity warning can be acted on before the customer experiences a failure.
Software vendor hosting is the relevant service area for discussing the requirements. No NetLeverage capacity, price or performance guarantee is claimed.
Sources and limits
- NIST SP 800-145, September 2011; accessed 14 November 2026.
- Microsoft: Multitenant storage and data, accessed 14 November 2026.
The terminology checklist, scenario and decision process are editorial guidance. No load test or benchmark was run. Validate the exact platform's reservation, throttling and quota semantics before relying on them.
Learning notes
A limit does not guarantee minimum performance. Combined demand and shared dependencies matter more than a simple sum of customer labels. A sizing decision needs measured workload evidence and an explicit service outcome.
This article was originally published on .