Infrastructure Provisioning - seojedaperez/IgnisMap GitHub Wiki

This document details the Microsoft Azure cloud services that power the IgnisMap emergency response system, including their configuration, interconnections, and automated provisioning. 1 It covers the core infrastructure components that enable fire monitoring, AI analysis, and real-time emergency response coordination.

Service Architecture Overview

The IgnisMap system leverages eight core Azure services organized into critical and supporting tiers based on operational importance and cost impact.

Azure Services Diagram

graph TB
    subgraph "Critical Services ($115-150/month)"
        AzureMaps["emergency-app-maps<br/>Azure Maps S1"]
        CosmosDB["emergency-app-cosmos<br/>Cosmos DB"]
        Functions["emergency-app-functions<br/>Function App"]
        OpenAI["emergency-openai<br/>Cognitive Services"]
    end
    
    subgraph "Supporting Services ($50-120/month)"
        EventHub["emergency-app-events<br/>Event Hubs"]
        CogServices["emergency-app-cognitive<br/>Cognitive Services"]
        KeyVault["emergency-app-vault<br/>Key Vault"]
        AppInsights["emergency-app-insights<br/>Application Insights"]
        Storage["emergencystorage<br/>Storage Account"]
    end
    
    subgraph "External Data Sources"
        NASA["NASA FIRMS API"]
        Weather["Open-Meteo API"]
    end
    
    AzureMaps --> Functions
    CosmosDB --> Functions
    Functions --> OpenAI
    Functions --> CogServices
    EventHub --> Functions
    KeyVault --> Functions
    KeyVault --> CosmosDB
    KeyVault --> AzureMaps
    Functions --> AppInsights
    Functions --> Storage
    
    NASA --> EventHub
    Weather --> Functions
Loading

Infrastructure Provisioning

The Azure infrastructure is provisioned through automated shell scripts that create and configure all necessary resources in a single resource group. 2

Provisioning Workflow

flowchart TD
    Start["azure-setup.sh"] --> Login["az login verification"]
    Login --> ResourceGroup["Create emergency-rg<br/>Resource Group"]
    
    ResourceGroup --> Maps["Create emergency-app-maps<br/>S1 SKU"]
    Maps --> Cosmos["Create emergency-app-cosmos<br/>GlobalDocumentDB"]
    Cosmos --> Containers["Create 8 Cosmos containers<br/>Organizations, FireAlerts, etc."]
    
    Containers --> Storage["Create storage account<br/>Standard_LRS"]
    Storage --> Functions["Create emergency-app-functions<br/>Node.js 18, v4"]
    
    Functions --> Cognitive["Create emergency-app-cognitive<br/>CognitiveServices S0"]
    Cognitive --> EventHubs["Create emergency-app-events<br/>Standard SKU"]
    
    EventHubs --> KeyVault["Create emergency-app-vault<br/>Standard SKU"]
    KeyVault --> Secrets["Store connection strings<br/>and API keys"]
    
    Secrets --> Insights["Create emergency-app-insights<br/>Application Insights"]
    Insights --> Config["Configure Function App<br/>environment variables"]
    
    Config --> Output["Generate azure-config.json<br/>configuration file"]
Loading

Resource Naming Convention

All Azure resources follow the naming pattern {APP_NAME}-{SERVICE_TYPE} where APP_NAME is "emergency-app": 3

Service Type Resource Name Purpose
Maps emergency-app-maps Geospatial mapping services
Cosmos DB emergency-app-cosmos Global document database
Functions emergency-app-functions Serverless compute platform
Cognitive Services emergency-app-cognitive AI and ML services
Event Hubs emergency-app-events Real-time data streaming
Key Vault emergency-app-vault-{timestamp} Secrets management
App Insights emergency-app-insights Application monitoring
Storage emergencystorage{timestamp} File and blob storage

Automated Setup Script

The provisioning process is automated through the setup-azure-emergency.sh script: 4

