The Colocation 'Private Cloud' at Northwind Accounting
Northwind Accounting is a 180-person firm with three offices and a 12 TB file share that holds client tax records. Its three physical servers are five years old and out of warranty; replacement quotes total $96,000 in capital, plus $18,000 per year in maintenance and power. Demand is sharply seasonal: during the eight-week tax season, CPU and storage throughput run at roughly four times the annual average, while for the rest of the year utilization sits near 15%. The managing partner has read that 'the cloud is just someone else's computer' and proposes colocating the existing VMware hosts in a local data center, calling the result a private cloud. The IT manager wants to move email and file sharing to SaaS but keep the tax-preparation application on infrastructure it controls, because the vendor supports only a specific OS build. The firm has 4 Mbps of symmetric internet at the main office and a 100 Mbps circuit at the data center. Budget approval requires a defensible three-year comparison.
1. Evaluate the managing partner's claim that colocating the existing VMware hosts creates a private cloud. Which essential cloud characteristics are met, which are not, and what is the practical consequence for the firm's elasticity problem?
Read the worked answer
Assess against the five essential characteristics, not against virtualization.
- On-demand self-service: provisioning still goes through a ticket to the infrastructure team, so this is not met.
- Broad network access: access exists, but the main office has only 4 Mbps symmetric; it is not adequate for a 12 TB data set or for peak-season work.
- Resource pooling: VMware clusters pool hosts, but the pool is sized to the firm rather than shared at provider scale, so pooling is only partially met.
- Rapid elasticity: fixed hosts cannot add capacity for the eight-week 4x peak; this is not met.
- Measured service: there is no metering or billing per workload or tenant, so this is not met.
Conclusion: colocation plus VMware is a virtualized private data center, not a private cloud. The practical consequence is that the firm's core problem - a 4x seasonal peak on a 15% average-utilization base - remains a capital-sizing decision: it must buy for the peak and leave capacity idle for most of the year. Calling the result a cloud does not change that economics, and it may mislead the partner into thinking elasticity has been solved when it has not.
2. Recommend a service and deployment model for the tax-preparation workload and for email/file sharing, and justify the split using the utilization and connectivity numbers.
Read the worked answer
Split by workload profile and data gravity.
Email and file sharing: SaaS. These are commodity collaboration workloads. The firm avoids Exchange and file-server patching and pays per user. The main constraint is the 12 TB of file data: 12 TB = 96 Tb = 96,000,000 Mb. At an effective 4 Mbps, that is 24,000,000 seconds, or about 278 days. Even at 100 Mbps it is about 11 days. A network-only migration is therefore not feasible inside a tax season; use a provider import/seed appliance or upgrade the circuit before cutover.
Tax-preparation application: keep it on controlled infrastructure initially, then consider IaaS/hybrid. The vendor supports only a specific OS build, and the data set is large and regulated. Viable options are a refreshed on-premises platform sized for peak, or IaaS with reserved capacity for the 15% baseline plus on-demand capacity for the eight-week peak. A dedicated host in a provider may satisfy the OS and licensing constraint.
Recommendation: SaaS for collaboration, with a seed import and circuit upgrade; IaaS/hybrid for the tax application only after connectivity and licensing are proven. Keep a small on-premises cache if the application has latency-sensitive lookups. This split addresses the seasonal peak without pretending that colocation is elastic.
3. What metric should decide whether the tax application stays on-premises or moves to IaaS, and how should reserved versus on-demand pricing change the answer?
Read the worked answer
Use a three-year, risk-adjusted total cost of ownership that separates baseline from peak capacity.
If average utilization is 15% and peak is 4x average, peak utilization is about 60% of the purchased capacity, yet the firm pays for 100% of it year-round. The decision metric is:
- On-premises: refreshed capacity sized for peak + maintenance + power + administrative labor + expected downtime cost.
- IaaS: reserved instances for the baseline + on-demand instances for the eight-week peak + circuit upgrade + migration + operations + residual downtime risk.
Reserved pricing suits the steady 15% baseline; on-demand pricing suits the eight-week burst. If the burst is only eight weeks, paying on-demand for that period is usually cheaper than buying peak capacity for 52 weeks, but only if the application can scale horizontally and the licensing permits cloud deployment. Include the circuit upgrade as a cloud-option cost; omitting it is a common business-case error that makes IaaS look artificially cheap.
If the vendor will not support the OS build in IaaS, the comparison collapses to refresh versus colocation. In that case, negotiate a managed service with explicit capacity and recovery commitments rather than claiming a private cloud. Compare three-year NPV at the firm's cost of capital, and treat the $96,000 quote as avoidable only if the existing servers are truly at end of life.