Skip to main content
Monthly Archives

January 2022

Cloud Services at the Edge

By Blog

This post first published on the IBM blog at this link; it has been reposted here with permission. Some content has been redacted so as not to be seen as an endorsement by LF Edge. 

By Ashok Iyengar, Executive Cloud Architect & Gerald Coon, Architect & Dev Leader, IBM Cloud Satellite

Where the enterprise edge ends, where the far edge begins and what, if any, are the various points of intersection?

What do AWS Outpost, Azure Stack, Google Anthos and IBM Cloud Satellite have in common? Each one of them is essentially an extension of their public cloud offering into an enterprise’s on-premises location or edge facility. This is, in fact, the hybrid cloud platform paradigm.

Each vendor has their offering nuances. They even support different hardware for building the on-premises components of a hybrid cloud infrastructure. But the end goal is to combine the compute and storage of public cloud services into an enterprise’s data center — what some might call Enterprise Edge. It is worth pointing out that IBM Cloud Satellite is built on the value of Red Hat OpenShift Container Platform (RHOCP). This blog post will discuss where the enterprise edge ends, where the far edge begins and what, if any, are the various points of intersection.

To reiterate from previous blogs in this series, edge encompasses far edge devices all the way to the public cloud, with enterprise edge and network edge along the way. The various edges (network, enterprise, far edge) are shown on the left side of Figure 1 along with the major components of a platform product that include the cloud region, the tunnel link, a control plane, and different remote Satellite locations:

Figure 1. Different edges and IBM Cloud Satellite components.

 

Note that one would need more than one control plane only. For example, a telco location for the network team and a development location for deploying edge services.

Please make sure to check out all the installments in this series of blog posts on edge computing:

Edge components

As we have mentioned in our other blogs in this series, there are three main components in an edge topology, no matter which edge we are talking about:

  • A central hub that orchestrates and manages edge services deployment.
  • Containerized services or applications that can run on edge devices.
  • Edge nodes or devices where the applications run, and data is generated.

Some edge solutions do not use agents on edge devices, while others like IBM Edge Application Manager require an agent installed on each device. An agent is a small piece of code running on edge nodes or devices to facilitate the deployment and monitoring of applications. Refer to “Architecting at the Edge” for more information.

Which cloud?

In most cases, these platform products that bring public cloud services to an on-premises location work with one cloud provider. AWS Outpost, for example, is a hardware solution only meant to work with AWS. IBM Cloud Satellite, on the other hand, has certain connectivity and resource requirements (CPU/memory) but is agnostic to the hardware. The requirements generally begin at the operating system level (Red Hat) and leave the hardware purchasing to the customer. The Red Hat hosts provided can even be EC2 instances in AWS or other cloud providers. This means IBM Cloud Satellite can bring IBM Cloud services to remote locations as well as services from AWS, Azure, Google Cloud and more that are planned.

[…]

Overlapping or complementary technologies?

We hear the phrase “cloud-out” when describing the compute moving out toward the edge. But what we see from Figure 1 is that the services brought on-premises from the public cloud cannot quite be extended out to the far edge devices. That is where one would require a product like the IBM Edge Application Manager to deploy and manage services at scale.

A common challenge of edge workloads is training the artificial intelligence (AI) and machine learning (ML) models and using predictive model inferencing. An IBM Cloud Satellite location can act as the platform in close proximity where data can be stored and accessed, and AI/ML models can be trained and retrained before they are deployed on to edge devices. Or the apps running on the edge nodes could access a suite of AI/ML services via the Satellite location. Thus, low latency and data sovereignty are two major reasons why enterprises would want to deploy such solutions. Compliance and other security requirements are easier to implement when the cloud object storage or database is physically located on-premises.

