3.6: Environments

This section outlines the environment isolation strategy for the new eMap platform. A clear and robust isolation strategy is crucial for safeguarding production stability, enabling high-fidelity testing in non-production environments, providing effective training environments, facilitating accurate load testing and managing costs effectively.

The new eMap platform will consist of five distinct environments:

• Development (DEV)
• User Acceptance Testing (UAT)
• Production (PROD)
• Training (TRN)
• Staging (STG)

The main principle of this strategy is the provision of dedicated Azure PaaS resources and compute instances for each environment, ensuring complete separation. This is complemented by structural parity across environments where DEV, UAT and TRN environments mirror the multi-component architecture of PROD (e.g., separate VMs for Portal for ArcGIS, ArcGIS Server and ArcGIS Data Store; ArcGIS Web Adaptors hosted on Azure App Service). The STG environment will be a direct replica of PROD in both architecture and SKU selection. Cost-effectiveness for persistent non-production environments (DEV, UAT, TRN) is achieved through careful selection of resource SKUs, instance counts and the presence or absence of High Availability (HA) and Disaster Recovery (DR) features. The STG environment's cost-effectiveness stems from its ephemeral nature.

The following diagram illustrates the strategy of dedicated PaaS and Compute resources for each environment, highlighting the differentiation in tiers, redundancy, scale and purpose.

%%{init: {"flowchart": {"defaultRenderer": "elk"}}}%%
graph TB
    classDef envBox fill:#fff,stroke:#333,stroke-width:2px;
    classDef prod fill:#e8f5e9,stroke:#38761d;
    classDef stg fill:#e8f5e9,stroke:#38761d,stroke-dasharray:5 5;
    classDef uat fill:#fff9c4,stroke:#f57f17;
    classDef dev fill:#e3f2fd,stroke:#0d47a1;
    classDef trn fill:#fff0f5,stroke:#c51162;

    subgraph DEV["💻 DEV"]
        direction TB
        style DEV fill:#e3f2fd,stroke:#0d47a1
        D_VMs["🖥️ Single VMs<br>(Minimal SKUs)"] --> D_PG["📦 Burstable PG<br>(LRS)"]
        D_AS["🌐 Basic App Services"] --> D_SA["🗄️ LRS Storage"]
    end

    DEV -->|Promote| UAT

    subgraph UAT["🧪 UAT"]
        direction TB
        style UAT fill:#fff9c4,stroke:#f57f17
        U_VMs["🖥️ Single VMs<br>(General SKUs)"] --> U_PG["📦 General PG<br>(LRS)"]
        U_AS["🌐 Standard Services"] --> U_SA["🗄️ LRS Storage"]
    end

    UAT -->|Promote| PROD

    subgraph PROD["🏭 PROD"]
        direction TB
        style PROD fill:#e8f5e9,stroke:#38761d
        P_VMs["🖥️ HA VMs Cluster<br>(High-tier SKUs)"] --> P_PG["📦 Memory Opt. PG<br>(ZRS/GRS)"]
        P_AS["🌐 Premium Services"] --> P_SA["🗄️ ZRS/GRS Storage"]
    end

    PROD -->|Replicate| STG
    PROD -->|Replicate| TRN

    subgraph STG["🚀 STG (Ephemeral)"]
        direction TB
        style STG fill:#e8f5e9,stroke:#38761d,stroke-dasharray:5 5
        STG_VMs["🖥️ PROD Mirror"] --> STG_PG["📦 PROD Mirror DB"]
        STG_AS["🌐 PROD Mirror"] --> STG_SA["🗄️ PROD Mirror Storage"]
    end

    subgraph TRN["🎓 TRN"]
        direction TB
        style TRN fill:#fff0f5,stroke:#c51162
        T_VMs["🖥️ UAT-like VMs"] --> T_PG["📦 Dummy Data DB"]
        T_AS["🌐 UAT Services"] --> T_SA["🗄️ Training Storage"]
    end

    class PROD,STG,UAT,DEV,TRN envBox;