sequenceDiagram
    participant User as "Administrator"
    participant Script as "setup-azure-emergency.sh"
    participant Azure as "Azure CLI"
    participant Portal as "Azure Portal"
    
    User->>Script: Execute setup script
    Script->>Azure: Verify login status
    Azure-->>Script: Authentication confirmed
    
    Script->>Azure: Create resource group
    Script->>Azure: Create Azure Maps (S1)
    Script->>Azure: Create Cosmos DB
    Script->>Azure: Create 8 containers
    Script->>Azure: Create Storage Account
    Script->>Azure: Create Function App
    Script->>Azure: Create Cognitive Services
    Script->>Azure: Create Event Hubs
    Script->>Azure: Create Key Vault
    Script->>Azure: Store secrets in vault
    Script->>Azure: Create Application Insights
    Script->>Azure: Configure environment variables
    
    Script-->>User: Display configuration summary
    Script-->>User: Output azure-config.json
Loading

Data Storage Architecture

Cosmos DB serves as the primary data store with eight specialized containers optimized for different data types and access patterns.

Cosmos DB Container Structure

graph TB
    subgraph "EmergencyDB Database"
        Orgs["Organizations<br/>Partition: /organizationType<br/>400 RU/s"]
        Zones["MonitoringZones<br/>Partition: /organizationId<br/>400 RU/s"]
        Alerts["FireAlerts<br/>Partition: /organizationId<br/>1000 RU/s"]
        Plans["TacticalPlans<br/>Partition: /organizationType<br/>400 RU/s"]
        Satellite["SatelliteData<br/>Partition: /satellite<br/>2000 RU/s<br/>TTL: 30 days"]
        Weather["WeatherData<br/>Partition: /location<br/>800 RU/s<br/>TTL: 7 days"]
        Resources["ResourceAllocation<br/>Partition: /organizationId<br/>400 RU/s"]
        Audit["AuditLog<br/>Partition: /organizationId<br/>400 RU/s"]
    end
    
    subgraph "Access Patterns"
        Orgs --> "Query by organization type"
        Zones --> "Query by organization ID"
        Alerts --> "Query by organization ID"
        Plans --> "Query by organization type"
        Satellite --> "Query by satellite source"
        Weather --> "Query by geographic region"
        Resources --> "Query by organization ID"
        Audit --> "Query by organization ID"
    end
Loading

Container Configuration

Each Cosmos DB container is configured with specific throughput allocation and partitioning strategy:

  • High-throughput containers: SatelliteData (2000 RU/s), FireAlerts (1000 RU/s), WeatherData (800 RU/s)
  • Standard-throughput containers: All others (400 RU/s)
  • TTL-enabled containers: SatelliteData (30 days), WeatherData (7 days)

Service Integration Configuration

Function App Environment Variables

The Function App receives configuration through environment variables managed by the provisioning script: 5

Variable Source Purpose
COSMOS_CONNECTION_STRING Cosmos DB primary connection string Database access
AZURE_MAPS_KEY Azure Maps primary key Geospatial services
COGNITIVE_SERVICES_ENDPOINT Cognitive Services endpoint URL AI service access
COGNITIVE_SERVICES_KEY Cognitive Services primary key AI service authentication
APPINSIGHTS_INSTRUMENTATIONKEY Application Insights key Telemetry collection

Key Vault Secret Management

Three critical secrets are stored in Key Vault for secure access: 6

graph LR
    KeyVault["emergency-app-vault"] --> CosmosSecret["CosmosConnectionString"]
    KeyVault --> MapsSecret["AzureMapsKey"]
    KeyVault --> CognitiveSecret["CognitiveServicesKey"]
    
    CosmosSecret --> CosmosDB["emergency-app-cosmos"]
    MapsSecret --> AzureMaps["emergency-app-maps"]
    CognitiveSecret --> CogServices["emergency-app-cognitive"]
Loading

Event Processing Architecture

Event Hubs Configuration

The Event Hubs namespace emergency-app-events contains the satellite-data event hub configured for high-throughput satellite data ingestion: 7

  • Partition count: 4 partitions for parallel processing
  • Message retention: 7 days
  • SKU: Standard tier for production workloads

Data Flow Pattern

