Sankofa/docs/phoenix/CLOUD_PROVIDER_MAPPING.md

# Phoenix Cloud Provider Mapping & Competitive Analysis

**Mapping Phoenix Operating Model to Azure, AWS, and Competitive Positioning**

This document maps the Phoenix operating model to Azure and AWS equivalents, provides competitive analysis, feature comparison, and migration considerations for sovereign governments.

---

## Executive Summary

Phoenix is purpose-built for **international and multi-national sovereign governments** and competes directly with Azure, AWS, and other cloud providers. This document shows how Phoenix's operating model maps to Azure/AWS concepts while highlighting competitive advantages, especially for sovereign deployments.

**Key Competitive Advantages:**
- **Superior Multi-Tenancy**: Finer-grained control than Azure
- **Superior Billing**: Per-second granularity vs Azure's hourly
- **Sovereign Identity**: Keycloak-based, no Azure dependencies
- **Multi-Region Native**: Built for international/multi-national deployments
- **Decentralized Architecture**: Supports distributed sovereignty
- **Landing Zone Patterns**: Sovereign cloud deployments per region

---

## I. Mapping to Azure

### Entity Mapping

| Phoenix Entity | Azure Equivalent | Key Differences |
|----------------|------------------|-----------------|
| **Client (Billing Profile)** | Azure Billing Account / Customer | Phoenix separates billing from identity |
| **Tenant** | Azure AD Tenant | Phoenix Tenant = identity + domain + security boundary |
| **Subscription** | Azure Subscription | Phoenix Subscription = service bundle + quotas + policies |
| **Environment** | Azure Resource Group | Phoenix Environment = lifecycle stage + isolation |
| **Landing Zone** | Azure Landing Zone | Phoenix Landing Zone = sovereign cloud per region |

### Detailed Mapping

#### Client (Billing Profile) → Azure Billing Account

**Azure Model:**
- Billing Account contains billing profiles
- Billing profiles contain subscriptions
- Direct billing-to-subscription relationship

**Phoenix Model:**
- Client (Billing Profile) owns multiple Tenants
- Tenants contain Subscriptions
- Billing aggregates at Client level, not directly tied to Subscriptions

**Advantage**: Phoenix separates commercial governance from technical tenancy, enabling more flexible billing structures for multi-national governments.

#### Tenant → Azure AD Tenant

**Azure Model:**
- Azure AD Tenant = identity boundary
- One tenant can have multiple subscriptions
- Tenant is primarily for identity/access management

**Phoenix Model:**
- Tenant = identity + domain + security boundary
- Tenant is the security blast-radius
- One tenant can have multiple subscriptions
- Tenant includes data residency and compliance profiles

**Advantages:**
- Phoenix Tenant includes domain ownership and sovereignty flags
- Phoenix Tenant is explicitly the security boundary
- Phoenix supports multi-region tenants with regional data residency

#### Subscription → Azure Subscription

**Azure Model:**
- Azure Subscription = billing + resource container
- Subscriptions belong to Azure AD Tenant
- Resource Groups organize resources within subscriptions

**Phoenix Model:**
- Subscription = service bundle + quotas + policies
- Subscriptions belong to Tenant
- Environments organize resources within subscriptions
- Subscriptions are mapped to Client for billing

**Advantages:**
- Phoenix separates billing (Client) from resource provisioning (Subscription)
- Phoenix Subscriptions include policy packs (security, networking, data access)
- Phoenix supports subscription types (Shared Platform, Product, Sandbox)

#### Environment → Azure Resource Group

**Azure Model:**
- Resource Group = logical container for resources
- Resources can be moved between resource groups
- Resource groups don't enforce lifecycle stages

**Phoenix Model:**
- Environment = lifecycle stage (DEV, INT, UAT, STAGING, PROD, etc.)
- Environments enforce deployment policies
- Environments have network and data isolation
- Promotion flows are policy-driven between environments

**Advantages:**
- Phoenix Environments explicitly represent lifecycle stages
- Phoenix Environments enforce promotion policies
- Phoenix supports specialized environments (REGULATED, SOVEREIGN, AIR-GAPPED)

#### Landing Zone → Azure Landing Zone

**Azure Model:**
- Azure Landing Zone = reference architecture
- Typically single-region or multi-region within same cloud
- Centralized governance

