blog | edge computing

Navigating the Edge ecosystem complexity

About the Author: Vanitha Ramaswami

Vanitha, A Telecommunications professional with more than 20 years of Industry experience from various companies in Singapore including StarHub, Amazon Web Services (AWS), Singtel, and ST Engineering. As a technical consultant to customers & partners I have deep domain & technology expertise in Wireless Communications, Cloud technologies and Connected Product Design. Passionate product designer, continuous learner, problem solver and have strong technical and business acumen. The motivation for her writing is to bridge the knowledge gap among the cross-functional stakeholders and accelerate the edge ecosystem development.

The heterogeneity of the Edge Ecosystem

Telecommunications networks are evolving towards a more disaggregated architecture decoupling the monolithic network infrastructure and allowing more flexible programming of the network. This creates new opportunities with plenty of new locations where data can be processed in the telecom network. This enables a wide range of next-generation applications to evolve, and these apps are following a distributed data processing architecture to have the best performance.

Edge is heterogenous and is a complex ecosystem comprising a diverse set of stakeholders. There are several types of edges as in Figure 1. Due to its multi-disciplinary nature, edge-enabled service development poses an immense challenge to both the service provider and the consumer. Edge solution offerings are available in multiple forms and often it is a tough decision for enterprises on how to get started and integrate edge services into their organizational context (IT and OT systems).

The-edge-continuom_fig01
Figure 1. Edge to cloud continuum Source: The Linux Foundation

Single-vendor or multi-vendor solution for edge services

Multiple stakeholders are trying to simplify the edge 2 cloud solution development. Due to the complexity of edge service development and the multi-disciplinary skillset required to create edge products & services, edge solutions are often released in the form of accelerators, from a single vendor or multiple vendors.
In this post, I would like to provide some perspective on single-vendor and multi-vendor solutions for edge services.

Edge 2 cloud system accelerators

These accelerators are available in multiple forms from edge 2 cloud as a single package and are offered by public cloud providers. These accelerators are available for various types of edges (Near edge a.k.a. Network Edge, Far edge a.k.a Enterprise edge, etc.). The basic unit of these accelerators are the different independent services (e.g., compute, storage, database, networking, analytics, AI/ML, etc.,) and is also assembled as a Full stack solution (pre-integrated package from a single vendor).

In this post, I will compare two network edge accelerators:

i. Single Vendor network edge platform – Azure Operator for Nexus
ii. Multi-Vendor edge platform –
Offered by many ISV (Independent Software Vendors)

Platform business models are typically multi-sided engagements. E.g., In the network edge platform scenario on the service provider side, we have the MNO (e.g., Tier 1/2 operator), and on the consumer side, we have the Enterprise customer.

Azure for Operators is a single-vendor network edge platform service that is launched by public cloud providers with their MNO partners.
In the multi-vendor ecosystem, equivalent network edge platform services are offered by multiple ISV (Independent Software Vendors).

fig02

Figure 2. Network edge platform – simplified view

As illustrated in Figure 2 multiple stakeholders are required to realize this architecture from the edge 2 cloud. The pre-integration can be viewed as an accelerator as well as a constraint. To the service provider/MNO, it might seem to reduce the time to deploy the compute, storage, and network infrastructure. However, the pre-integration has less impact on edge-enabled solution development as it involves a different set of stakeholders (solution providers, enterprise customers, and network function providers).

MNO is a neutral stakeholder in the edge ecosystem and has a need to serve enterprise customers requesting multi-cloud connectivity. The single-vendor solution introduces additional complexities and overheads for both the MNO and the Enterprise customers who are developing solutions or buying solutions for the edge.

The below table (Table 1) provides a comparison of the single-vendor network edge platform stack vs the multi-vendor stack.

From a software architecture perspective

Next-generation applications must process the data closer to the data source to gain real-time insights and perform actions. These apps need to follow a distributed data processing architecture to be successful.

From a solution designer perspective

There are plenty of ways to realize this architecture and scale the implementation. The key requirement to develop next-generation applications that take advantage of these network capabilities is the infrastructure must provide agility and flexibility from edge to cloud and support for modern development tools. Analytics and AI/ML could be integrated in edge solutions in multiple forms.

From an Enterprise customer perspective

To simplify things, I have split the edge 2 cloud solution primitives into three layers:

R Edge Hardware or Edge Infrastructure – compute, storage, networking, and accelerators
R Edge Software and Platforms – Deploy, and manage applications, and network functions across multiple domains (From edge 2 cloud).
R Edge-enabled Solutions – Leverages a distributed architecture paradigm. Solutions can be developed as a point/be-spoke solution or as platform services for various vertical industries.

Comparing single-vendor and multi-vendor edge platform stack