It is easy to envision a use case where a retail chain would use a product like AWS Outpost or IBM Cloud Satellite to establish a satellite location in a city. That satellite location could then provide the required cloud-based services to all its stores in that city. These could be a common set of services like AI/ML analytics, access policies, security controls, databases, etc. — providing consistency across all environments. Consistency and access to a large set of powerful processing services are additional advantages of such deployments.

Another common example is with telecommunication service providers that are looking to monetize 5G technology by offering cloud services to their customers. Figure 3 shows a Telco MEC (Mobile Edge Computing) topology making use of IBM Cloud Satellite, IBM Edge Application Manager (IEAM) and Red Hat OpenShift Container Platform (RHOCP):

Figure 3. Telco MEC topology using IBM Cloud Satellite and IEAM services.

 

To provide a bit more context, MEC effectively offers localized cloud servers and services rather than depending on a larger, centralized cloud. This basically means the edge/IoT devices will communicate with more, smaller data hubs that are physically closer to them (i.e., on the “edge” of the network). Rather than online games having to send data to a distant central server, process it and send back a response — all of which slows down overall communication speeds — they will be able to access more power, closer to the gamers.

Wrap-up

In addition to the millions of devices, IoT and edge computing have the challenge of accessing and storing data in the “last mile.” Products like AWS Outpost, Azure Stack, Google Anthos and IBM Cloud Satellite complement IoT and Edge topologies. In fact, the IBM Edge Application Manager Hub is often deployed in a Satellite location or resides in the cloud. The combination of the two technologies provides a compelling solution that companies in healthcare, telecommunications and banking can use. The agnostic nature of IBM Cloud Satellite even allows it to not only bring IBM Cloud services to remote locations but also services from AWS, Azure and Google Cloud.

The IBM Cloud architecture center offers up many hybrid and multicloud reference architectures including AI frameworks. Look for the IBM Edge Computing reference architecture here.

This blog post talked about bringing cloud services to the edge in what is commonly called distributed cloud or “cloud out.” It offers the best of both worlds — public cloud services and secure on-premises infrastructure. The folks at mimik have a very interesting notion of “edge in,” wherein they describe a world of microservices, edge-device-to-edge-device communication and creating a sort of service mesh that expands the power of the edge devices toward the cloud.

Let us know what you think.

Special thanks to Joe Pearson, David Booz, Jeff Sloyer and Bill Lambertson for reviewing the article.

 

Introduction: Akraino’s Federated Multi-Access Edge Cloud Platform Blueprint in R5

By Akraino, Blog

Introduction

This blog focuses on providing an overview of the “Federated Multi-Access Edge Cloud Platform” blueprint as part of the Akraino Public Cloud Edge Interface (PCEI) blueprint family. This blog specifically provides an overview of the key features and implemented components as part of Akraino Release-5. Key idea for this blueprint is to have a federated Multi-Access Edge Cloud (MEC) Platform that showcases the inter-play between telco side and cloud/edge side.

Prior to discussing the specifics of this blueprint implementation, the following subsection provides a brief description of what Multi-Access Edge Cloud (MEC) is and how it is ushering in as an enabler for emerging 5G/AI based applications landscape.

What is MEC and what are its  challenges?

MEC is a network architecture concept that enables cloud computing and IT capabilities to run at the edge of the network. Applications or services running on the edge nodes – which are closer to end users – instead of on the cloud, can enjoy the benefits of lower latency and enhanced end-user experience. MEC essentially moves the intelligence and service control from centralized data centers to the edge of the network – closer to the users. Instead of backhauling all the data to a central site for processing, it can be analyzed, processed, stored locally and shared upstream when needed. MEC solutions are closely “integrated” with access network(s). Such environments often include WiFi, mobile access protocols such as 4G-LTE/5G etc.

MEC opens up plethora of potential vertical and horizontal use cases, such as Autonomous Vehicle (AV), Augmented Reality (AR) and Virtual Reality (VR), Gaming, and Artificial Intelligence (AI), Machine Learning (ML), and Deep Learning (DL) enabled applications like autonomous navigation, remote monitoring by using Natural Language Processing (NLP) or facial recognition, video analysis, and more. These emerging 5G/AI based applications landscape typically exhibit characteristics such as the following:

  • Low Latency requirements
  • Mobility
  • Location Awareness
  • Privacy/Security etc.

