Well, it is wherever an entity defines it.
There are so many: provider edge, enterprise edge, edge computing, cloud edge, edge cloud, distributed cloud edge, near edge, far edge, to mention a few, that edge is now a marketing term applied to anything and everything.
So, let’s try to clarify this situation from Alef’s perspective. From a Time required to send data over two points in a network. point, there are two types of operating systems, real time OS (RTOS, e.g., VxWorks) and operating system (OS, e.g., Windows, Unix, Linux). Depending on the application requirements, one of the operating systems was chosen for app development. Any time sensitive app was written using RTOS, e.g., network switches, routers, radio equipment, manufacturing robots, manufacturing controllers, healthcare devices, any SW that had to control a physical device with very predictable latency to the action.
Everything else was written on other types of OSs. As enterprises took the approach of one app per server (mainly for performance and security reasons), it became very expensive, from a CAPEX and OPEX point of view. The applications weren’t running 100% of the time and the HW was quite a bit underutilized.
VMWare came along to solve the problem by porting the hypervisor architecture on Intel x86 (the original hypervisor was created by IBM in the 60s and productized in 1972 for IBM 370 mainframe) that enabled running multiple instances of OS with a single application on a single HW unit. VxWorks was still the king of low and predictable latency applications.
A few years later Amazon created AWS to solve their HW underutilization problem and started selling compute as a service and cloud was born and took the computing world slowly, but surely over.
During this period VxWorks was still the king of RTOS, but there were more and more problems starting to come out, such as how to integrate more computing power into devices, how to conduct more data collection and real time analytics, and towards improving manufacturing efficiencies and productivity. The manufacturing sector was looking for a solution for the lack of compute power and everyone looked to the cloud, because it offers a lot of cheap compute power, but it has a draw-back. It doesn’t guarantee latency, so there is no predictable/real time process control that app developers need that RTOS provides.
There is a trade off
The closer to the manufacturing/warehousing/healthcare site the cloud is coming, there is less and less power, space and cooling available for compute. Latency then becomes more predictable and more in real time.
The further from the manufacturing/warehousing/healthcare site the cloud is, there is more and more power, space and cooling available for compute. Latency then becomes less predictable and in less real time.
Different applications have different latency/predictability requirements, so not all of them have the same requirements for the Edge. Here are the categories:
- Hard – missing a deadline is a total system failure. A lot of embedded SW with edge computing supporting the embedded systems, <5ms latency.
- Firm – infrequent deadline misses are tolerable but may degrade the system’s quality of service. The usefulness of a result is zero after its deadline. A healthy mix of edge computing and embedded SW, in a few years I see 60/40, 70/30 ratio between edge and embedded SW, under <50ms latency.
- Soft – the usefulness of a result degrades after its deadline, thereby degrading the system’s quality of service. A healthy mix of edge and embedded SW, in a few years, but going the opposite way from Firm category, <100ms latency.
With mobility being added to the requirements, it becomes a harder problem to solve, but we have all the ingredients to solve it.
As long as it meets the application requirements, the Edge can be on customer premises, within 1ms, 10ms, 500ms, or 5s latency.
We have now made a full circle and came to almost the same statement as at the beginning:
The Edge is wherever the applications need it to be.