**Phoenix Model:**
- Landing Zone = sovereign cloud deployment per region/nation
- Decentralized governance with coordination
- Regional autonomy with cross-region coordination

**Advantages:**
- Phoenix Landing Zones support complete regional sovereignty
- Phoenix supports air-gapped landing zones
- Phoenix Landing Zones enable decentralized governance

### Architecture Comparison

**Azure Architecture:**
```
Azure AD Tenant
  └── Azure Subscription (billing + resources)
      └── Resource Group (logical container)
          └── Resources (VMs, storage, etc.)
```

**Phoenix Architecture:**
```
Client (Billing Profile)
  └── Tenant (identity + domain + security)
      └── Subscription (service bundle + quotas)
          └── Environment (lifecycle stage + isolation)
              └── Resources (VMs, storage, etc.)
```

**Key Difference**: Phoenix separates commercial (Client), identity (Tenant), provisioning (Subscription), and lifecycle (Environment) into distinct planes.

---

## II. Mapping to AWS

### Entity Mapping

| Phoenix Entity | AWS Equivalent | Key Differences |
|----------------|----------------|-----------------|
| **Client (Billing Profile)** | AWS Customer / Billing Account | Phoenix separates billing from organization |
| **Tenant** | AWS Organization (partial) | Phoenix Tenant = identity + domain + security |
| **Subscription** | AWS Account | Phoenix Subscription = service bundle + quotas |
| **Environment** | AWS Resource Group / Tag | Phoenix Environment = lifecycle stage + isolation |
| **Landing Zone** | AWS Landing Zone | Phoenix Landing Zone = sovereign cloud per region |

### Detailed Mapping

#### Client (Billing Profile) → AWS Customer / Billing Account

**AWS Model:**
- AWS Customer = billing entity
- Billing Account contains AWS Accounts
- Direct billing-to-account relationship

**Phoenix Model:**
- Client (Billing Profile) owns multiple Tenants
- Tenants contain Subscriptions
- Billing aggregates at Client level

**Advantage**: Phoenix separates commercial governance from technical tenancy.

#### Tenant → AWS Organization

**AWS Model:**
- AWS Organization = account management + billing
- Organizations contain AWS Accounts
- Organizations can have multiple accounts

**Phoenix Model:**
- Tenant = identity + domain + security boundary
- Tenants contain Subscriptions
- Tenant is the security blast-radius

**Advantages:**
- Phoenix Tenant includes identity provider and domain ownership
- Phoenix Tenant explicitly defines security boundaries
- Phoenix supports multi-region tenants with regional data residency

#### Subscription → AWS Account

**AWS Model:**
- AWS Account = billing + resource container
- Accounts belong to AWS Organization
- Resources are organized within accounts

**Phoenix Model:**
- Subscription = service bundle + quotas + policies
- Subscriptions belong to Tenant
- Environments organize resources within subscriptions

**Advantages:**
- Phoenix separates billing (Client) from resource provisioning (Subscription)
- Phoenix Subscriptions include policy packs
- Phoenix supports subscription types

#### Environment → AWS Resource Group / Tag

**AWS Model:**
- Resource Groups = logical grouping of resources
- Tags = metadata for organization
- No explicit lifecycle stage enforcement

**Phoenix Model:**
- Environment = lifecycle stage with enforcement
- Environments enforce deployment policies
- Promotion flows are policy-driven

**Advantages:**
- Phoenix Environments explicitly represent lifecycle stages
- Phoenix Environments enforce promotion policies
- Phoenix supports specialized environments

#### Landing Zone → AWS Landing Zone

**AWS Model:**
- AWS Landing Zone = reference architecture
- Typically multi-account within same organization
- Centralized governance

**Phoenix Model:**
- Landing Zone = sovereign cloud deployment per region/nation
- Decentralized governance with coordination
- Regional autonomy

**Advantages:**
- Phoenix Landing Zones support complete regional sovereignty
- Phoenix supports air-gapped landing zones
- Phoenix Landing Zones enable decentralized governance

### Architecture Comparison

**AWS Architecture:**
```
AWS Organization
  └── AWS Account (billing + resources)
      └── Resource Group / Tag (logical grouping)
          └── Resources (EC2, S3, etc.)
```

