Cloud Design Patterns for Edge Computing: Adapting to New Realities

When designing an application to run in the cloud, typically using container orchestration with Kubernetes, several well-established design patterns guide the process. However, when you start designing an application for the edge—or consider moving an existing cloud application to the edge—are these same patterns still applicable?

In this article, we’ll explore some of the most well-known cloud design patterns and examine their relevance when applied to edge computing.

Understanding Edge Applications

Before delving into specific patterns, it’s crucial to establish the context for edge applications. The “edge” we refer to in this discussion is the far edge, characterized by relatively small sites that typically have between 1 and 10 computers. These sites are often found in environments like retail stores, factory floors, mining operations, ships, and similar settings. Unlike large data centers or centralized cloud environments, far edge sites operate with limited resources and are distributed across many physical locations.

Edge environments differ significantly from cloud environments in several key ways:

Cloud Patterns at the Edge

Load balancing at the Edge

In cloud-based applications, the focus is on centrally managing a high and variable load of incoming requests. However, in edge applications, the scenario changes. Instead of a central application, you have a distributed application across many edges, each serving a smaller set of clients.

This distribution inherently solves much of the need for load balancing. Therefore, the complex load balancing mechanisms often used in the cloud can be significantly simplified at the edge, reducing complexity and maintenance efforts.

That said, some load balancing needs to persist at the edge. For instance, managing replicas for availability and upgrades still requires simple round-robin requests and health-check mechanisms. A site-local DNS, in combination with site-local health probes, can efficiently manage these requirements.

Dynamic Scaling at the Edge

In the cloud, horizontal and vertical scaling are standard practices—running more replicas or allocating more resources as needed. However, resources are inherently limited at the edge, often confined to a few hosts. This limitation restricts your ability to scale horizontally or vertically.

Instead of based on load, edge scaling is typically governed by the physical resources available at each site. For example, the number of application replicas might be determined by the number of hosts at an edge site. While dynamic scaling can still be implemented, the edge environment tends to simplify this process.

Dynamic Resource Usage

Cloud environments associate dynamic costs with resource usage, such as GPUs, which incentivizes careful resource management. In contrast, these costs are fixed at the edge as part of the initial infrastructure investment.

This makes resource allocation more static at the edge but also requires ensuring that applications are locally scheduled to the edge hosts where the necessary resources, like GPUs, are available.

Everything central

Cloud applications rely on centralized resources for essential items like secrets and images, assuming consistent connectivity. However, edge applications cannot assume this connectivity. Instead, all necessary resources must be cached and distributed to the edge to ensure autonomy.

Security in Edge Computing

Security requirements at the edge differ fundamentally from those in the cloud. Edge environments often lack the centralized protection of cloud systems and may operate in insecure networks. For further details on edge security, see our related articles:

• Tech blog: How to automatically manage application certificates across thousands of edge sites
• Securing the edge – white paper
• Avassa security overview

Cattle vs Pets

In cloud environments, servers are treated as “cattle”—interchangeable and easily replaced. However, edge environments are inherently heterogeneous, with varying hardware, network performance, and site configurations.

Edge applications must accommodate differences across diverse environments to ensure functionality, such as by supporting multi-architecture containers. Deployment strategies must also adapt to these varied conditions.

See our article for more on achieving different numbers of replicas for different sites: https://avassa.io/tech/i-need-different-number-of-replicas-per-edge-site-can-i-do-that/

Deployment

Deployment strategies differ significantly at the edge. While cloud deployments typically involve a single dev, stage, and prod environment, edge deployments may target thousands of sites with unique characteristics.

Edge deployments require tools to handle different configurations and manage unstable network connections. Canary deployments at the edge also differ, targeting multiple sites instead of just a few instances in the cloud.

Monitoring the Edge

Cloud monitoring relies on centralized principles, with all components “always on.” In contrast, edge sites may be disconnected at times, necessitating more context-aware, local monitoring solutions. For more insights, we’ve outlined principles for edge-native monitoring in:

• Observability at the edge – white paper
• Edge observability: https://avassa.io/articles/edge-observability-shift-left/
• Video: Ask the expert – Edge observability

Summary

As outlined, cloud design patterns often need to be simplified for edge computing due to the distinct characteristics of edge environments. This simplification can reduce both application complexity and operational costs. While cloud and Kubernetes design patterns work well in data centers and the cloud, they might not be the best fit for edge computing. Instead, new patterns like caching resources and managing heterogeneous environments are more relevant at the edge.