What is an edge-native application?

Cloud-native. Those two simple words redefined how we build, deploy, and even consume software. Twenty-five years ago, when I had hair I could pull on when having trouble with my code, the idea that I would use an office suite contained in my web browser would have sounded like science fiction. And yet, here we are. Gone are the days of installing an office suite from a pile of floppy disks. Naturally, the three or four years gap between releases is also a thing of the past. Nowadays, new features may appear anytime and anywhere, with no installation required. It's an understatement to say that the velocity of the software industry increased by an order of magnitude.

This evolution is a tremendous achievement from my perspective. Of course, if you are a bit younger than me or even one of those "cloud-native" developers who never experienced anything else, you surely see things differently. At this point, cloud-native is de facto how things are done—even for me. It is not exciting or new, just assumed. However, there are still applications living outside the cloud. Those applications are increasingly impacting our personal and professional lives. You see, software is eating the world. And this means cloud-native applications are increasingly supplemented with edge-native ones.

In this article, I will define edge applications and describe their characteristics. But before I get to that, it's important to understand how the cloud and edge environments differ.

What's the difference between edge and cloud?

We are increasingly surrounded by everyday objects powered by software. This is why I think the term Internet of Things will eventually be replaced by Software Defined Everything. This idea has profound implications for the way applications and services are built. In most cases, connecting things directly to the cloud doesn't make sense. This concept is where edge computing comes into play. Edge computing, at its core, provides compute, networking, and storage capabilities at the network's border, closer to the source of the data. It makes it possible to reduce latency and optimize bandwidth usage. It makes applications more resilient and lets users control where their data is located physically.

The edge and the cloud are two very different computing environments. The cloud is defined by the on-demand availability of resources. You can create new virtual machine instances, add network capacity, or change the network topology anytime. Cloud resources are naturally limited, but those limits are so high that most users will never bump into them. By nature, the cloud is heterogeneous, centralized, and large-scale.

• Heterogeneous: The cloud is heterogeneous since the compute resources available fit into several predefined types. It's possible to create hundreds or even thousands of instances of the same type, all identical unless customized. From a developer's perspective, they represent a stable and predictable hardware platform.
• Centralized: The cloud is centralized. You can deploy resources in specific data centers or geographical zones, but everything is managed from a central console.
• Large-scale: Finally, the cloud is inherently a large-scale environment. Your specific deployment may be small, but the resources at your disposal are immense in terms of capacity and performance.

The edge is the polar opposite of the cloud. It is heterogeneous, distributed, and small-scale. When designing edge computing solutions, picking the right hardware for the job is critical. In particular, battery-operated devices require top-notch power efficiency, which means that processors based on the ARM and RISC-V architectures are much more common than in the cloud. Moreover, many edge devices must interact with legacy equipment; they usually feature ports not found on IT equipment and leverage protocols specific to operational technology. For these reasons, edge hardware often differs from one physical location to another. By definition, edge computing implies distributed applications; data processing is performed in various physical locations across the whole edge-to-cloud continuum. Lastly, the edge is a small-scale environment. Of course, deploying thousands of edge nodes to support a solution is possible. However, the compute, networking, and storage resources will be severely limited in any specific location.

The distinctions between the two environments mean that edge-native applications differ greatly from cloud-native ones. Let's now look more closely at them.

Edge-native application characteristics

Edge-native applications share some characteristics with cloud-native ones. Both application types rely on microservices. They expose APIs, often in a RESTful way, which enables service composition. Both types of applications consist of loosely coupled services. This design prevents the creation of affinities between the services and enhances the overall resiliency of the application. Finally, teams leveraging a DevOps approach focused on continuous integration build them. Edge-native applications, however, will often avoid continuous deployment—especially for applications driven by real-time or mission-critical requirements.

Edge-native applications naturally possess specific characteristics setting them apart. Specifically, these are lifespan, heterogeneity, and constraints.