**Phoenix Architecture:**
```
Client (Billing Profile)
  └── Tenant (identity + domain + security)
      └── Subscription (service bundle + quotas)
          └── Environment (lifecycle stage + isolation)
              └── Resources (VMs, storage, etc.)
```

**Key Difference**: Phoenix separates commercial (Client), identity (Tenant), provisioning (Subscription), and lifecycle (Environment) into distinct planes.

---

## III. Hybrid Deployments

### Sovereign + Public Cloud Patterns

Phoenix supports hybrid deployments combining sovereign Phoenix clouds with public cloud providers.

#### Pattern 1: Sovereign Primary, Public Cloud Secondary

**Use Case**: Sovereign government with primary workloads in Phoenix, using public cloud for non-sensitive workloads.

**Architecture:**
- Primary: Phoenix sovereign cloud (data residency, compliance)
- Secondary: Azure/AWS for public-facing, non-sensitive workloads
- Integration: Federated identity, coordinated governance

#### Pattern 2: Multi-Cloud with Phoenix Coordination

**Use Case**: Multi-national government using multiple clouds with Phoenix as coordination layer.

**Architecture:**
- Phoenix: Control plane and coordination
- Azure/AWS: Regional deployments
- Integration: Phoenix manages identity, billing, and governance across clouds

#### Pattern 3: Phoenix Landing Zones with Public Cloud Services

**Use Case**: Sovereign landing zones using public cloud services where appropriate.

**Architecture:**
- Phoenix Landing Zones: Core infrastructure and data
- Public Cloud Services: Specific services (AI, analytics) where data residency allows
- Integration: Policy-driven service selection based on data residency

### Integration Strategies

1. **Federated Identity**: Phoenix Keycloak federates with Azure AD / AWS IAM
2. **Coordinated Billing**: Phoenix aggregates costs across clouds
3. **Unified Governance**: Phoenix policies apply across hybrid deployments
4. **Data Residency Enforcement**: Phoenix ensures data stays in appropriate clouds

---

## IV. Multi-Region Landing Zones

### Comparison: Azure vs AWS vs Phoenix

| Feature | Azure | AWS | Phoenix |
|---------|-------|-----|---------|
| **Landing Zone Model** | Reference architecture | Reference architecture | Sovereign cloud per region |
| **Regional Autonomy** | Limited | Limited | Complete |
| **Data Residency** | Regional options | Regional options | Hard enforcement per region |
| **Air-Gapped Support** | Limited | Limited | Native support |
| **Decentralized Governance** | No | No | Yes |
| **Cross-Region Coordination** | Centralized | Centralized | Federated |
| **Sovereign Cloud** | Azure Government | AWS GovCloud | Native sovereign clouds |

### Phoenix Advantages

1. **Sovereign Cloud Per Region**: Each region/nation can have complete sovereign cloud
2. **Air-Gapped Support**: Native support for air-gapped deployments
3. **Decentralized Governance**: Regional autonomy with coordination
4. **Hard Data Residency**: Enforced data residency per region
5. **Multi-National Support**: Built for international/multi-national governments

---

## V. Decentralized Architecture

### How Phoenix Differs from Centralized Azure/AWS

**Azure/AWS Model:**
- Centralized control plane
- Single point of governance
- Regional deployments but centralized management

**Phoenix Model:**
- Distributed control planes per region
- Federated governance
- Regional autonomy with coordination
- No single point of control

### Advantages for Sovereign Governments

1. **Sovereignty**: Complete regional control
2. **Resilience**: No single point of failure
3. **Compliance**: Regional compliance per region
4. **Data Residency**: Hard enforcement per region
5. **Governance**: Regional autonomy with coordination

---

## VI. Feature Comparison Matrix

### Multi-Tenancy Capabilities

| Feature | Azure | AWS | Phoenix |
|---------|-------|-----|---------|
| **Custom Domains per Tenant** | Limited | Limited | Full support |
| **Cross-Tenant Resource Sharing** | Limited | Limited | Full support |
| **Tenant Isolation** | Logical | Logical | Logical + optional physical |
| **RBAC Granularity** | RBAC only | IAM policies | RBAC + JSON permissions |
| **Tenant Tiers** | Limited | Limited | FREE, STANDARD, ENTERPRISE, SOVEREIGN |

**Phoenix Advantage**: Superior multi-tenancy with finer-grained control and flexibility.

### Billing Granularity