This approach supports modern DevOps practices by enabling a unified Infrastructure as Code (IaC) and Configuration Management (CM) codebase, parameterised for each environment, streamlining deployments and reducing environment-specific discrepancies.

3.6.1. Production (PROD) Environment: Dedicated, High-Tier, Redundant Resources¶

The PROD environment is engineered for maximum performance, resilience and availability, hosting live services and data.

• Purpose: To host the live, operational eMap platform, serving all end-users and integrated systems. It requires the highest levels of stability, performance and data integrity.
• Resource Allocation Strategy:
  • Compute (Portal, Server, Data Store VMs):
    • Portal for ArcGIS: Deployed on a dedicated, appropriately sized Azure VM. High Availability (HA) for Portal (e.g., a two-machine active-passive configuration) is targeted for implementation in Silver Stage.
    • ArcGIS Server: Deployed as an Azure VM Scale Set (VMSS) using a "golden image", configured with an initial minimum of one instance (MVP Stage) and auto-scaling rules (Stage Bronze onwards) to handle production loads. Instances utilise performant VM SKUs.
    • ArcGIS Data Store: Deployed on dedicated Azure VMs. HA (primary-standby configuration) is targeted for implementation in Silver Stage.
  • Web Tier (ArcGIS Web Adaptors on Azure App Service):
    • Two dedicated Azure App Service instances per region (one for Portal, one for Server) hosted on performant App Service Plans.
    • Configured for manual scaling (minimum 2 instances) in MVP Stage, with auto-scaling based on metrics implemented in Bronze Stage.
    • Fronted by a full-featured Web Application Firewall (WAF) and Application Delivery Controller (ADC), with ADC HA targeted for Silver Stage. Global Server Load Balancer (GSLB) and optional CDN are implemented in Gold Stage.
  • PaaS Data Stores (User-Managed):
    • Azure Database for PostgreSQL (Flexible Server): Dedicated instance, utilising a Memory Optimised or high-tier General Purpose SKU. Configured for Same-Zone HA within Melbourne (Silver Stage) and Geo-Redundant Backup to Sydney (Gold Stage).
    • Azure Storage (Blob, ADLS Gen2, Files): Dedicated Storage Accounts.
      • Azure Blob Storage & ADLS Gen2: Zone-Redundant Storage (ZRS) for MVP Stage, transitioning to Geo-Redundant Storage (GRS) in Gold Stage.
      • Azure Files: Premium tier (SSD) with ZRS for MVP, transitioning to GRS for Gold Stage.
• Resilience Features:
  • Full High Availability (intra-region) for all critical components is progressively implemented (targeting Silver Stage).
  • Full Disaster Recovery (inter-region, Melbourne to Sydney) capabilities are progressively implemented (targeting Gold Stage).
• Cost Optimisation: Achieved through right-sizing resources, auto-scaling, leveraging Azure Reservations or Savings Plans for predictable workloads and efficient use of storage tiering.
• Automation: All aspects of PROD environment should provisioned and managed via OpenTofu and Configuration Management scripts, ensuring consistency and repeatability.

3.6.2. User Acceptance Testing (UAT) Environment: Dedicated Lower-Tier Resources¶

The UAT environment provides a high-fidelity platform for end-users and stakeholders to validate changes before deployment to Production.

