Before We Use Kubernetes to Develop Edge, We Should Define It

Edge isn’t just something found in trolly Internet threads, but an entire spectrum of computing that can best be defined as “Computing not done in your traditional data center.” However, this definition is flippant and also fails to cover the true breadth and depth of edge computing, as it can be defined differently by almost every business, industry, and IT team. This is because edge computing is a relative term, meaning everything from one lock-and-key facility, Amazon's, Google's, Microsoft's or IBM’s clouds, or dozens of small datacenters surrounded by IoT devices.

You may also enjoy:  An Introduction to Edge Computing

Because of these varying associations, the term “edge computing” should first be defined by one standard to which it is relative. Once defined, the problem area quickly becomes complicated and tangled, as infrastructure and application layers suss themselves out.

Defining “Edge”

That distinction is important. Infrastructure at the edge is more properly exemplified by Kubernetes running on smaller clusters, which might be managing and monitoring IoT devices. Meanwhile, application computing at the edge is likely to include some type of actual workload being performed on those edge machines: AI/ML, data processing, or event logging, for example.

Edge computing allows enterprises to bring their applications closer to the data that is being generated or processed. Sensors that take in data can also normalize the data before it even enters transit. In an infrastructure-focused example, devices can be sent to the field and plugged in by non-skilled workers when the company network is capable of recognizing new devices and automatically provisioning them.

The promise of edge is often less work for the core processing systems and personnel inside an enterprise. But that does not mean such a system is easy to setup. Edge computing requires the coordination of many layers of technology, often working in a distributed fashion across multiple geographic locations.

Common Requirements for Systems Before Getting Edgy

While each edge case is different, there are some common requirements for such systems that must be understood before they can be built out. These considerations include:

• System management: Primary among these is some sort of provisioning, management, and monitoring system. Red Hat is quite partial to Kubernetes for this use case, naturally.
• Infrastructure: Just spreading jobs out to an edge network requires a large amount of infrastructure.
• Security: Security must be of paramount importance, which also insinuates the need for roles, identity, location, and configuration management across all systems. For some users, this need for security can even extend to the edge devices themselves: systems must be able to detect when actual devices in the field have been tampered with, lest they become vectors for infiltration back into the network.
• Architecture: And those devices themselves add an even further layer of complications to the architecture: how do you get a Linux container up and running on a security camera, an antenna, or a drone? There is no easy solution, and thus, almost all edge compute scenarios will require a wide ecosystem of partners working together. There will be no end-to-end edge solution simply because there is no typical end-to-end edge architecture. Almost every scenario will be different.

There will be some commonalities, patterns, and best practices. One of those commonalities will be the rollout of 5G, which can provide even greater access to end-user devices to perform such edge processing functions. And there can also be many new cell antennae to be deployed and provisioned.

Further Reading

Demystifying Edge vs. Cloud Computing

Why Is Edge Computing Gaining Popularity Today?