• Lifespan: Edge-native applications typically have a long lifespan. Edge-native applications usually include significant capital investments, such as heavy machinery or industrial equipment. This means they must be maintained and operated for years, if not decades.
• Heterogeneity: Edge-native applications exhibit heterogeneity. Here, I am not only referring to the edge node themselves but also to the origin of all the components of the solution. No one supplier can provide you with the sensors, actuators, microcontrollers, edge nodes, software, and networking equipment needed to build and deploy a solution. At a minimum, you must deal with several vendors with different support lifecycles and commitments to your particular market.
• Constraints: Edge-native applications are constrained by the realities that edge hardware and software face in the field. It's a harsh world outside the data center. The list of threats is long: Extreme temperatures, humidity, electromagnetic interference, water or dust ingress, and vibrations all contribute to shortening the life of the equipment and falsifying sensor readings. Power consumption is also a huge concern, and not just for battery-operated devices. Higher consumption results in more heat, which requires a beefier cooling system which, in turn, is an additional cost and point of failure. Finally, since edge computing applications are inherently distributed, they are completely dependent on the network. You must assume the network will be unstable and unreliable and design the solution accordingly.

Another important consideration is that edge computing bridges the world of information technology (IT) and operational technology (OT). The latter provides the components of industrial control systems used to operate factories, pipelines, water distribution systems, and wind farms, for example. In other words, OT is part of the technology universe where Programmable Logic Controllers (PLCs) and Supervisory Control and Data Acquisition Systems (SCADA) reign supreme. IT and OT embody two different approaches to computing. IT relies on off-the-shelf components that are replaceable and updated frequently. A three-year lifecycle for laptops is common in many organizations. On the other hand, OT is about purpose-built solutions controlling critical infrastructure, which means updates are infrequent. Thus, one could say that, for many organizations, IT is a service to the business, while OT is the business itself.

Not all edge-native applications target OT use cases. But since they may exist outside of the cloud and the corporate data center, they are exposed to many of the dangers OT applications must face and must fulfill many of the same requirements. This requires a change of mindset from developers.

Defining edge-native

We now have a solid understanding of the edge environment and the characteristics of edge-native applications. Now is the time to answer the question in this article's title: What is an edge-native application?

My answer to this question goes like this:

A distributed application made of virtualized or containerized microservices that are deployed outside the cloud and the corporate data center. Edge-native applications are optimized for field use, resilient, adapted to mobility, orchestrated and leverage zero trust and zero touch operational models.

This definition implies that it is not enough to have distributed nodes processing data locally to have an edge-native application. Such applications, after all, are built from the ground up for the edge using a specific approach. Think about it: Is any random transactional website a cloud-native application? Of course not.

Optimized for field use

Because they often run on constrained hardware, edge-native applications are optimized for size and power consumption. There is little to no elasticity at the edge, meaning you must manage resources carefully, especially considering the longer lifespan expected from the solution. You could be tempted to future-proof your edge nodes by providing them with additional compute power, memory, and storage. However, this is not cost-effective and, in any case, will probably not be viable over the long term.

Resilient

Edge-native applications possess great resiliency, given their distributed nature. They assume that nodes, services, and even the network may fail anytime. They manage such outages as seamlessly as possible by buffering outbound transactions and data for later. Nodes near a failed system should be able to take over, although with reduced quality of service.

Adapted to mobility

Edge-native applications can connect to mobile networks and be deployed on nodes onboard vehicles. They are location-aware, meaning they can dynamically take advantage of services available in the local environment. They can also adapt their behavior according to local regulations and requirements. Moreover, they can leverage location-based routing when needed. This enables them to pick the most cost-effective option to transmit data and receive commands.

Orchestrated

The components of edge-native applications may be deployed inside containers, but virtual machines, serverless functions, and binaries also play a role. The lifecycle of all these deployment artifacts must be carefully orchestrated to scale up or down certain services or to stage incremental updates. Naturally, this reliance on orchestration makes the whole application more resilient since additional service instances can be spun up to face adverse conditions or operational challenges.

Zero trust

The zero trust model implies that, by default, no device is trusted. Every device and node is seen as a potential attack vector. The zero trust model involves systematic device authentication and authorization, with limitations on the scope and timeframe of the access granted. In addition, data must be encrypted in motion and at rest.

Zero touch

Edge-native applications require credentials for authentication, authorization, and even device attestation. The latter involves using certificates or similar means to prove a device's unique identity and trustworthiness. Zero touch onboarding means that such credentials are deployed automatically from a central location as soon as a device connects to the network. Manual manipulations are error-prone and potential attack vectors, so eliminating them is an important priority.

Wrap up

If you are a cloud-native developer, I hope you now realize how the edge computing space differs from what you are familiar with. These differences should not prevent you from jumping in, however. The languages and techniques you know are certainly applicable at the edge. With the right mindset and a willingness to learn, you can become a productive edge-native developer.

If you are looking for a community of experienced edge-native developers to strike up a conversation with, join the Edge Native working group at the Eclipse Foundation.