sequenceDiagram
    participant NASA as "NASA FIRMS API"
    participant EventHub as "satellite-data Event Hub"
    participant Functions as "Azure Functions"
    participant Cosmos as "Cosmos DB"
    participant AI as "Cognitive Services"
    
    NASA->>EventHub: Satellite fire data
    EventHub->>Functions: ProcessSatelliteData trigger
    Functions->>AI: Analyze fire imagery
    Functions->>Cosmos: Store processed data
    Functions->>Functions: GenerateTacticalPlan
    Functions->>Cosmos: Store tactical plans
Loading

Monitoring and Observability

Application Insights Integration

Application Insights (emergency-app-insights) provides comprehensive monitoring through: 8

  • Performance monitoring: Function execution times and resource utilization
  • Error tracking: Exception logging and failure analysis
  • Custom telemetry: Fire detection accuracy and response time metrics
  • Dependency tracking: External API call monitoring

Monitoring Architecture

graph TB
    subgraph "Application Layer"
        App["IgnisMap Application"]
        Functions["Azure Functions"]
    end
    
    subgraph "Monitoring Services"
        Insights["Application Insights"]
        Monitor["Azure Monitor"]
        Alerts["Alert Rules"]
    end
    
    subgraph "Data Sources"
        Logs["Application Logs"]
        Metrics["Performance Metrics"]
        Traces["Distributed Traces"]
    end
    
    App --> Insights
    Functions --> Insights
    Insights --> Logs
    Insights --> Metrics
    Insights --> Traces
    Monitor --> Alerts
    Insights --> Monitor
Loading

Key Performance Indicators

The system monitors these critical metrics:

Metric Target Purpose
Alert response time < 30 seconds Emergency response effectiveness
Fire detection accuracy > 95% Prediction system reliability
System availability 99.9% Service continuity
Tactical plan generation < 2 minutes Operational readiness
Satellite data latency < 5 minutes Real-time monitoring capability

Cost Structure and Optimization

Monthly Cost Breakdown

The Azure infrastructure operates with an estimated monthly cost of $165-270 USD: 9

pie title "Monthly Cost Distribution ($165-270 USD)"
    "Azure Maps" : 50
    "Cosmos DB" : 32
    "Cognitive Services" : 40
    "Event Hubs" : 40
    "Function App" : 15
    "Other Services" : 25
Loading
Service Category Cost Range Services Included
Critical Tier $115-150/month Azure Maps ($50-80), Cosmos DB ($25-40), Functions ($10-20), OpenAI ($30-50)
Supporting Tier $50-120/month Cognitive Services ($30-50), Event Hubs ($30-50), Storage/Vault/Insights ($20-30)

Cost Optimization Strategies

The provisioning scripts implement several cost optimization measures:

  • Cosmos DB: Session consistency level and optimized RU/s allocation per container
  • Storage: Standard_LRS redundancy for cost-effective local storage
  • Functions: Consumption plan for serverless cost scaling
  • TTL policies: Automatic data expiration for satellite and weather data

Deployment Process

Prerequisites

flowchart LR
    Start["Start Deployment"] --> Check1["Azure Account<br/>with $1,000 credits"]
    Check1 --> Check2["Azure CLI<br/>installed"]
    Check2 --> Check3["Contributor permissions<br/>on subscription"]
    Check3 --> Ready["Ready for<br/>deployment"]
Loading

Execution Steps

The deployment follows this automated sequence: 10

  1. Execute setup script: chmod +x scripts/setup-azure-emergency.sh && ./scripts/setup-azure-emergency.sh
  2. Resource creation: Automated provisioning of all Azure services
  3. Configuration: Environment variables and secrets setup
  4. Verification: Service connectivity testing
  5. Documentation: Generation of azure-config.json configuration file

Notes

The infrastructure provisioning system is designed for the IgnisMap emergency response platform, replacing the original "FlameForecast" branding throughout the codebase. The system uses Azure's enterprise-grade services to provide real-time fire monitoring, AI-powered analysis, and emergency response coordination capabilities. All provisioning is automated through shell scripts that handle the complete setup process, from resource creation to configuration management.

Wiki pages you might want to explore:

⚠️ **GitHub.com Fallback** ⚠️