Reliability is critical to keeping business operations running, minimizing disruptions, and meeting user expectations. However, reliability is not a one-size-fits-all approach. For example, a city planning department using ArcGIS Enterprise for internal zoning and planning workflows may be able to tolerate occasional downtime due to patching and can accept some failure conditions and recover using backups within a few hours. In comparison, an emergency management agency providing public-facing incident maps during a natural disaster requires continuous availability and recovery times measured in minutes.
These two systems have very different reliability requirements, yet both can be considered well-architected because their reliability strategies align with their organization’s business objectives, user expectations, and operational constraints. When architecting for reliability, the ArcGIS Well-Architected Framework provides guidance for translating business requirements into architectural and operational decisions that support reliable, resilient systems. While ArcGIS is available as a highly reliable SaaS offering through ArcGIS Online, the guidance in this article focuses on self-hosted deployments including ArcGIS Enterprise on Windows, Linux, and Kubernetes.
What Does ‘Reliable’ Actually Mean?
For a well-architected system, reliability means consistently supporting the GIS capabilities and workflows of an organization at the level of service the business requires. Defining reliability starts with understanding the business outcomes a system needs to support and the consequences of service disruption. This does not mean that every system must be highly available and highly redundant to be well-architected, because for some systems this would indicate an improper level of complexity or cost that may not be needed.
Organizations commonly measure reliability through Service-level Agreements (SLAs), which are commitments from providers to business users and clients to maintain a level of service at all times. The process of defining reliability for your organization involves translating business requirements into concrete SLA commitments that reflect what matters most to your users and workflows. The architectural choices used to achieve those SLA commitments will vary by organization. Some may rely on traditional or virtual deployment models, while others may adopt cloud-native deployment models that provide built-in capabilities for resilience, monitoring, backup and recovery, and automated failure detection. The specific approach is less important than ensuring that the chosen architecture aligns with business requirements and service expectations. An availability SLA defines a set of services, applications, or workflows; a time period during which they are expected to be available (usually 24 hours a day, 7 days a week); and a definition of what conditions constitute a breach of the SLA, such as repeated failures, slow requests, errors, or degraded user experiences. Rather than adopting a generic definition of reliability, well-architected systems focus on defining, monitoring, and responding to SLAs that are tailored to the organization’s own business needs instead of simply pursuing higher uptime numbers as a goal.
When systems are designed for a certain level of reliability, they typically use a combination of several techniques:
- High Availability. Building redundant system components, configured together and designed to take over and provide the same services in case of an outage.
- Backups. Regularly backing up the state of a system, the important details, data, and services for future recovery.
- Disaster Recovery. Planning for uncommon but disruptive scenarios and identifying methods to quickly rebuild a site or system
- Monitoring. Using effective monitoring to identify potential issues early, measure downtime, and report results for post-event analysis
Reliability in Modern Architectures
The techniques above can be implemented in many ways, depending on an organization’s needs, infrastructure, and operational practices. The right approach is the one that aligns with your business requirements and service expectations and not necessarily the one with the most redundancy.
High Availability
Designing a highly available system rarely starts with a blank canvas. Existing IT infrastructure, operational practices, technical expertise, and governance standards all shape the framework within which an enterprise GIS must operate and contribute to its availability. Business requirements dictate acceptable levels of downtime and data loss; deployment patterns influence how availability responsibilities are shared; infrastructure capabilities define practical boundaries; and maintenance needs affect how updates are introduced with minimal disruption.
ArcGIS Enterprise gives organizations that manage their own software the flexibility to design highly available systems:
- In Windows and Linux deployments, specific high availability configurations are used for each component of ArcGIS Enterprise, and interact with other design requirements like load balancing, workload separation, and failover strategies, and specific availability requirements through redundancy, load balancing, workload separation, and failover strategies.
- For teams adopting a cloud-native approach, ArcGIS Enterprise on Kubernetes supports high-availability by distributing workloads across multiple containers and infrastructure components rather than relying on a single point of failure. Architecture profiles can configure service redundancy and increase the number of deployed service instances to further align a deployment with availability goals.
Backups & Disaster Recovery
For enterprise systems, it is important to have a clear understanding of backup and disaster recovery (DR) strategies, so you can select what’s most appropriate for your system.
It’s worth noting that backups and DR are related but not the same. Backups preserve data and state; disaster recovery answers the broader question of what an organization does after a disaster, based on defining what both “disaster” and “recover” mean in their specific context, and outlining the process recovery requires.
- ArcGIS Enterprise on Windows and Linux supports both manual and scheduled backups, helping organizations automate protection of their deployment and reduce the risk of downtime or data loss after an incident. The Web GIS Disaster Recovery (WebGISDR) tool enables administrators to capture and restore a complete ArcGIS Enterprise deployment, while support for full and incremental backups helps improve efficiency and recovery readiness. Esri continues to introduce enhancements at every release, helping organizations restore services faster and minimize disruption.
- ArcGIS Enterprise on Kubernetes supports both manual and scheduled backups, letting organizations automate backup creation and reduce the risk of downtime or data loss after an incident. Cloud-native deployments can also support DR objectives by automatically detecting and recovering failed workloads, restoring services faster and minimizing disruption. For a look at this in practice, watch this live demonstration where an Esri expert shows how architecting for both high availability and recoverability improves reliability, with Kubernetes automatically detecting failures and restoring services with minimal downtime.
Monitoring
Even the most resilient systems require ongoing visibility into their health and performance. Monitoring helps organizations understand how their ArcGIS systems are operating, surface issues before they become outages, and respond more effectively when disruptions occur. Proactive monitoring is as important as reactive problem-solving, and effective telemetry is key to both point-in-time awareness and identifying long-term performance trends. ArcGIS-specific and system telemetry should be integrated into existing enterprise IT monitoring patterns wherever possible, so IT staff maintain holistic system awareness.
ArcGIS Enterprise supports a range of monitoring approaches through built-in capabilities, using ArcGIS Monitor, and integrations with third-party observability and monitoring platforms. The options vary by deployment.
- ArcGIS Enterprise on Windows and Linux can be monitored through component-specific logs and the Metrics API introduced in ArcGIS Enterprise 12.1. Your ArcGIS Enterprise can be configured to allow monitoring tools such as Prometheus to scrape data from the metrics API that can be used for visualization and analysis in third-party viewers like Grafana. Additionally, you can configure webhooks to receive alerts when particular events happen within your ArcGIS Enterprise. It’s just as important to monitor the technology stack supporting ArcGIS Enterprise: operating system, databases and data stores, and compute, network, and security infrastructure. For guidance on building a comprehensive observability approach, see Best practices for building an Enterprise GIS observability strategy.
- ArcGIS Enterprise on Kubernetes can be observed through system logs and health monitoring in ArcGIS Enterprise Manager, along with the same supporting infrastructure: the Kubernetes environment, databases, and underlying compute, network, and security components. Organizations can also integrate with third-party monitoring tools such as Prometheus and Grafana to visualize metrics, configure alerts, and track system health. Webhooks can further extend monitoring capabilities by triggering automated workflows and notifications when important events occur, helping teams respond more quickly to operational issues.
Designing for Your Definition of Reliable
The Reliability Pillar of the ArcGIS Well-Architected Framework provides organizations with the tools to properly define what reliable means in their context, establish meaningful SLAs, select appropriate reliability techniques, and build systems that deliver the right level of service without unnecessary complexity or cost.
Learn more about how your organization can create a well-architected and reliable system:
Article Discussion: