Defining Edge Architecture
Senior Data Centre Consultant, Steve Bowes-Phipps, takes us through his definition of Edge Architecture and clears up the myth around its relationship with 5G.
Visiting a recent conference in Amsterdam, I couldn’t help but feel “Edge” was a little misunderstood. While many people acknowledged that “The Edge does not need 5G but 5G needs the Edge”, they then went on to describe the architecture and business model for 5G. I couldn’t see why this should be the case, and made me wonder, is more technical input needed?
I agreed with Farid Singh’s (Founder of Take 3 Innovative Consultancy) presentation which focused on content delivery networks and why architecting 5G into the Edge must be done with care. However, for me, Edge is not just about content delivery, nor is it directly related to 5G (which has its own business case and needs to demonstrate value). The Edge is about, first and foremost, handling data close to the point of delivery or capture, which sets it apart from the large colocation facilities and hyperscale Data Centres that traditionally make up the industry.
Let’s first take the content delivery network (CDN) aspect. Edge Data Centres will deliver large volumes of data with low latency, to enable the scaling up of large content delivery business models, the most well-known of these being the streaming services of Netflix, Now TV, Amazon Prime, BBC iPlayer, etc.
The other Edge paradigm is for the Internet of Things (IoT). Data collected from a multiplicity of devices, ranging from temperature sensors, fridge freezers to cars and commercial airliners. The data volumes associated with these devices can be vast. It doesn’t make logical or commercial sense to transmit all of this data back to a Data Centre for storing and processing when a large part of it is transient and of little value or use.
My own belief is that many of today’s smaller Data Centres, the type I classify as “Boutique” due to their personal services and specialised utility, will reclassify themselves as “Edge”, if they haven’t already done so. This will be a sensible decision as it allows them to use their location close to urban areas as an advantage compared to large, out-of-town colocation providers. These will serve a useful purpose as Points of Presence (PoPs) for the content providers. In addition to these, there will be the “Data Centre in a Box” (DCB), which will be deployed to telephone exchanges, mobile masts, factories, shopping centres, etc in order to consolidate and process data prior to further upload to the public or private cloud. Indeed, intelligent systems within Edge devices, such as autonomous vehicles, could also be considered as DCBs. DCBs will contain business logic that allows instructions or data refreshes to transmit back to autonomous devices or presented to monitor and control systems for further analysis and assessment.
For me, IoT is the most interesting area that I’ve not yet seen discussed in any great detail with regards to the Edge. There are several questions to be concerned about when considering the characteristics of the IoT device:
What is the criticality of the device/sensor?
a. Is this device one of a redundant set or is it allowed to fail?
b. Reliability is critical? How can you detect failure and what can you do about it?
How complex does it really need to be?
The trade-offs are usually “low-cost and high volume” vs “high-cost and low volume”. Which is most appropriate for the business model?
What is the paradigm for data/information flow?
a. In terms of the network does it work in Fetch, Push or Contextual (if situation, then upload/download data) connectivity?
What levels of redundancy and availability are needed at each layer?
Do they need connectivity back to the ‘home’ Data Centre (cloud?) and/or each other?
The device/sensor network card will need to be reprogrammable or based on international standards to allow local connectivity even when the target object is moving around. Even fridges can move to a new house!
To summarise, there are two types of use cases for Edge. The first being the consumption of content close to the consumer. The second, the device data flows bi-directionally for automation services / live broadcast (low latency vs medium latency vs who cares)
The connectivity needs to be client-agnostic in order to allow for many different types of device/sensor. Most importantly, business cases should identify latency and bandwidth requirements and provide only what is needed.