5W – Edge Computing

Thank you for reading! Please see “Why 5W?”  for context, methodology and disclaimers.

Edge Computing Overview

Edge Computing (EC) is a distributed computing paradigm where highly-scalable and efficient computing resources are made available closer (physically or through optimized network enhancements) to an end user, providing a superior application experience. EC offloads processing that would otherwise make round trips to a primary datacenter / cloud resource, thereby reducing latency and improving application / workload performance. Applications that can benefit from Edge Computing include mobile, web or thick client (locally installed on workstation).

The concept of ‘edge’ (in earlier days was known as ‘content delivery network‘ (CDN) as early as the 1990s. Companies like Akamai recognized a business model in providing improved end-user performance by serving static binary assets (images, videos and files) from geographically-dispersed data centers, closer to the end user than the central data center. Content and website owners uploaded large (videos, binary / file-based content) and a plethora of smaller, oft-used images (icons and web page graphics) to these servers to help the end-user avoid the latency of downloading these assets from central servers. Before the cloud, these servers were originally positioned in major data centers in the cardinal regions (AM, APAC, EMEA), but soon expanded into even more geographically-dispersed edge sites to improve end-user performance.

As you may surmise, companies who deployed assets on CDNs demanded policy-based content management (availability, expiry, etc.), unified upload / addressing for application access and consumption (storage, bandwidth) cost optimization from the CDN vendors. The winners in this early space sorted this through lookups, automation and dynamic addressing, methods deployed to this day.

Also to be expected, functional capability requirements evolved well beyond managing static content to include distributed interim storage, processing and expanded integration capabilities to third-party systems from the decentralized site, hence EC emerged. Early EC implementations were IoT-focused, especially for location-bound services that required increased computing performance to manage the output from sensors, machines and other monitorable / controllable assets.

The EC use case landscape is quite broad. Early deployments supported near-line collection and processing, enhancing data collected from IoT devices. These data were aggregated and correlated to provide a broader picture of the captured data. Next-stage deployments required highly-customized efforts by offering owners (i.e., a lot of code) to integrate these data. As with other emerging technologies, vendors stepped into the gap, providing platforms that reduce the level of effort (and code) enabling offering owners to engage in the new paradigm. Please see some of these in ‘Technology Providers’, below.

EC can be part of, and benefit from, a robust SD-WAN implementation, where devices, on-premises assets and cloud resource connections are managed and optimized centrally through policy. Most importantly, the benefits of an Edge Computing implementation can be measured by improved end-user / customer experience (CXM).

Edge Computing Business Benefits

Before modern browser-based and mobile-enabled capabilities, many applications were delivered to users in a client-server model, leveraging fast bandwidth and the computing capabilities of a local PC to do last-moment processing, dynamic presentation (sorting, graphics generation, etc.), in addition to relying on local temporary storage.

These applications were typically deployed in on-premises environments and connected to the central application server via a Local Area Network (LAN). Application developers / product owners relied on local PC capabilities to enhance the end-user experience for improved data navigation and management. When applications moved to browser-based implementation (with no access to local system resources), extended to mobile devices (multiple operating systems, introducing separate mobile-only code lines) or engaged with ‘dumb’ devices (devices lacking local processing, like sensors or cameras) the need for data aggregation and processing shifted back to the server. This introduced latency as entire data sets had to be transported over a slower connection for heretofore simple operations like sorting or graphics manipulation. As you may surmise, user experience suffered and bandwidth costs increased.

EC enables many of the same types of user experience enhancements through pre-processing content to thin-client implementations (web browsers, mobile devices, thin PCs and embedded endpoints), all without the need to write native client software for each of these devices. EC processing enhancements and close proximity avoid round trips to the central application server, leveraging capacity much closer to the end user, reducing latency and improving functionality. Further, EC enables call-outs to external services without the need to route them through the central application server, enabling application owners to leverage external services far more efficiently.

An EC DIY effort isn’t as easy or as seamless as an organization might hope. Establishing an edge infrastructure is beyond the typical product organization as it requires securing computing capacity close to your end users. Modern cloud vendors have enabled this capability by offering remote capacity in a pay-as-you-go model (please see ‘Technology Providers’, below). The short bit: aligning with an Edge provider with a platform is a far safer path.

Companies with existing applications encountered challenges getting to the edge as well, as, in short, many older applications were built with a single source server in mind. Companies discovered that off-loading tasks to remote computing capacity required refactoring application code or extra infrastructure into the new paradigm. While significant value can be achieved from this effort, companies had to balance the value against the investment. Again, modern cloud vendors and direct-to-edge platforms streamlined prompting application owners to review their existing applications to make them more edge-friendly / cloud-native applications.

EC is still early enough that many clear standards and verified strategies have yet to emerge. At a high level, there are some (emergent and hyper-simplified) EC offering methodologies:

• Edge Capacity: IaaS-like computing resources enhanced with the means to perform automated deployments. Code must be written to be deployed across central and Edge servers, as with a distributed application.
• Edge Platform: A PaaS-like platform that reduces manual deployments and code refactoring by enabling developers to ‘write to the platform’. This makes deployments simpler, but requires developers to refactor their code to Edge-Native standards.
• Microservices: This option typically requires a significant re-write of application code, including provisioning services that enable standardized access to back-end resources. This is not for the faint of heart, nor those who do not have access to significantly-capable technical resources within their organization.

The first enables lift-and-shift code deployments, but at the cost of increased, remote management efforts. The second provides a far more robust and scalable implementation, but potentially creates vendor lock-in for the end customer. The third requires a code rewrite, all the way from the UI to the backend services. Note that in practice, an implementation may include any of these three, all combined into the final product.

As of this writing, there is a notable lack of codified EC standards and practices, with companies deploying workarounds to accommodate dated application standards and ‘not-quite-right’ edge toolsets. EC concepts are solid .. expect other paradigms to emerge as EC matures. The larger technology companies are the most mature, most notably, Akamai, IBM and Amazon.

Edge Computing Capabilities

The EC Platform paradigm solves significant application operability and performance use cases by enabling offering owners to get computing power closer to the end user. This is especially important when aiming to provide a thick-client user experience to cloud-hosted applications or aggregate and process data from thousands of IoT devices. While EC deployments will reduce latency, they will introduce levels of complexity in application design. As yet early, capable EC offerings may include:

• EC as a Service: the edge platform is offered via provider-owned and operated assets, requiring little to no edge infrastructure on the part of the customer. This can be IaaS or PaaS. If the latter, will likely have one or more software platform components to which the application owner must comply.
• Hardware Abstraction and Vendor-Independent Architectures: enables ‘Write Once / Deploy Broadly’ capabilities for developers to write code to a platform that can be deployed through automation, governed by policy.
• Cloud Independence: EC intermediary systems can provide an abstraction layer to work with multiple clouds simultaneously or switch between clouds if  business needs / opportunities warrant.

Given the diversity of platforms and to-be-defined Edge standards, ISVs and SIs are filling the gap more so than Enterprises .. in short, organizations don’t really want to ‘roll their own’. This will shift as Edge-Native development paradigms become the norm for various application patterns. Open-Source platforms are clearly ahead of Edge development, albeit in a less-cohesive fashion. At the least, Edge-interested companies can cobble together an implementation from an impressive set of tools that will reduce their overall code and deployment challenges.

When defining EC capabilities, certain realities will come into play that will drive vendor selection and application considerations for organizations. In no particular order, these may include:

• n-layer / n-tier, rather than flat, application architectures will lend themselves well to EC, especially if some of the layers / tiers are already defined as services-oriented implementations.
• Services-oriented architectures (alluded to, above) enable broad application distribution, whereby services can be located and referenced to avoid duplication of code, capacity and effort.
• Microservices architectures with policy-based deployment and connectivity models.
• Configurable Process Orchestration.
• Dynamic workload placement agility.
• Aggregation and processing layers placed closer to data collection assets creating simplified inline real-time feedback to local monitoring assets.
• Centralized processing tiers aggregating content for historical reporting.
• Always-available connectivity, including 5G networks to ensure data can flow between tiers.

EC makes it possible to collect, process, augment and deliver data and content to end users. Besides improved user experience, EC enables thousands of real-time use cases that were simply infeasible before. Please see Use Cases below for examples of use cases that can benefit from EC.

Edge Computing Use Cases

EC lends itself to a wide variety of use cases, typically described as stories when engaging prospects. A few described below for reference.

Mapping and Directions:

• An end user makes a request from a mapping application to obtain directions to their destination.
• The request is authenticated by the main site, providing a processing token and redirection to the nearest edge site.
• The token validates the request between the user device and the edge site and allows access.
• The edge site processes the request independently, adding additional (and hyper-local) ephemeral assets like maps, weather, specific driving directions and more, sending the response to the mobile device.
• The edge site performs lazy updates to the main site to update user history while the trip is in progress.
• The end user receives the directions from the edge site, monitoring their progress locally via their mobile device.
• While navigating, the mobile application updates the edge site and receives localized updates on traffic, weather or other local travel factors.
• The user arrives at their destination and the edge site lazy updates user history on the main site.

To summarize: the main site offloaded parts of the services delivery to the edge site based on user location. The edge site performed localized outreach to manage changing conditions, informing the end user. The edge site updated the main site in the background during, finalizing user history at the end of the trip.

Image Acquisition / Manipulation  for Social Media upload:

• An end user snaps a picture on their mobile device with the intent to upload it to their favorite social media site.
• The request is authenticated by the main site, providing a token and redirection to the nearest edge site. The token validates the request between the user device and the edge site and allows access.
• The mobile device opens the raw image file in the social media application, which is uploaded to the edge site. The main site is notified of the activity in the background, however the raw image is not uploaded to the main site just yet.
• The user edits the image in the social media application (cropping, filters, enhancements, etc.). The mobile application prepares to send the delta of these changes (not the image file itself) to the edge site.
• The user confirms their changes and when satisfied, commits them on the mobile device.
• The edge site dynamically allocates computing capacity to manipulate the image to user specifications.
• The edge site uses computing capacity to finalize the image, notifying the user when complete.
• The edge site lazy writes the final version to the central server for permanent storage.

The main site offloaded processor-intensive image manipulation tasks to the edge site. Note the image was only uploaded once, and only to the edge site. Only after the end user approved changes did the final optimized image be uploaded to the main site for permanent storage.

Other use cases can be discussed:

• Location-based Interactive Gaming like Ingress and Pokemon Go.
• TMS: Vehicle Monitoring and Management through processing telematics. 5G enablement opportunity.
• Manufacturing: ‘Smarter’ Sensors for Monitoring and Management.
• “Smart Buildings” Monitoring and Management through embedded systems.

EC use cases number in the thousands. No customer buys ‘Edge Computing’ by itself .. they will have at least one (and likely several) use case goals in mind. It is the seller / SME task to understand the target use case proposals to the point where we can suggest appropriate solutions from our client offerings. Note that while adopting a platform can satisfy a priority use case, the same platform can be used for additional use cases to achieve more ROI from an end-customer investment.

Edge Computing Providers

As use cases vary far and wide, these are all ‘some assembly required’ .. where these companies provide the hardware and / or software platforms requiring connecting and orchestrating systems and services. It is highly unlikely widely-accepted standards will emerge across all platforms. 

ED: As Article Publish dates are frozen in time, it is quite possible reviewed vendors and their capabilities may have advanced beyond those presented herein. Please accept my apologies for my shortcomings. A note to vendors: please reach out to advise your current offering capabilities and I will update.

Edge Computing Audiences

Most IT audiences will recognize Edge by name .. but all will have different definitions and a wide variety of understanding and expectations for Edge use in their organization. Ditto for Executive audiences. The majority of these audiences will need to be engaged through education on the performance and cost savings aspects of EC, tailored to their role in an organization. IT can be engaged through potential cost savings where an offering can be decentralized, shifting processing to remote locations, saving processing and bandwidth.

Surprisingly, Product Owners (POs), who are typically hungry for new features to improve their products are not seen as primary audiences for EC as of yet .. the PO audience must also be educated, relying on ‘what if’ scenarios and stories that will improve their offering. Given virtually infinite use cases, engaging POs through discovery is an important part of an engagement. A seller can approach prospective POs by describing the value of EC to add new features and enhance performance to end-customer audiences. This will require sellers to take a close look at the company offering, understanding the use cases the offering enables and extrapolating offering enhancements they can present to the PO. Not all ideas will land with POs .. this engagement will require thick-skinned ‘idea hamsters‘ working with outreach agents to ensure a credible impression in an initial contact.

EC is not a technical sale at the outset. It is creative and educational, relying on sellers identifying, researching and offering use cases that align to prospect roles within the target organization.

A company should consider EC for:

• Adding new features to their offering that can be optimized via the end-user location.
• Enhancing the performance of their offering.
• Cost savings through application optimization (smaller centralized footprint, reduced bandwidth, etc.).
• Improving end-customer experience with new features and better performance.
• Localizing customer experiences.

A seller needs the ability to recognize, expand and document end-customer use cases / need states that enable them to secure a solid prospect.

An EC sale will cross multiple audiences, engaging PO, IT, Operations, Developers and Executive audiences.

Conclusion

Edge Computing is a storytelling campaign. It may not begin with a prospect who has an enhancement story already in mind. As noted above, no company will buy ‘edge’ .. they will consider new features, better customer experience, faster performance, application stability, cost savings and so on. Edge Computing is a paradigm shift .. engagements will involve several technical and business audiences, as well as reaching from developer audiences to the executive suite of an organization. Product Owners and Developers will present as useful influencers, but the ultimate decisions must be recognized across the organization.