More things are being pushed to the edge. Think of the edge as the space between the cloud and whatever device or system is tossing off data.
The idea is to do most of the processing at the edge, close to where the data is produced. This approach, called edge computing, provides a much better response time, because there’s no need to send the data back to a central cloud-based data-storage system where it’s processed and then returned all the way back to the device.
Edge computing is very useful. Which is why most enterprises are sold on the concept. I’m seeing interest in edge computing move from proofs of concepts to production. However, it’s not a substitute for a good architectural approach and old-fashioned pragmatism. Which is why I’m also seeing huge mistakes being made—mistakes that are avoidable. Here are two common mistakes to avoid.
Edge mistake No. 1: Doing too much at the edge
Most edge platforms are embedded platforms, small, and all SSD-based. Examples include the Arduino platform and Raspberry Pi, but I’ve seen some pretty hefty platforms used as well, such as those based on hyperconverged infrastructure.
The rule of thumb is to keep it small, cheap, and easy to replicate. The companies that put too much processing on those edge devices soon find that the latency and speed issues that they are looking to solve with edge computing come back in a new form and, in most cases, make things worse.
The edge device should be purpose-built and only do the minimum of what’s needed to collect, process, and transmit data, as well as respond to some issues that need immediate attention. For example, an edge device can host telemetry data coming from a truck engine and report any obvious issues directly to the engine’s computer and the driver, such as overheating by a temperature parameter being out of range. However, the edge not a good location for predictive analytics to determine potential emerging problems with the engine—potential problems whose identification means cullibng through petabytes of data.
Also, if you design all edge computers to be functionally the same, automated tasks are easily replicated. If you customize, or take too much of a DIY approach, you’re not doing yourself any favors.
Edge mistake No. 2: Neglecting security at the edge
Security for edge computing is often an afterthought, even though the consequences are worse than neglecting security in the cloud.
Consider the truck example. What if someone hacked into the edge device and generated erroneous data that could cause the engine to shut down, or the driver to make wrong decisions? Such isolated devices are great targets because of their separation from core systems, where you might have ways to detect attacks.
Sadly, the need to address potential security threats with greater consequences is not first on the to-do list for most edge architects.
To address the security issues, you need to replicate most of the cloud services that you use at the edge. Most public cloud providers have already figured this out, so their edge platform offerings now extend security and ops services down to the edge computer that’s not in the cloud.
The idea is to automate as much as you can, and ensure that things are automatically taken care of, such as updates for known new threat vectors and OS upgrades.