• Purpose: To conduct comprehensive user acceptance testing, performance testing and pre-production validation of new features, configurations and data.
• Resource Allocation Strategy:
  • Compute (Portal, Server, Data Store VMs):
    • Mirrors PROD's multi-component structure with separate, dedicated VMs for Portal for ArcGIS, ArcGIS Server (single instance) and ArcGIS Data Store (single instance).
    • Utilises lower Azure VM SKUs (e.g., smaller General Purpose or Burstable tiers) compared to PROD, sized to meet Esri minimum requirements and support UAT activities.
  • Web Tier (ArcGIS Web Adaptors on Azure App Service):
    • Two dedicated Azure App Service instances (one for Portal, one for Server) hosted on lower-tier App Service Plans (e.g., Basic or Standard).
    • Fronted by a WAF and ADC, potentially simplified (e.g., Azure Application Gateway with WAF SKU or smaller ADC instances) and without HA configuration for the ADC.
  • PaaS Data Stores (User-Managed):
    • Azure Database for PostgreSQL (Flexible Server): Separate, dedicated instance (e.g., smaller General Purpose or Burstable tier) with Locally-Redundant Storage (LRS) backups. No cross-region replication.
    • Azure Storage (Blob, ADLS Gen2, Files): Separate, dedicated Storage Accounts.
      • Azure Blob Storage & ADLS Gen2: Configured with LRS replication.
      • Azure Files: Standard HDD tier with LRS replication.
• Resilience Features: No HA or DR configurations are implemented. Recovery relies on redeployment via automation scripts and restoration from backups.
• Cost Optimisation: Achieved through the use of lower-tier SKUs, LRS for storage, absence of HA/DR, smaller quotas and potential auto-shutdown policies for VMs and services during periods of inactivity.
• Automation: Deployed and managed using the same OpenTofu and Configuration Management automation suite as PROD, with UAT-specific parameters ensuring architectural consistency.

3.6.3. Development (DEV) Environment: Dedicated Minimal Resources¶

The DEV environment supports development, unit testing and initial integration testing by the technical teams.

• Purpose: To facilitate software development, workflow creation (e.g., VertiGIS Studio Workflows), automation script development and initial functional testing by developers and GIS engineers.
• Resource Allocation Strategy:
  • Compute (Portal, Server, Data Store VMs):
    • Mirrors PROD's multi-component structure with separate, dedicated VMs for Portal for ArcGIS, ArcGIS Server (single instance) and ArcGIS Data Store (single instance).
    • Utilises the lowest practical Azure VM SKUs (e.g., Burstable B-series) that meet Esri minimum requirements for base functionality.
  • Web Tier (ArcGIS Web Adaptors on Azure App Service):
    • Two dedicated Azure App Service instances (one for Portal, one for Server) hosted on minimal App Service Plans (e.g., Basic tier, potentially Free tier if viable for limited testing, single instance).
    • Fronted by a WAF and ADC, configured similarly to UAT but potentially with even smaller/fewer resources.
  • PaaS Data Stores (User-Managed):
    • Azure Database for PostgreSQL (Flexible Server): Separate, dedicated instance (e.g., Burstable tier with potential for auto-pause). Configured with LRS backups and no cross-region replication.
    • Azure Storage (Blob, ADLS Gen2, Files): Separate, dedicated Storage Accounts.
      • Azure Blob Storage & ADLS Gen2: Configured with LRS replication.
      • Azure Files: Standard HDD tier with LRS replication.
• Resilience Features: No HA or DR configurations are implemented. Recovery relies on redeployment via automation and restoration from backups if necessary.
• Cost Optimisation: Maximised through the use of minimal SKUs, LRS for storage, absence of HA/DR, aggressive auto-shutdown policies for VMs and services, potential scale-to-zero for App Service Plans and smaller data quotas.
• Automation: Deployed and managed using the same OpenTofu and Configuration Management automation suite as PROD and UAT, with DEV-specific parameters.

3.6.4. Training (TRN) Environment: Replica of PROD (Architecture) with UAT SKUs¶

The TRN environment is specifically designed to provide a stable platform for training activities, mirroring PROD's architecture but optimised for cost.

