Edge Use Cases Must Start with the Business

Technology “hype” sometimes serves as a justification for companies that are afraid to be left behind by their peers. We saw this with cloud infrastructure, as countless companies shifted from data centers to the cloud without well-defined use cases. Many were ultimately disappointed that they were paying more without any real benefits. Likewise, organizations that race to transition to edge computing and networking could face similar fates.

The only way to validate a potential move to the edge is to start with the business. Technology should facilitate, rather than justify, the strategy you define. How do you know if your use case merits the edge? There are a few high-level questions worth asking, and you should only make the move if the answer to all of them is “yes.” Once you’ve justified the move, there are a few critical steps for making the transition to edge a reality.

Four Questions to Assess Your Fit for the Edge

1. Is your policy centrally managed? Unlike both traditional data centers and the cloud, edge decouples policy creation and execution. As a result, it aligns well with use cases for which a central authority determines policy and then sends it to multiple edge sites that each execute that policy in a unique, context-driven way. For example, many fast-food restaurant chains operate on this model, where the central authority is the corporation, and each edge is an individual franchise. If policy is not centrally managed, then the effort required to prepare and operate at each edge location outweighs any potential benefits.

2. Is your use case fully remote and autonomous? A valid edge use case requires operations at the edge to continue even when no connection to central infrastructure is active. You will not derive substantial benefit from the edge if you need to move data centrally to store, process, and make decisions for the edge. Notably, while this means the edge is an excellent fit for many manufacturing scenarios, it also disqualifies some use cases that might initially seem like logical cases to implement edge technology. These include retail chains with no flexibility in implementing centrally dictated protocols and mobile apps that rely on centrally located servers.

3. Does your use case apply to the same edge in each instance? The benefits of the edge depend on central infrastructure only needing to issue one set of instructions across the edge. However, suppose each edge is distinct and requires a new set of instructions. In that case, there is no efficiency improvement tied to moving to the edge, as needing to instruct each edge separately is prohibitively time-consuming.

4. Are your data streaming and backhaul costs tied to your data lake? Are you incurring data streaming and backhaul costs at your data lake or the edge? If the costs are tied to shifting the data away from the edge, then moving processes to the edge can help significantly lower costs. If backhaul costs are not a significant concern, this may limit the value you derive from the use case.

How to Get Started on the Edge

Once you’ve established that your use case fits the edge, you should prioritize overcoming a few significant logistical challenges. These include convincing key stakeholders that moving to the edge is worthwhile, ensuring your company can troubleshoot effectively on the edge, and preparing your network to support a distributed footprint.

When beginning the conversation around the edge with critical stakeholders, frame the move as a natural evolution of your company’s long-term digital transformation. The same argument played a key role in the move to the cloud, where it was framed as a natural extension of the data center that turned CapEx investment into OpEx investment. Now with the edge, you are expanding where your compute can live, but it is still your compute, and it will live in footprints you already occupy.

Review how your company’s communications support the edge. If something goes wrong on the edge, who learns about it, and who fixes it? If you need to backhaul IT support from a central location, you must empower IT to handle the issue as efficiently as possible. They don’t need to know every device’s analytics, just the ones that are not working. Finding ways to zero in on the data you need improves efficiency while reducing backhaul costs.

In terms of preparing your network for the edge, there are three layers that you need to review for readiness. The first is the exposure layer, which determines how people connect to the network (i.e., DNS). The second layer is the technologies that connect the various infrastructure components (such as VPNs and Anycast). The third layer, which often gets overlooked, is a central source of inventory for your infrastructure. Even if you create excellent policies, they will not be effective if your understanding of your network is inaccurate.

Even if the edge doesn’t fit with every use case, it is a worthwhile transition for many companies. When you have an answer for why you’re moving to the edge, along with a solid plan, it can benefit both the company and users alike by significantly reducing backhaul costs, streamlining the logistics of implementing a centrally defined policy at each edge location, and providing a faster and more reliable user experience.