| Feature | Azure | AWS | Phoenix |
|---------|-------|-----|---------|
| **Billing Granularity** | Hourly | Per-second (some services) | Per-second (all services) |
| **Real-Time Tracking** | Limited | Limited | Full real-time |
| **Cost Forecasting** | Basic | Basic | ML-based |
| **Optimization Recommendations** | Manual | Manual | Automated |
| **Blockchain Billing** | No | No | Yes (optional) |
| **Multi-Currency** | Limited | Limited | Full support |
| **Custom Pricing Models** | Limited | Limited | Per-tenant models |

**Phoenix Advantage**: Superior billing with per-second granularity, ML-based forecasting, and blockchain support.

### Identity Management

| Feature | Azure | AWS | Phoenix |
|---------|-------|-----|---------|
| **Identity Provider** | Azure AD only | AWS IAM | Keycloak (sovereign) |
| **Self-Hosted** | No | No | Yes |
| **Multi-Realm Support** | Limited | Limited | Full support (one per tenant) |
| **Custom Authentication Flows** | Limited | Limited | Full support |
| **Federated Identity** | Yes | Yes | Yes (Keycloak-based) |
| **Blockchain Identity** | No | No | Yes (optional) |
| **Sovereign Identity** | No | No | Yes (no Azure dependencies) |

**Phoenix Advantage**: Sovereign identity management with Keycloak, no Azure dependencies, full self-hosting.

### Multi-Region Support

| Feature | Azure | AWS | Phoenix |
|---------|-------|-----|---------|
| **Regional Autonomy** | Limited | Limited | Complete |
| **Sovereign Cloud Per Region** | Azure Government | AWS GovCloud | Native sovereign clouds |
| **Air-Gapped Support** | Limited | Limited | Native support |
| **Decentralized Governance** | No | No | Yes |
| **Cross-Region Coordination** | Centralized | Centralized | Federated |
| **Data Residency Enforcement** | Soft | Soft | Hard (per region) |
| **Multi-National Support** | Limited | Limited | Built-in |

**Phoenix Advantage**: Native multi-region support with sovereign clouds, air-gapped deployments, and decentralized governance.

### Compliance and Security

| Feature | Azure | AWS | Phoenix |
|---------|-------|-----|---------|
| **Compliance Standards** | ISO, SOC, HIPAA, FedRAMP | ISO, SOC, HIPAA, FedRAMP | ISO, SOC, HIPAA, FedRAMP, Custom |
| **Audit Trails** | Yes | Yes | Yes (blockchain-optional) |
| **Data Residency** | Regional options | Regional options | Hard enforcement per region |
| **Sovereign Cloud** | Azure Government | AWS GovCloud | Native sovereign clouds |
| **Air-Gapped** | Limited | Limited | Native support |
| **Regulated Environments** | Limited | Limited | REGULATED, SOVEREIGN, AIR-GAPPED types |

**Phoenix Advantage**: Native support for sovereign, regulated, and air-gapped environments with hard data residency enforcement.

### DevOps and Content Management

| Feature | Azure | AWS | Phoenix |
|---------|-------|-----|---------|
| **Enterprise Content Hierarchy** | No | No | Yes (Enterprise → Portfolio → Product → Application → Component) |
| **Git Integration** | Yes | Yes | Yes (with governance) |
| **CI/CD Integration** | Yes | Yes | Yes (with policy gates) |
| **Promotion Flows** | Manual/scripted | Manual/scripted | Policy-driven |
| **Content Governance** | Limited | Limited | Full (approval workflows, compliance tagging) |
| **GitOps** | Yes | Yes | Yes (ArgoCD integration) |

**Phoenix Advantage**: Enterprise content hierarchy with full governance, policy-driven promotion flows.

---

## VII. Migration Considerations

### Migration Complexity Assessment

#### From Azure to Phoenix

**Low Complexity:**
- Identity migration (Keycloak can import from Azure AD)
- Resource migration (standard VM/storage migration)
- Application migration (standard application deployment)

**Medium Complexity:**
- Billing model migration (Client/Tenant/Subscription structure)
- Governance migration (policy packs, approval workflows)
- Multi-region migration (landing zone setup)

**High Complexity:**
- Air-gapped migration (complete isolation setup)
- Sovereign cloud migration (regional sovereignty setup)
- Decentralized governance migration (federated governance setup)