All of these characteristics pose unique challenges while developing emerging 5G/AI applications at the network edge. Supporting such an extensive feature-set at the required flexibility, dynamicity, performance, and efficiency requires careful and expensive engineering effort and needs adoption of new ways of architecting the enabling technology landscape.

To this regards, our proposed “Federated Multi-Access Edge Cloud Platform” blueprint enables desired abstractions in order to address these challenges and, as a result, ushers in an application development environment that enables support for ease of development and deployment of these emerging applications landscape. Subsequent sections delve deep into the proposed “Federated Multi-Access Edge Cloud Platform” blueprint details.

Blueprint Overview: Federated Multi-Access Edge Cloud Platform

The purpose of the “Federated Multi-Access Edge Cloud Platform” blueprint is an end-to-end technology solution for mobile game deployed across multiple heterogeneous edge nodes using various network access protocols such as mobile and WiFi and others. This blueprint demonstrates how an application leverages a distributed and multi access network edge environment in order to get all the benefits of edge computing.

The diagram above highlights the use case scenario. On the left hand side is the device – as can be seen that the device is moving from location x to y.

The whole use case goes through 4 distinct steps. The first step is the service discovery flow. And then the game service flow follows. And once the device actually moves, it would trigger additional session migration flow. This also includes subsequent service discovery to go along with this session migration. Finally, step number four is once this migration happens, the UE will go to the new edge node.

In order to support all this, platform provides two key abstractions:

  • Multi-Access/Mobile Operator Network Abstraction: Multi-access network means a mobile, Wi Fi or whatever it takes. Multi-operator means even for the same 4G/5G there could be different operators (Verizon, AT&T etc.). There are various MEC edge nodes, they could be the WiFi based edge node and they can be from different operators.
  • Cloud-Side Abstraction: Cloud side abstraction includes key architectural components to be described in the subsequent sections.

Functional Diagram: Federated Multi-Access Edge Cloud Platform

The key component is this federated multi-access edge platform. The platform sits between applications and underlying heterogeneous edge infrastructure and also abstracts the multi-access interface and exposes application developer friendly APIs. This blueprint leverages upstream project KubeEdge as baseline platform – this includes the enhanced  federation function (Karmada).

Telco/GSMA side complexities (5GC/NEF etc.) need to be thought through and designed appropriately in order to realize extremely low latencies (10 ms) requirements desired by typical MEC use cases. For the multi access, we may initially use a simulated mobile access environment to mimic a real time device access protocol conditions as part of the initial release/s.

Key Enabling Architectural Components

Federation Scheduler (Included in Release-5)

As a “Global Scheduler”, responsible for application QoS oriented global scheduling in accordance to the placement policies. Essentially, it refers to a decision-making capability that can decide how workloads should be spread across different clusters similar to how a human operator would. It maintains the resource utilization information for all the MEC edge cloud sites. Cloud federation functionality in our blueprint is enabled using open source Karmada project. The following is an architecture diagram for Karmada.

Karmada (Kubernetes® Armada) is a Kubernetes®  management system that enables cloud-native applications to run across multiple Kubernetes® clusters and clouds with no changes to the underlying applications. By using Kubernetes®-native APIs and providing advanced scheduling capabilities, Karmada truly enables multi-cloud Kubernetes® environment. It aims to provide turnkey automation for multi-cluster application management in multi-cloud and hybrid cloud scenarios with key features such as centralized multi-cloud management, high availability, failure recovery, and traffic scheduling. More details related to Karmada project can be found here.

EdgeMesh (Included in Release-5)

