Technology Validation Assessment
An honest assessment of Apache CloudStack and the proposed open-source stack, including evidence of production viability, known limitations, risk factors, and alternative pathways.
Executive Summary: Technology Readiness
Technology Readiness Levels (TRL): TRL 9 = Proven in production at scale; TRL 7-8 = Validated in operational environment; TRL 5-6 = Technology validated but integration requires work.
Bottom Line: The core technology (Apache CloudStack) is production-proven at scale. Individual PaaS components are mature. The integration challenge—assembling these into a cohesive platform rivalling AWS—has not been done at this scale by any government. This is achievable but represents genuine technical risk requiring the 24-36 month pilot programme to validate before full commitment.
1. Apache CloudStack: Production Evidence
1.1 Global Scale Deployments
Apache CloudStack is not an experimental technology. It powers production clouds handling millions of workloads globally:
| Organisation | Scale | Use Case | Source |
|---|---|---|---|
| China Telecom* | 300+ data centres, 500M+ subscribers | Tianyi Cloud (largest cloud in China by revenue) | CloudStack.org |
| BT (British Telecom) | Enterprise cloud services | Public and private cloud offerings | CloudStack.org |
| Korea Telecom | National telco scale | Cloud infrastructure | CloudStack.org |
| Huawei | Global infrastructure | Cloud platform component | CloudStack.org |
| Apple | Internal infrastructure | Development and testing clouds | CloudStack.org |
| Yotta (India GovCloud) [MOST RELEVANT] | Multi-region hyperscale | Government of India sovereign cloud (2024) | CCC 2024 |
| EWERK (Germany) | 500+ companies | Critical infrastructure: finance, health, public sector | Case Studies |
* China Telecom Caveat: While demonstrating CloudStack's technical scalability, China Telecom operates under very different conditions: state backing, domestic regulatory requirements, and captive market. This example proves CloudStack can technically scale, but does not directly demonstrate suitability for democratic government contexts. The India GovCloud (Yotta) and EWERK (Germany) deployments are more directly comparable to the proposed Cooperative model.
1.2 Scalability Testing Results
ShapeBlue (CloudStack consultancy) has published detailed scalability testing results:
CloudStack Scalability Benchmarks (Version 4.20+)
| Production deployments | 5,000+ hosts routine |
|---|---|
| Lab testing | 25,000 hosts benchmarked (CSEUG 2025) |
| Design target | 100,000 hosts, millions of VMs |
| Database improvements | HikariCP pooling, 75% reduction in lookups via Caffeine caching |
| Concurrent operations | Background tasks parallelised for 10,000+ host environments |
Source: ShapeBlue: Scaling Apache CloudStack to 100,000 Hosts , CloudStack European User Group 2025
1.3 CloudStack vs OpenStack: Honest Comparison
OpenStack is the most commonly cited alternative. This comparison is based on independent industry assessments:
| Factor | Apache CloudStack | OpenStack | Assessment |
|---|---|---|---|
| Architecture | Integrated, all-in-one | Modular microservices (20+ components) | CloudStack simpler to deploy and maintain |
| Deployment time | Hours to days | Days to weeks | CloudStack faster |
| Operational team | Smaller team viable | Larger specialised team required | CloudStack lower ops burden |
| Flexibility | Good, but less modular | Highly flexible, swap components | OpenStack more customisable |
| Community size | Smaller but stable | Larger but fragmented | Depends on needs |
| Talent availability | Fewer specialists | More OpenStack engineers | Risk CloudStack talent scarcer |
| Stability | Fewer moving parts | More interoperability issues | CloudStack more stable |
| Hyperscale proven | China Telecom, India GovCloud | CERN, Walmart, eBay | Both proven at scale |
Sources: OpenMetal Comparison, ShapeBlue Comparison, Liquid Web Assessment
Recommendation: CloudStack is preferred for this initiative due to lower operational complexity and faster deployment. However, the Cooperative should remain technology-agnostic at the framework level—OpenStack or OpenNebula could be substituted if a jurisdiction has existing expertise.
2. Alternative Open-Source Platforms
2.1 OpenNebula and Virt8ra (EU IPCEI-CIS)
The EU has invested €1.2 billion in State Aid (plus €1.4 billion private) in the IPCEI-CIS initiative to build European-sovereign cloud infrastructure. This uses OpenNebula as the core platform:
🇪🇺 Virt8ra: Europe's First Sovereign Edge Cloud (January 2025)
| Investment | €2.6 billion (€1.2B State Aid + €1.4B private) |
|---|---|
| Initial providers | 8 organisations in 6 EU Member States |
| March 2025 expansion | 6 additional providers including OVHcloud, Scaleway, Clever Cloud |
| Core technology | OpenNebula (European-developed, EU-owned) |
| Goal | European sovereign virtualisation stack, vendor-neutral |
| EU Data Act | Designed for compliance (September 2025) |
Implication for Cooperative: The EU is already building sovereign cloud infrastructure with substantial investment. The Cooperative should coordinate with IPCEI-CIS rather than duplicate effort.
Sources: Virt8ra Launch, Virt8ra Expansion, IPCEI-CIS Reference Architecture
2.2 Comparison: CloudStack vs OpenNebula vs OpenStack
| Factor | CloudStack | OpenNebula | OpenStack |
|---|---|---|---|
| Origin | US (Cloud.com, now Apache) | EU (Spain) | US (Rackspace/NASA) |
| EU investment | Commercial users | IPCEI-CIS (€2.6B) | Various EU deployments |
| Best for | Medium-large private clouds | Edge, federated, hybrid | Large-scale, complex environments |
| VMware migration | Strong | Strong (post-Broadcom focus) | Moderate |
| Enterprise support | ShapeBlue (UK), others | OpenNebula Systems (EU) | Canonical, Red Hat, SUSE |
Recommendation: The Cooperative should be platform-flexible. CloudStack is recommended for new builds due to simplicity. OpenNebula should be considered for EU coordination due to IPCEI-CIS alignment. OpenStack may be appropriate where existing expertise exists.
3. Alternative Pathway: OCI Dedicated Region
3.1 What is OCI Dedicated Region?
Oracle Cloud Infrastructure (OCI) Dedicated Region25 is a turnkey sovereign cloud solution where Oracle deploys the full Oracle Cloud stack in a customer's own data centre:
| Feature | OCI Dedicated Region |
|---|---|
| Deployment | Full Oracle Cloud in customer data centre |
| Minimum size | 3 racks (DR25 modular architecture) |
| Data sovereignty | Data stays in customer facility, customer controls |
| Operations | Oracle manages, customer controls access |
| Certifications | FedRAMP High, UK G-Cloud, ISO 27001 |
| GPU support | NVIDIA GPUs for AI workloads |
| Global deployments | 60+ dedicated/Alloy regions live or planned |
3.2 Existing Government Deployments
| Jurisdiction | Status | Details |
|---|---|---|
| UK Government Cloud | Live | First sovereign dual-region cloud for UK government and defence |
| Australian Government | Live | Canberra region, isolated from commercial customers |
| Abu Dhabi (UAE) | Live (Dec 2024) | 13 billion AED investment, 25 government entities, 15,000 daily users |
| US Federal | Live | FedRAMP High + air-gapped regions for SECRET/TOP SECRET |
Source: Oracle UK Sovereign Cloud, Abu Dhabi Deployment
3.3 OCI Dedicated Region: Trade-offs
| Factor | Advantage | Disadvantage |
|---|---|---|
| Time to deploy | Months, not years | — |
| Technical risk | Proven platform, Oracle-managed | — |
| Vendor dependence | — | Oracle lock-in replaces hyperscaler lock-in |
| US jurisdiction | — | Oracle is a US company; CLOUD Act applies |
| Cost | Predictable, subscription-based | Likely higher than open-source long-term |
| Sovereignty | Data stays local, customer controls access | Proprietary software, not truly sovereign |
| Strategic autonomy | — | No capacity to exit without major migration |
Assessment: OCI Dedicated Region is a legitimate option for jurisdictions prioritising speed and reduced technical risk over full sovereignty. It does not eliminate US jurisdiction exposure—it merely localises operations. For governments where CLOUD Act risk is the primary concern, this is not a solution.
Possible Hybrid: OCI Dedicated Region could serve as a fallback or parallel path for specific workloads while the open-source sovereign stack matures. This would increase costs but reduce implementation risk.
4. Technology Risk Assessment
An honest assessment of what could go wrong:
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| CloudStack skills shortage | Medium | Medium | Train existing VMware/OpenStack staff; engage ShapeBlue for knowledge transfer; accept longer ramp-up |
| Integration complexity | High | Medium | Phased approach; validate each layer before adding next; accept that full AWS parity is unrealistic |
| PaaS services immature | Low-Med | Medium | Individual components are mature; integration patterns need validation via pilot |
| Open-source project abandonment | Low | Medium | CloudStack is Apache Foundation (stable governance); alternatives available for all components |
| Hardware vendor issues | Low-Med | Medium | Multi-vendor strategy; European server manufacturers (Bull/Atos, others) |
| Performance gaps vs hyperscalers | High | Low | Accept that internal clouds won't match AWS ergonomics initially; prioritise functionality over polish |
| Cost overruns | Medium | High | Fixed pilot budget (€478M); Go/No-Go gate before scaling; worst-case models already included |
| Political reversal (Munich scenario) | Medium | High | Cross-party support; international treaty binding; documented security rationale; user satisfaction focus |
4.1 What We Don't Know
Honest acknowledgment of uncertainties that the pilot programme must resolve:
- Full-stack integration at government scale: No government has built the complete proposed stack at this scale. India GovCloud uses CloudStack but details of their full stack are not published.
- Developer experience parity: AWS succeeds partly due to excellent documentation, SDKs, and developer tooling. Replicating this for an open-source stack will require significant investment beyond infrastructure.
- Managed services complexity: Offering RDS-equivalent managed databases requires substantial operational automation. Kubernetes operators help but require expertise to run reliably.
- Multi-jurisdiction coordination overhead: Coordinating development across UK, EU, Canada, and Australia adds complexity that may slow delivery.
- Vendor neutrality in practice: European server supply chains have dependencies on Asian components. True supply chain sovereignty may be unachievable.
5. Technology Acceptance Criteria
The Phase 0 Pilot Programme must demonstrate these criteria before full-scale investment:
5.1 Mandatory Technical Gates
| Gate | Acceptance Criterion | Measurement |
|---|---|---|
| GT-1: IaaS Stability | CloudStack cluster operates with ≥99.9% availability over 6 months | Prometheus monitoring, incident logs |
| GT-2: Workload Migration | Successful migration of 2-3 non-critical services per jurisdiction | Service health, user feedback |
| GT-3: Cross-border Interoperability | Demonstrated workload portability between UK and EU pilot zones | Migration test, API compatibility |
| GT-4: Security Certification | NCSC/ENISA review with no critical findings | Security assessment report |
| GT-5: Managed Services | At least 3 PaaS services (e.g., PostgreSQL, Redis, S3) operational | Service catalogue, utilisation metrics |
5.2 Decision Framework
Go/No-Go Decision at Month 30
| GO | All 5 mandatory criteria met + 7 of 10 target criteria |
| CONDITIONAL | 4 of 5 mandatory criteria met; additional 6-month remediation |
| NO-GO | Fewer than 4 mandatory criteria met; pivot to alternatives |
Exit Strategy: In the event of NO-GO, maximum stranded capital is €400M (€320M infrastructure with residual value + €80M non-recoverable). This is less than 1% of the projected 10-year costs of continued hyperscaler dependence.
Technology Validation Summary
PaaS Components: Individually mature. Integration at government scale unproven.
Recommendation: Proceed with pilot. Defined Go/No-Go gates. Accept that this is achievable but represents genuine technical risk requiring validation.
Alternative Path: OCI Dedicated Region available as fallback, trading some sovereignty for reduced risk.