#### From AWS to Phoenix

**Low Complexity:**
- Identity migration (Keycloak can import from AWS IAM)
- Resource migration (standard VM/storage migration)
- Application migration (standard application deployment)

**Medium Complexity:**
- Organization structure migration (Client/Tenant/Subscription)
- Governance migration (policy packs, approval workflows)
- Multi-region migration (landing zone setup)

**High Complexity:**
- Air-gapped migration (complete isolation setup)
- Sovereign cloud migration (regional sovereignty setup)
- Decentralized governance migration (federated governance setup)

### Data Migration Strategies

#### Strategy 1: Lift and Shift

**Approach**: Migrate resources as-is to Phoenix.

**Use Cases:**
- Non-sensitive workloads
- Standard applications
- Quick migration requirements

**Process:**
1. Export resources from Azure/AWS
2. Import to Phoenix
3. Update networking and identity
4. Validate and cutover

#### Strategy 2: Refactor for Phoenix

**Approach**: Refactor applications to leverage Phoenix capabilities.

**Use Cases:**
- Applications requiring sovereign capabilities
- Multi-region deployments
- Air-gapped requirements

**Process:**
1. Analyze application architecture
2. Refactor for Phoenix operating model
3. Implement Phoenix-specific features (sovereign identity, landing zones)
4. Migrate and validate

#### Strategy 3: Hybrid Migration

**Approach**: Gradual migration with hybrid operations.

**Use Cases:**
- Large-scale migrations
- Mission-critical applications
- Phased migration requirements

**Process:**
1. Set up Phoenix alongside Azure/AWS
2. Migrate non-critical workloads first
3. Gradually migrate critical workloads
4. Complete migration and decommission Azure/AWS

### Identity Migration Strategies

#### From Azure AD to Keycloak

**Process:**
1. Export users and groups from Azure AD
2. Import to Keycloak realm
3. Configure identity provider federation (if needed)
4. Update applications to use Keycloak
5. Migrate authentication flows

**Tools:**
- Keycloak user import
- Azure AD Graph API export
- Custom migration scripts

#### From AWS IAM to Keycloak

**Process:**
1. Export users and roles from AWS IAM
2. Import to Keycloak realm
3. Configure identity provider federation (if needed)
4. Update applications to use Keycloak
5. Migrate authentication flows

**Tools:**
- Keycloak user import
- AWS IAM API export
- Custom migration scripts

### Application Migration Strategies

#### Containerized Applications

**Process:**
1. Export container images
2. Import to Phoenix container registry
3. Update deployment configurations
4. Deploy to Phoenix Kubernetes/container platform
5. Update networking and identity

#### Virtual Machine Applications

**Process:**
1. Export VM images
2. Convert to Phoenix VM format
3. Import to Phoenix
4. Update networking and identity
5. Deploy and validate

#### Serverless Applications

**Process:**
1. Analyze serverless functions
2. Port to Phoenix serverless platform (if available)
3. Update event sources and triggers
4. Deploy and validate

### Cost Migration Analysis

#### Cost Comparison Framework

**Factors to Consider:**
- Compute costs (VM, container, serverless)
- Storage costs (object, block, archive)
- Network costs (egress, cross-region)
- Identity costs (Azure AD vs Keycloak)
- Compliance costs (sovereign vs public cloud)

#### Phoenix Cost Advantages

1. **Per-Second Billing**: More accurate than hourly
2. **No Vendor Lock-In**: Avoid Azure/AWS lock-in costs
3. **Sovereign Cloud**: Potentially lower costs for sovereign deployments
4. **Custom Pricing**: Per-tenant pricing models

#### Migration Cost Considerations

- **Migration Tools**: Cost of migration tools and services
- **Downtime**: Cost of downtime during migration
- **Training**: Cost of training teams on Phoenix
- **Integration**: Cost of integrating with existing systems

### Timeline Estimates

#### Small-Scale Migration (< 100 resources)

**Timeline**: 1-3 months
- Planning: 2 weeks
- Migration: 4-8 weeks
- Validation: 2-4 weeks

#### Medium-Scale Migration (100-1000 resources)

**Timeline**: 3-6 months
- Planning: 1 month
- Migration: 2-4 months
- Validation: 1 month

#### Large-Scale Migration (> 1000 resources)