The key differentiation of the Full-stack network edge platform from the single vendor is the pre-integrated networking and the management with the respective public cloud services. The single vendor constraint gets propagated from the infrastructure layer all the way up to the solution layer, creating vendor lock-in and hampering the progress of the edge solution development.

This creates friction and adds additional overhead for the Enterprise customers consuming these services. For example, a full-stack single-vendor solution is difficult to integrate into an Enterprise customer environment. Even if an edge-enabled solution exists, the organizational structure and technical capabilities of the Enterprise make such a solution difficult to consume.

The Enterprise customer needs to acquire new technical skills, from the infrastructure layer up to the solution layer, which increases the solution deployment time and scaling of the solution.

However, some tooling is now emerging as a de facto standard and is also used by public cloud providers as indicated in Table 1.

fig04

Table 1. Single vendor Vs Multi-vendor stack – Tooling comparison

Every Enterprise is unique and will have its own operational processes and tools. i.e., teams could have been organized as Infrastructure operations (to manage compute, and storage), Network Operations, Security Operations, DevOps, DevSecOps, etc.

The edge ecosystem is evolving so rapidly, and the multi-vendor network edge tooling is now matured, enabling cloud-native infrastructure and security automation available in the form of edge orchestration platforms (vendor supported). This is offered by many 3rd party independent software vendors (ISV) or private cloud providers [Figure 3].

Figure 3. Single Vendor Full Stack Network Edge Platform vs Multi Vendor Edge Platform

Avoiding full stack dependency

The single vendor full stack solutions reduce the Total Addressable Market segment for the edge solution providers if purpose-built cloud services are used in edge solution development.

While every stakeholder in the edge value chain is trying to pre-integrate the capabilities to lower the barrier to entry, the benefits are not clear. In the case of the full-stack network edge platform, the pre-integration adds additional overhead. A wide array of new technologies need to be learned both by the MNO and the enterprise customer. However, with the plethora of low code platforms & tools available to develop edge applications that are pre-integrated with analytics and AI/ML capabilities, edge-enabled solutions could be developed using microservices architecture, Kubernetes based deployment for high availability, scalability in a modular manner avoiding vendor lock-in. The dependency on the full stack could be avoided, providing greater flexibility and accelerating the edge ecosystem development.

Designing for the needs of the Enterprise customer

Edge is heterogenous and the accelerators need to be designed with loose coupling and open standards to easily fit into enterprise environments. For digital transformation initiatives, Enterprises will need to develop or procure solutions and/or platforms. If it is a single-vendor full-stack edge 2 cloud solution, pre-integrated with a vertical solution, enterprises need to learn a new networking stack and management tools to operate the edge-enabled solution. In a multi-vendor solution, the Enterprise shall be able to reuse some of its existing systems, tools, skillsets, and processes. The benefits and the trade-off of the pre-integrated compute, storage, and networking with the edge solutions need to be analyzed from both perspectives (provider and consumer).

To provide a high degree of autonomy for innovation to all stakeholders in the ecosystem, the edge 2 cloud solution architecture should be made modular adopting more open standards.

Networking need not be pre-integrated with solutions so that the network operations team can run autonomously.

DevOps, Analytics, and AI/ML tools have matured, and several multi-vendor solutions are available to manage the edge 2 cloud solution development complexity. For enterprises without in-house AI/ML capabilities adopting a low code Al/ML platform shall help to accelerate as opposed to learning a proprietary service offering (Reduce Time to acquire new skills).

Security operations and infrastructure management tools need not be a single-vendor stack to avoid vendor lock-in.

Having a data management strategy to integrate organizational data silos with the right choice of AI/ML tools helps to progressively evolve in the digital transformation journey.

To navigate the edge 2 cloud ecosystem complexity: R Solution providers need to adopt open standards to help develop an open-edge ecosystem with standardized interfaces to reduce the value chain complexity. R Edge device makers need to decouple device management from data management. Edge data management needs to be tailored to various Enterprise contexts and vertical needs. R Enterprise customers need to analyze the Enterprise IT/OT landscape and assess whether these edge 2 cloud accelerators fit into the organizational context.

For MNOs without too many in-house development resources, the multi-vendor network edge platform lowers the barrier to entry with the solution offering that is vendor supported as opposed to a public cloud network edge platform that requires much higher investment and many more new skills to be acquired. Edge has a huge potential to transform several industries and edge-enabled solutions are rapidly evolving as the MNO edge infrastructure is being built. The MNO edge platform (network edge, enterprise edge) is critical to the success of the next-generation edge apps to reach the mass market. I hope you gained some information on the tradeoff between a single vendor/full stack vs multi-vendor edge platforms.

Share This