EdgeMesh provides support for service mesh capabilities for the edge clouds in support of microservice communication cross cloud and edges. EdgeMesh provides a simple network solution for the inter-communications between services at edge scenarios (east-west communication).

The network topology for edge cloud computing scenario is quite complex. Various Edge nodes are often not interconnected and the direct inter-communication of traffic between applications on these edge nodes is highly desirable requirement for businesses. EdgeMesh addresses these challenges by shielding the complex network topology at the edge applications scenario. More details related to EdgeMesh project can be found here.

Service Discovery (Not included in Release-5)

Service Discovery retrieves the endpoint address of the edge cloud service instance depending on the UE location, network conditions, signal strength, delay, App QoS requirements etc.

Mobility Management (Not included in Release-5)

Cloud Core side mobility service subscribes to UE location tracking events or resource rebalancing scenario. Upon UE mobility or resource rebalancing scenario, mobility service uses Cloud core side Service Discovery service interface to retrieve the address of new appropriate location-aware edge node. Cloud Core side mobility service subsequently initiates UE application state migration process between edge nodes. Simple CRIU container migration strategy may not be enough, it is much more complex than typical VM migration.

Multi-Access Gateway (Not included in Release-5)

Multi access gateway controller manages Edge Data Gateway and Access APIG of edge nodes. Edge data gateway connects with edge gateway (UPF) of 5G network system, and routes traffic to containers on edge nodes. Access APIG connects with the management plane of 5G network system (such as CAPIF), and pulls QoS, RNIS, location and other capabilities into the edge platform.

AutoScaling (Not included in Release-5)

Autoscaling provides capability to automatically scale the number of Pods (workloads) based on observed CPU utilization (or on some other application-provided metrics). Autoscaler also provides vertical Pod autoscaling capability by adjusting a container’s ”CPU limits” and ”memory limits” in accordance to the autoscaling policies.

Service Catalog (Not included in Release-5)

Service Catalog provides a way to list, provision, and bind with services without needing detailed knowledge about how those services are created or managed.

Detail Flow of various Architectural Components

What is included in Release-5

As mentioned earlier that the purpose of this blueprint is an end-to-end technology solution for mobile game deployed across multiple heterogeneous edge nodes using various network access protocols such as mobile and WiFi and others. This blueprint demonstrates how an application leverages a distributed and multi access network edge environment for realizing all the benefits of edge computing.

This is the very first release of this new blueprint as part of the Akraino PCEI family. Current focus for this release is to enable only the following two key architectural components:

  1. Open source Karmada based Cloud Federation
  2. EdgeMesh functionality

This blueprint will evolve as we incorporate remaining architectural components as part of the subsequent Akraino releases. More information on this blueprint can be found here.

Acknowledgements

Project Technical Lead: Deepak Vij, KubeEdge MEC-SIG member – Principal Cloud Technology Strategist at Futurewei Cloud Lab.

Contributors:

  • Peng Du, Futurewei Cloud Lab.
  • Hao Xu, Futurewei Cloud Lab.
  • Qi Fei, KubeEdge MEC-SIG member – Huawei Technologies Co., Ltd.
  • Xue Bai, KubeEdge MEC-SIG member – Huawei Technologies Co., Ltd.
  • Gao Chen, KubeEdge MEC-SIG member – China Unicom Research Institute
  • Jiawei Zhang, KubeEdge MEC-SIG member – Shanghai Jiao Tong University
  • Ruolin Xing, KubeEdge MEC-SIG member – State Key Laboratory of Network and Switching Technology, Beijing University of Posts and Telecommunications
  • Shangguang Wang, KubeEdge MEC-SIG member – State Key Laboratory of Network and Switching Technology, Beijing University of Posts and Telecommunications
  • Ao Zhou, KubeEdge MEC-SIG member – State Key Laboratory of Network and Switching Technology, Beijing University of Posts and Telecommunications
  • Jiahong Ning, KubeEdge MEC-SIG member – Southeastern University
  • Tina Tsou, Arm