• Purpose: To enable effective training for end-users, administrators and developers on a platform that architecturally resembles Production. This environment will contain dummy data relevant for training scenarios.
• Resource Allocation Strategy:
  • Architecture: A replica of the PROD environment's multi-component architecture. This means dedicated VMs for Portal for ArcGIS, ArcGIS Server (single instance) and ArcGIS Data Store (single instance). ArcGIS Web Adaptors will be hosted on Azure App Service. This architectural parity ensures training accurately reflects the production setup.
  • Compute (Portal, Server, Data Store VMs): Utilises Azure VM SKUs, instance counts and storage tiers that mirror the UAT environment. This ensures cost-effectiveness while maintaining architectural fidelity with PROD.
  • Web Tier (ArcGIS Web Adaptors on Azure App Service): Mirrors the UAT environment, using two dedicated Azure App Service instances on lower-tier App Service Plans, fronted by a simplified WAF/ADC.
  • PaaS Data Stores (User-Managed): Mirrors the UAT environment. This includes a separate Azure Database for PostgreSQL instance (e.g., Burstable tier with LRS backups) and Azure Storage accounts (Blob, ADLS Gen2, Files) configured with LRS replication.
  • Data: Populated with dummy data sets specifically designed for training exercises. Real production data will not be used in this environment.
• Resilience Features: Similar to UAT, no HA or DR configurations are implemented. Recovery relies on redeployment via automation scripts.
• Cost Optimisation: Achieved through the use of UAT-level SKUs, LRS for storage, absence of HA/DR and potential auto-shutdown policies for VMs and services during periods of inactivity.
• Automation: Deployed and managed using the same OpenTofu and Configuration Management automation suite as PROD, UAT and DEV, with TRN-specific parameters (e.g., for dummy data loading).

3.6.5. Staging (STG) Environment: Ephemeral Mirror of PROD for Load Testing¶

The STG environment is a transient, high-fidelity replica of PROD, created specifically for load testing.

• Purpose: To conduct comprehensive load testing of the ArcGIS Enterprise deployment, simulating peak user loads and transaction volumes to validate performance, scalability and identify potential bottlenecks before changes are promoted to Production. This environment is ephemeral; it is created for a load testing run and then decommissioned.
• Resource Allocation Strategy:
  • Architecture and SKUs: An exact mirror of the PROD environment in terms of its multi-component architecture, Azure resource SKUs, instance counts and configurations at the time of STG creation. This ensures that load test results accurately reflect PROD's behaviour.
  • Compute (Portal, Server, Data Store VMs): Mirrors PROD's compute setup, including any HA configurations for Portal and Data Store VMs and the VMSS configuration for ArcGIS Server.
  • Web Tier (ArcGIS Web Adaptors on Azure App Service): Mirrors PROD's Web Tier, including App Service Plan tiers, instance counts and WAF/ADC configurations.
  • PaaS Data Stores (User-Managed): Mirrors PROD's PaaS data store setup, including Azure Database for PostgreSQL tiers and storage account configurations (e.g., ZRS/GRS, Premium tiers).
  • Data: May be populated with a sanitized, anonymized subset of production data or a realistically scaled synthetic dataset suitable for generating representative load.
• Resilience Features: Mirrors the resilience features (HA/DR) implemented in the PROD environment at the time the STG environment is provisioned. This allows for testing the platform's behaviour under load with its full resilience mechanisms active.
• Cost Optimisation:
  • The primary cost optimisation strategy is its ephemeral nature. The STG environment is provisioned only when needed for a load testing cycle and is de-provisioned (deleted) immediately afterwards.
  • For very extended load testing periods, short-term Azure Reservations might be considered for compute resources if it offers cost benefits over pay-as-you-go.
• Automation: The creation, configuration and destruction of the STG environment must be fully automated using the unified OpenTofu and Configuration Management codebase, with STG-specific parameters. This ensures rapid, consistent provisioning and teardown, minimising manual effort and cost.

This environment isolation strategy provides a balanced approach, enabling robust and resilient production services, effective training and thorough load testing, while ensuring that development and pre-production testing activities can proceed efficiently and cost-effectively. The consistent use of automation across all environments is crucial to providing reliability and speeding up delivery.