**Timeline**: 6-12 months
- Planning: 2 months
- Migration: 4-8 months
- Validation: 2 months

#### Sovereign/Air-Gapped Migration

**Timeline**: 6-18 months (additional complexity)
- Planning: 3 months
- Migration: 6-12 months
- Validation: 3 months

### Step-by-Step Migration Guides

#### Migration from Azure

**Phase 1: Planning**
1. Assess current Azure deployment
2. Map Azure entities to Phoenix entities
3. Plan Client/Tenant/Subscription structure
4. Plan identity migration
5. Plan resource migration

**Phase 2: Setup**
1. Create Phoenix Client
2. Create Phoenix Tenants
3. Create Phoenix Subscriptions
4. Set up Keycloak realms
5. Configure landing zones

**Phase 3: Migration**
1. Migrate identity (Azure AD → Keycloak)
2. Migrate resources (Azure → Phoenix)
3. Update applications
4. Update networking
5. Validate functionality

**Phase 4: Cutover**
1. Final validation
2. Cutover plan
3. Execute cutover
4. Monitor and support
5. Decommission Azure resources

#### Migration from AWS

**Phase 1: Planning**
1. Assess current AWS deployment
2. Map AWS entities to Phoenix entities
3. Plan Client/Tenant/Subscription structure
4. Plan identity migration
5. Plan resource migration

**Phase 2: Setup**
1. Create Phoenix Client
2. Create Phoenix Tenants
3. Create Phoenix Subscriptions
4. Set up Keycloak realms
5. Configure landing zones

**Phase 3: Migration**
1. Migrate identity (AWS IAM → Keycloak)
2. Migrate resources (AWS → Phoenix)
3. Update applications
4. Update networking
5. Validate functionality

**Phase 4: Cutover**
1. Final validation
2. Cutover plan
3. Execute cutover
4. Monitor and support
5. Decommission AWS resources

---

## VIII. Competitive Advantages Summary

### For Sovereign Governments

1. **Sovereign Identity**: Keycloak-based, no Azure/AWS dependencies
2. **Multi-Region Native**: Built for international/multi-national deployments
3. **Decentralized Architecture**: Supports distributed sovereignty
4. **Landing Zone Patterns**: Sovereign cloud deployments per region
5. **Air-Gapped Support**: Native support for classified workloads
6. **Hard Data Residency**: Enforced data residency per region
7. **Superior Multi-Tenancy**: Finer-grained control than Azure/AWS
8. **Superior Billing**: Per-second granularity vs hourly

### For Enterprise Deployments

1. **Enterprise Content Hierarchy**: Full governance from Enterprise to Component
2. **Policy-Driven Promotion**: Automated, auditable promotion flows
3. **Superior RBAC**: RBAC + JSON permissions
4. **Custom Pricing**: Per-tenant pricing models
5. **Blockchain Integration**: Optional blockchain for billing and identity

---

## IX. Conclusion

Phoenix provides a superior operating model for sovereign governments compared to Azure and AWS, with:

- **Separation of Concerns**: Five orthogonal control planes
- **Sovereign Capabilities**: Native support for sovereign, regulated, and air-gapped deployments
- **Multi-Region Native**: Built for international/multi-national governments
- **Decentralized Architecture**: Supports distributed sovereignty
- **Superior Features**: Better multi-tenancy, billing, and identity management

Migration from Azure/AWS to Phoenix is feasible with proper planning and execution, and provides significant advantages for sovereign government deployments.

---

## References

### Phoenix Operating Model Documentation

- **[Operating Model](./OPERATING_MODEL.md)** - Core operating model documentation
- **[Architecture Diagrams](./OPERATING_MODEL_DIAGRAMS.md)** - Visual diagrams of the operating model
- **[MVP Control Plane](./MVP_CONTROL_PLANE.md)** - Minimum viable product specification
- **[Multi-Region Landing Zones](./MULTI_REGION_LANDING_ZONES.md)** - Landing zone patterns and deployment
- **[Migration Guide](./MIGRATION_GUIDE.md)** - Migration from existing systems and cloud providers
- **[Product Specification](./PRODUCT_SPEC.md)** - Client-facing product specification

---

**Last Updated**: 2025-01-09  
**Version**: 1.0  
**Status**: Complete Cloud Provider Mapping & Competitive Analysis