# Multi-Cloud, HCI, and Hybrid Architecture

## Overview

This document describes the multi-cloud, HCI (Hyper-Converged Infrastructure), and hybrid architecture for the DeFi Oracle Meta Mainnet (ChainID 138). The architecture enables deployment across:

- **Multiple Cloud Providers**: Azure, AWS, Google Cloud, IBM Cloud, Oracle Cloud
- **On-Premises HCI**: Azure Stack HCI, vSphere-based clusters
- **Hybrid Environments**: Combination of on-prem and cloud resources

## Architecture Principles

### 1. Environment Abstraction

All environments are defined in a single configuration file (`config/environments.yaml`). Adding or removing regions, clouds, or HCI clusters requires only configuration changes, not code modifications.

### 2. Cloud-Agnostic Design

- **Infrastructure as Code**: Terraform modules for each provider
- **Kubernetes-First**: Standardize on Kubernetes for workload orchestration
- **Abstraction Layers**: Unified interfaces for networking, identity, secrets, and observability

### 3. Admin Region Pattern

- **1 Admin Region**: Hosts CI/CD, control plane, monitoring, orchestration
- **N Workload Regions**: Deploy application workloads
- **Flexible Location**: Admin region can be on-prem, in Azure, or any cloud

## Repository Structure

```
smom-dbis-138/
├── config/
│   └── environments.yaml          # Single source of truth for all environments
├── terraform/
│   ├── multi-cloud/
│   │   ├── main.tf                # Main orchestration
│   │   ├── providers.tf          # Multi-cloud provider configuration
│   │   ├── variables.tf          # Global variables
│   │   └── modules/
│   │       ├── azure/            # Azure infrastructure module
│   │       ├── aws/              # AWS infrastructure module
│   │       ├── gcp/              # GCP infrastructure module
│   │       ├── onprem-hci/       # On-prem HCI module
│   │       ├── azure-arc/        # Azure Arc integration
│   │       ├── service-mesh/     # Service mesh deployment
│   │       ├── secrets/          # Secrets abstraction
│   │       └── observability/   # Observability abstraction
│   └── modules/                  # Existing Azure modules (reused)
├── orchestration/
│   ├── portal/                   # Web-based orchestration UI
│   └── strategies/               # Deployment strategies (blue-green, canary)
├── k8s/                          # Kubernetes manifests
├── helm/                         # Helm charts
└── .github/workflows/            # CI/CD pipelines
```

## Configuration File Format

The `config/environments.yaml` file defines all environments:

```yaml
environments:
  - name: admin-azure-westus
    role: admin
    provider: azure
    type: cloud
    region: westus
    enabled: true
    components:
      - cicd
      - monitoring
      - orchestration
    infrastructure:
      kubernetes:
        provider: aks
        version: "1.28"
        node_pools:
          system:
            count: 3
            vm_size: "Standard_D4s_v3"
  # ... more environments
```

## Deployment Flow

### 1. Define Environments

Edit `config/environments.yaml` to add/remove/modify environments.

### 2. Provision Infrastructure

```bash
cd terraform/multi-cloud
terraform init
terraform plan
terraform apply
```

### 3. Onboard to Azure Arc (Optional)

For hybrid management via Azure:

```bash
./scripts/arc-onboard-<environment>.sh
```

### 4. Deploy Platform Components

- Service mesh (Istio/Linkerd/Kuma)
- Secrets management
- Observability stack

### 5. Deploy Application Workloads

```bash
helm upgrade --install besu-network ./helm/besu-network \
  --namespace besu-network \
  --set environment=<environment-name>
```

## Deployment Strategies

### Blue-Green Deployment

Deploys new version alongside existing, then switches traffic:

```bash
./orchestration/strategies/blue-green.sh <environment> <version>
```

### Canary Deployment

Gradually rolls out new version to a subset of traffic:

```bash
./orchestration/strategies/canary.sh <environment> <version> <percentage>
```

## Web-Based Orchestration Portal

A Flask-based web UI provides:

- **Environment Discovery**: View all configured environments
- **Deployment Management**: Trigger deployments to any environment
- **Status Monitoring**: Real-time status of all environments
- **Logs and Health**: View deployment logs and cluster health

To run the portal:

```bash
cd orchestration/portal
pip install -r requirements.txt
python app.py
```

Access at: http://localhost:5000

## Azure Hybrid Stack

### Azure Arc Integration

Azure Arc enables:

