If you’re planning an ArcGIS Utility Network migration in a cloud environment, such as Amazon Web Services (AWS), Microsoft Azure, or GCP (Google Cloud Platform), you’ve likely encountered conflicting influences when it comes to choosing your system’s architecture. Cloud consultants often push Kubernetes (K8s) as ‘the future’, while GIS teams worry about complexity, and leadership looks to reduce infrastructure costs. You may be wondering whether it’s best to use traditional virtual servers, embrace Kubernetes, or to blend these architecture patterns. This vital infrastructure decision has the power to impact performance, cost, and operations.
Kubernetes is a cloud-native technology platform that automatically manages and orchestrates containerized applications, ensuring applications stay running even when servers fail by replacing failed components and rerouting without human intervention. Another key feature of Kubernetes is that the technology automatically scales services up when demand spikes and then back down when the load is normal, so that customers only pay for what they use. This self-healing, autoscaling capability has the potential to transform static infrastructure into a dynamic, resilient system that adapts to changing conditions in real time.
Utility companies transitioning to Esri’s Utility Network Management solution in the cloud have a unique opportunity to reevaluate their infrastructure during this transformative process, empowering them to choose the best architecture pattern for their specific infrastructure and business needs. Drawing from our experience with Utility Network deployments, we’ve identified how utilities can optimize infrastructure costs through improved resource utilization and elastic scaling that cloud offers, while maintaining the performance and reliability that the Utility Network requires. In our experience, a blended approach leveraging both the Kubernetes and virtual server architecture patterns can provide the architectural flexibility for addressing the common modernization scenarios faced by utilities today.
This article discusses two supported blended architecture patterns specifically designed for the Utility Network’s requirements based on proven cloud deployment strategies:
- Blended Federation: A single ArcGIS Enterprise deployment with Utility Network services published on virtual traditional servers and all other services published within containers
- Blended Enterprise: Multiple ArcGIS Enterprise deployments where traditional virtual machines (VMs) are dedicated to the Utility Network while containers are used for everything else
Content Overview
Modern Architecture Challenges
In today’s world, every utility faces a unique set of technology modernization pressures that can shape their architectural decisions. For some organizations, the struggle is with ‘blue sky’ operational efficiency and cost management. Other utilities identify the most pressing concern as ‘gray sky’ emergency events and the unpredictable system load on public mapping applications to check outage statuses. Meanwhile, the architecture must also be able to support field crews in accessing the Utility Network during major events, along with providing access to dozens or even hundreds of Utility Network editors for routine work-order posting jobs.
The organizational dynamics within each utility can also influence the modernization path. Some have separate teams managing their GIS and IT infrastructure, often creating silos and natural boundaries that can complicate unified cloud strategies. These internal stressors can lead to several technical challenges, including:
- Maintaining system uptime to ensure business continuity
- Providing reliable and scalable GIS services optimized for web mapping, analytics, and integration needs
- Balancing innovation with operational stability and regulatory compliance, while preserving a strict security posture and commitment to risk management
Whether deployed on AWS EC2 instances, Azure VMs, or GCP VMs, these architectures utilize a monolithic scaling approach that worked well in the customer data center era but now struggle with cloud economics and modern operational demands.
One of the major limitations, and a significant one with VM architecture, is the slow service initialization when scaling out for capacity. Even with optimized autoscaling configurations, when a new VM node joins an ArcGIS Server site, the services take a significant time to start up and become healthy. Map services must load their configurations, build caches, and initialize all service handlers before accepting requests. This startup sequence can take several minutes per service; that means a new node might need substantial time before it’s fully operational and ready to handle traffic. In contrast, Kubernetes-orchestrated pods have containerized services that start in seconds rather than minutes, leveraging lightweight images with pre-initialized configurations and optimized startup sequences that eliminate the need to boot full servers. This capability allows services to come online almost instantaneously during high demand.
Conversely, ArcGIS Enterprise on Kubernetes promises cloud-native benefits like elastic scaling and self-healing through Infrastructure as Code (IaC) but introduces its own challenges, especially around software upgrades. ArcGIS Enterprise on Kubernetes follows a regimented upgrade path since it’s a Software as a Service (SaaS) solution. Given this consideration, the two architectural patterns we present aren’t just alternatives; they’re engineered solutions that work within this real-world situation.
The Utility Network Factor
Here’s what makes this architecture decision unique for Utility Network: editing workloads behave fundamentally differently from map viewing workloads. Editing workloads require stateful topology caching, persistent database connections, and stable branch versioning. These characteristics align naturally with traditional virtual server deployments. Conversely, map viewing works well with stateless services, making those workloads ideal for Kubernetes’ elastic autoscaling capabilities.
Utility Network on ArcGIS Enterprise for Kubernetes is on Esri’s future roadmap. Until then, utilities can take this opportunity to think strategically about their workload optimization, rather than pushing their entire enterprise GIS into a single architecture pattern.
The Solution: Blended Architecture Patterns
The architectural flexibility available today begins with understanding that Kubernetes hosts a complete ArcGIS Enterprise deployment with ArcGIS Server sites and ArcGIS Data Stores, not just Portal for ArcGIS. This is all encompassed within a Namespace of a Kubernetes cluster. Organizations can leverage the pod-based architecture of ArcGIS Enterprise on Kubernetes to isolate workloads—all running as containerized microservices.
In the case of Utility Network, a blended architecture pattern leveraging traditional virtual servers and containers will be the best path forward if your organization seeks to deploy ArcGIS Enterprise on Kubernetes. The following blended architecture patterns highlight two different approaches utilities should consider. In practice, these patterns build a strategic architecture by placing each component where it excels and meets supportability requirements, synthesizing lessons learned from legacy deployments with emerging cloud-native possibilities from modern deployments.
Blended Federation Architecture
The Blended Federation approach separates Utility Network operations from general viewing services, deploying each on its optimal platform. All services pertaining to Utility Network functionality—including editing, tracing, network propagation, association management, and other network-specific workflows—remain on traditional VM infrastructure for maximum stability. Meanwhile, services are published to Kubernetes for general non-Utility Network content as well as for Utility Network visualization and analysis that don’t require network-specific functionality. This separation creates clear architectural boundaries between network-specific operations and high-volume viewing and analysis workloads. This separation protects the Utility Network’s performance during editing as well as critical network traces, while enabling elastic scaling for other map services.
From an architecture perspective, the non-Utility Network content operates on Kubernetes-orchestrated containers using multiple pods equating to specialized ArcGIS Server sites. These pods are configured with horizontal autoscalers that respond to a central processing unit (CPU) and memory health and performance thresholds. With this pattern, federation of a separate ArcGIS Server site creates a seamless integration with clear boundaries. Utility Network-dependent capabilities, like network traces and validation rules, are isolated to traditional virtual servers, while leveraging a single Portal for ArcGIS. Everything else—tile caches, spatiotemporal data, remote sensing data, non-asset operational services, web maps, web applications, and dashboards—resides in ArcGIS Enterprise on Kubernetes. Users can access everything through one Portal for ArcGIS without seeing the architectural split on the backend, while the infrastructure respects the uniqueness of the Utility Network. Most of the ArcGIS Enterprise components can fully leverage the resiliency benefits of a cloud-native service like Kubernetes because Portal for ArcGIS, ArcGIS Data Store, and all non-Utility Network services are running on containers. A consideration with the Utility Network services in that they must rely on traditional virtual server autoscaling.
Though this approach would require frequent upgrades, the architecture leverages native Kubernetes’ functionality to ensure high availability during the upgrade process. Kubernetes allows rolling updates where containers are replaced gradually, reducing downtime and lowering upgrade risk.
UDC recommends this approach for organizations that are beginning their Kubernetes journey or those seeking modernization with limited resources that are comfortable with continuous upgrades of ArcGIS Enterprise.
Blended Enterprise Architecture
Like the Blended Federation pattern, this approach separates Utility Network services from general GIS services, but it does so using multiple ArcGIS Enterprise deployments. The Utility Network content remains on traditional virtual servers within a separate ArcGIS Enterprise, and the remaining content resides on containers within ArcGIS Enterprise for Kubernetes.
With this pattern, the general GIS services can leverage containers to scale out and in to meet spikes in demand, while the Utility Network services utilize traditional virtual server autoscaling to achieve similar scalability. It’s important to re-emphasize that this pattern involves completely separate ArcGIS Enterprise deployments, and therefore, it’s equally important to recognize that traditional virtual server autoscaling capability is limited to ArcGIS Server sites and ArcGIS Web Adaptors. Portal for ArcGIS and ArcGIS Data Store cannot fully leverage traditional virtual server autoscaling. However, it’s worth pointing out one key distinctive benefit of the Blended Enterprise pattern: you maintain full control of your upgrades.
With the Blended Federation approach, the same can be true but only to a certain extent, meaning that at some point in time, the software version difference between ArcGIS Enterprise for Kubernetes and the federated ArcGIS Server site will become too disparate for supportability without upgrading the federated site.
Other potential benefits of the Blended Enterprise pattern include better security separation between internal operations and public access, independent scaling for meeting distinct types of demand, separate maintenance windows that can significantly reduce downtime, and cost optimization through the use of elastic scaling. On the flipside, compared to the Blended Federation pattern, the Blended Enterprise pattern can have a higher licensing and infrastructure cost.
UDC recommends this pattern when there are distinct user communities with different service level agreements (SLAs) and when advanced security requirements, complex usage patterns, or variable demand are expected. The additional overhead of managing multiple ArcGIS Enterprise deployments can be offset by the operational independence and risk mitigation it provides. This approach delivers minimal operational risk by preventing issues from propagating across deployments.
The diagram below can be used to help your utility decide which architecture pattern may best align with your organization’s current and future infrastructure needs.
Benefits of a Blended Architecture Pattern
The benefits realized from these two blended architecture patterns depend heavily on your business requirements and how you leverage the deployment of ArcGIS Enterprise across platforms for Utility Network. Organizations can often discover unexpected optimizations by reimagining their architecture. That geoprocessing site that sat idle 80% of the time on a virtual machine can now scale to zero on Kubernetes, eliminating waste. The mapping site struggling with morning login spikes can now pre-scale based on time of day and day of week. The flexibility to deploy ArcGIS components where they run best, while maintaining software supportability, transforms theoretical cloud benefits into practical operational improvements.
The financial benefits and implications vary based on workload characteristics and deployment decisions. Organizations with highly variable workloads or public-facing web applications see the greatest cost optimizations from Kubernetes deployments and realize the most flexibility with the Blended Enterprise pattern. For example, a utility that experiences 100x normal load during high demand periods can now scale dynamically rather than maintaining year-round capacity for peak. Conversely, utilities with steady, predictable workloads and smaller budgets might find the Blended Federation pattern more appropriate. These blended architecture patterns enable organizations to optimize based on their specific needs—rather than forcing a one-size-fits-all-approach.
Operational benefits often exceed initial expectations. The ability to deploy new services through IaC transforms delivery timelines. What once required procurement, installation, and configuration over several weeks now happens within hours through automated pipelines. Container orchestration provides self-healing capabilities that significantly reduce pressure on system administrators.
Utilities maintaining only traditional virtual server deployments may not need Kubernetes, especially if their current architecture meets business needs efficiently. However, those adopting either of the blended architecture patterns gain the added benefit of flexibility that Kubernetes offers to optimize each workload independently.
Choosing Your Best Cloud Option
When navigating today’s complex energy landscape, every utility—regardless of size or commodity—must start with a clear understanding of its business goals. Defining these requirements upfront is key to choosing the right strategy for your organization. By carefully evaluating the advantages and disadvantages of each architecture pattern, your organization can determine the best-fit solution that drives long-term business value.
The key question is no longer whether the Utility Network can run on ArcGIS Enterprise for Kubernetes or whether Kubernetes is a better option than traditional virtual servers. Utility Network services require traditional virtual server deployments, and everything else can reside wherever it makes sense for your organization. So, the question instead becomes which combination of architecture patterns will best enable my organization’s success? The key is understanding that you have choices, although those choices are limited to a subset of supported configurations.
The final takeaways are these:
- Traditional virtual server infrastructure remains viable for appropriate workloads, but is required for ArcGIS Utility Network services.
- Containerized infrastructure provides optimal scalability and resiliency benefits across ArcGIS Enterprise, and as containerization continues to expand, ArcGIS Utility Network services are not far from being a candidate for future Kubernetes support.
Contact UDC for help determining the right architecture pattern for your organization and learn about our Enterprise Architecture services.