7 Rules for Edge-Native Applications

Future-proof your architecture for Edge Computing

Edge Computing offers a new paradigm for running software applications outside the Cloud. It enables a new class of latency-sensitive and bandwidth-hungry applications. But how can architects design their applications for the Edge? And how can developers take advantage of Edge Computing?

Start by adopting an Edge-Native architecture.

Edge-Native Applications

What does Edge-Native mean? Edge-Native applications are built from the ground up with Edge in mind — just like Cloud-Native applications are built for the Cloud. Edge-Native applications take advantage of the unique capabilities and characteristics of the Edge.

This article covers a few basic rules for building Edge-Native applications.

1. Create Hierarchy

Decompose your architecture into services (or micro-services even). Each service might depend on some other subset of services. This is your dependency graph.

The simplest example is a three-tier web architecture where you might have a front-end tier, application/business logic tier, and a back-end persistence/database tier. The front-end tier depends on the application tier which depends on the back-end.

For an Edge-Native application, your dependency graph should form a clear hierarchy. If not, you may need to either:

1. Reduce the dependencies on certain client-facing services
2. Create a new service that acts as a front-end or caching layer

After drawing and adjusting your dependency graph, the services at the bottom of the hierarchy become your potential Edge Services (assuming that the bottom is where end-clients connect to your system). Evaluate these services carefully to determine if they might be suitable for running outside the Cloud (e.g., are they stateless?) and how your application might benefit from moving them (e.g., reducing bandwidth or improving responsiveness).

2. Embrace Caching

With your Edge Services identified, next, consider your data caching strategy. Start by evaluating your current global data strategy. How does data flow in and out of your services? Where and how is data stored currently? What are the data consistency and availability requirements for your application? Augment your dependency graph with this information.

If there are already caching layers in your architecture, consider whether they may benefit from running at the Edge. You may already be running a caching layer at the Edge in the form of a CDN. If not, consider augmenting your potential Edge Services with caching capabilities.

Identify what data to cache. Caching ephemeral state at the Edge can be useful for improving application response times.

3. Scale Up, Down, Out and Back

Each service in your architecture should have a scalability story. How does your service respond to increasing load? What metrics do you rely on for auto-scaling each service?

Usually, services in the Cloud have the option to scale out horizontally by spinning up new virtual machines or containers to take on heavy load within a single data center. Cloud-Native applications can also gracefully scale down during quiet times to save resources. We’ll refer to these capabilities as scaling up and scaling down, respectively.

Edge-Native applications have the new ability to scale out to the Edge or scale back to the Cloud. Meaning that in times of heavy load, some of the services that usually run in the Cloud can be moved to run in the Edge to dramatically offload Cloud resources. Alternatively, should request volume overwhelm Edge resources, some requests could fall back to processing in the Cloud.

Consider what metrics you might use to decide to scale out to or scale back from the Edge.

4. Shrink It

Edge Services must be small. The time it takes to transfer an image (whether it’s a function, a container, or a virtual machine) can dominate the spin-up time of an Edge Service. Containers and functions are ideal for shrinking the size requirements for Edge Services. However, architects and developers must remain vigilant to prevent image bloat in Edge Services.

Minimize or eliminate dependencies and compress images for Edge Service whenever possible. And keep your memory requirements in check.

5. Mobilize

Mobile users change locations while expecting a seamless experience with your application. For Cloud-hosted applications, the effect of changing cell towers is usually transparent from the perspective of the application and not something that Cloud application architects need to worry about. However, Edge changes that.

Mobile Edge Computing (MEC) is one of the hottest trends to ride the 5G bandwagon. Mobile Service Providers (i.e., Telcos) are excited about MEC as a means of further monetizing their valuable access networks. As such, Edge Computing platform may very well become embedded in the Edge of the mobile network.

What does this mean for Edge-Native application developers? First, understand that future Edge platforms will support proximity-based routing. These platforms will provide the capability for sending requests to the “closest” Edge location to a given client. The definition of “closest” requires its own article, so let’s ignore that for now.

By routing client requests to the closest Edge site, a single application session for a mobile user may very well span multiple Edge servers. In other words, your ephemeral state from rule #2 might disappear without notice. Edge Computing platforms may build in hooks for notifying applications of client mobility. In the meantime, expect that mobile clients will change locations and consider the implications on your architecture.

6. Expect Catastrophic Failure

The Cloud is a relatively stable platform that may experience a complete outage just a few times in a year. Think of the Cloud like civilization: urbanized and modernized. Think of the Edge like the frontier: untamed and wild. Catastrophic failure at the Edge is not an exception; it is the rule. Edge-Native applications must plan for catastrophic failure. Some Edge sites may suffer single points of failure in their network and power supplies.

Edge-Native applications must always be ready to scale back to the Cloud due to failure at the Edge. Assume all data at the Edge is ephemeral and could be lost without recovery.

7. Trust No One

Finally, security. Compared to the Cloud — sitting in a locked data center with multiple layers of physical, virtual, and human security — the Edge is much more vulnerable. Some Edge data centers may enjoy the same security attributes as the public cloud but some may not. Your code may run in an unattended site where attackers could gain physical access.

Avoid storing sensitive data or secrets at the Edge. When using an Edge Computing platform, understand where your code might run and restrict it through policy based on your requirements. Always establish trust from the Cloud to the Edge and offload trust to Cloud-hosted services whenever possible. Rely on key rotation, localization, and techniques that will limit the exposure of a data breach. Unless your Edge Computing platform provider can assure the integrity of your code running at the Edge, assume that all Edge Services might be compromised.

Wrap-up

Edge Computing platforms remain in their infancy. Applying these rules will keep your architecture ready for adopting these new platforms as they emerge.

CDN providers are leading the way in Edge Computing. For example, Lambda@Edge from AWS provides a mechanism for running AWS Lambda functions at the Edge of the AWS CloudFront CDN. Services like Lambda@Edge offer a limited set of capabilities for developers to get started with building Edge-Native applications. Lambda and other functions-as-a-service offerings are great for HTTP-based applications. As these services mature, we can expect more complex functionality at the Edge in the future.

At the end of the day, the Edge is just another place to run your code, and the same rules of thumb apply. I’ll leave you with my favorite of all: keep it simple.

“Simplify, simplify.” — Henry David Thoreau

Please share your thoughts in the responses here. What rules did I miss? Connect to me on LinkedIn if you’d like to talk about the evolution of Edge Computing and its impact on cloud application architecture. And please follow me on Medium if you’d like to hear more!