- **Unified Management**: Manage Kubernetes clusters from any provider via Azure
- **Policy Enforcement**: Apply Azure Policies across all clusters
- **GitOps**: Use Azure Arc GitOps for application deployment
- **Monitoring**: Centralized monitoring via Azure Monitor

### Azure Stack HCI

For on-premises HCI:

1. Deploy Azure Stack HCI cluster on-prem
2. Install Kubernetes (AKS on HCI or kubeadm)
3. Onboard to Azure Arc
4. Manage via Azure portal/APIs

## Networking

### Cross-Cloud Connectivity

Options for connecting environments:

1. **Public Endpoints + mTLS**: Service mesh provides secure communication
2. **VPN**: Site-to-site VPN between clouds
3. **Private Links**: Azure ExpressRoute, AWS Direct Connect, GCP Interconnect
4. **Service Mesh**: Istio/Linkerd for secure service-to-service communication

### Network Abstraction

The architecture abstracts networking concepts:

- **VPC/VNet/VLAN**: Unified configuration format
- **Subnets**: Consistent naming and addressing
- **Security Groups/NSGs/Firewalls**: Provider-agnostic rules

## Identity and Access

### Federated Identity

- **Central IdP**: Azure AD, Okta, or Keycloak
- **Federation**: Connect to cloud provider IAM
- **RBAC**: Kubernetes RBAC mapped to IdP roles

### Provider-Specific

- **Azure**: Azure AD + AKS RBAC
- **AWS**: IAM + EKS IRSA (IAM Roles for Service Accounts)
- **GCP**: GCP IAM + Workload Identity

## Secrets Management

### Unified Interface

Supports multiple providers:

- **HashiCorp Vault**: Centralized secrets (recommended for multi-cloud)
- **Azure Key Vault**: Per-environment or centralized
- **AWS Secrets Manager**: Per-environment
- **GCP Secret Manager**: Per-environment

### Secret Sync

Secrets can be synced across providers using:

- Vault sync agents
- External Secrets Operator
- Custom sync scripts

## Observability

### Unified Logging

- **Loki**: Centralized log aggregation
- **Elasticsearch**: Alternative log backend
- **Cloud Logging**: Native cloud logging (CloudWatch, Azure Monitor, GCP Logging)

### Unified Metrics

- **Prometheus**: Centralized metrics collection
- **Grafana**: Visualization and dashboards
- **Cloud Metrics**: Native cloud metrics (CloudWatch, Azure Monitor, GCP Monitoring)

### Distributed Tracing

- **Jaeger**: Distributed tracing
- **Zipkin**: Alternative tracing backend
- **Tempo**: Grafana's tracing backend

## Best Practices

### 1. State Management

- Use remote Terraform state (Terraform Cloud, S3, Azure Storage)
- Separate state per environment to avoid blast radius
- Enable state locking

### 2. Cost Optimization

- Tag all resources consistently
- Use spot/preemptible instances where possible
- Enable autoscaling
- Monitor costs per environment

### 3. Security

- Zero-trust networking
- Policy-as-code (OPA, Kyverno)
- Network policies enabled
- Pod security policies
- Secrets encryption at rest and in transit

### 4. Compliance

- Data residency: Deploy data stores per region
- Audit logging: Enable audit logs for all clusters
- Compliance scanning: Regular security scans

### 5. Testing

- Start with 2-3 environments before scaling
- Use synthetic tests to verify real usability
- Test failover scenarios
- Load test cross-cloud communication

## Troubleshooting

### Common Issues

1. **Provider Authentication**: Ensure credentials are set in environment variables
2. **Network Connectivity**: Verify VPN/private links are configured
3. **Service Mesh**: Check mTLS certificates and policies
4. **Secrets**: Verify secrets are accessible from all environments

### Debugging

- Check Terraform state: `terraform state list`
- View cluster status: `kubectl get nodes -A`
- Check service mesh: `istioctl proxy-status` (if using Istio)
- View logs: Portal UI or `kubectl logs`

## Next Steps

1. **Add More Providers**: IBM Cloud, Oracle Cloud modules
2. **Enhanced Monitoring**: Custom dashboards per environment
3. **Automated Testing**: Integration tests across environments
4. **Cost Dashboards**: Real-time cost tracking
5. **Disaster Recovery**: Automated failover procedures

## References

- [Terraform Multi-Cloud Best Practices](https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html)
- [Azure Arc Documentation](https://docs.microsoft.com/azure/azure-arc/)
- [Istio Multi-Cluster](https://istio.io/latest/docs/setup/install/multicluster/)
- [Kubernetes Multi-Cloud Patterns](https://kubernetes.io/docs/concepts/cluster-administration/federation/)