Sorry, you need to enable JavaScript to visit this website.

Feedback

Your feedback is important to keep improving our website and offer you a more reliable experience.

OSF Edge Working Group and its Minimum Viable Product (MVP) Architecture

BY Shane Wang ON Oct 27, 2019

INTRODUCTION

This article introduces the Edge Working Group in OpenStack Foundation, describes its background, history, objective, and scope. The article also presents the MVP architecture developed by the OSF Edge WG, which is based on OpenStack*, and the StarlingX* project, which is an edge-computing project based on OpenStack that conforms to the MVP architecture. Finally, the article introduces the recent activities of the OSF Edge WG in the Asia Pacific (APAC) region, and looks ahead to the future work.

SCOPE OF OSF EDGE WG

The OpenStack Foundation Edge Working Group (OSF Edge WG) is a working group founded exclusively for edge computing. Its primary activities include:

  • Identify use cases and scenarios related to edge computing.
  • Focus on challenges and solutions in the IaaS layer.
  • Emphasize the importance of open infrastructure.
  • Encourage industry-wide collaboration.


In order to focus on the challenges and solutions in the IaaS layer, the working group needs to find common requirements, define common edge computing reference architectures, design and implement not only enhancements to existing projects and services to provide a better fit for edge, but also new projects and services to implement the missing functionalities. At this time, the OSF Edge WG has defined enhancements in OpenStack Keystone, Glance* and Cyborg*, and proposed many new functions in the new StarlingX project, covering OpenStack Nova*, Neutron*, Cinder*, and so on.

As the working group continued its work, the WG members believe its scope has grown larger and larger, to support full-stack solutions for edge computing, because no singular design can accommodate all edge scenarios and requirements.

HISTORY OF EDGE ACTIVITIES IN OSF

[May, 2017] 

In May 2017, at OpenStack Boston Summit, Verizon* delivered a keynote about taking OpenStack out to the network edges, which started the edge-computing journey in the OpenStack community. Edge computing is a familiar concept developed by Content Delivery Network (CDN) initially and was an old topic in the Internet era in the last century. Now, edge computing has started to embrace its next prosperity in the Infrastructure-as-a-Service (IaaS) and Software-Defined Infrastructure (SDI) world since 2017, with the development of cloud computing and fog computing.

[September, 2017 - November, 2017] 

At that summit, a two-day OpenDev edge computing seminar was proposed for that September in San Francisco. More than 200 participants attended the seminar and initial steps towards identifying edge computing and initial use cases in the OpenStack community began. The OpenStack Foundation Edge Computing Working Group (OSF Edge WG), while not formally “created” at that time, had its foundation at the seminar. Later in the year, additional edge-related presentations and sessions were discussed at OpenStack Sydney Summit in November 2017.

[February, 2018 - May, 2018]

During the OpenStack Project Teams Gathering (PTG) in Dublin in February 2018, the community discussed details of use cases and requirements for edge computing, specifically focused on synchronization and transaction management. In that month the OpenStack Foundation published a white paper on edge computing in conjunction with community feedback and work done by the Edge Computing Working Group. The white paper primarily defined edge computing as an extension of data center and cloud computing, and listed some sample scenarios including Cloud in a box, Mobile connectivity, Network-as-a-Service, Universal Customer Premises Equipment (uCPE), and Satellite enabled communication, among others. It also listed the common requirements for edge computing. In May 2018, Shuquan Huang from 99cloud*, along with Yih Leong Sun, Shane Wang, Ruoyu Ying, and Jian-feng Ding from Intel translated the white paper into Chinese in order to promote edge in the Chinese developer community.

[May, 2018]

In May of the same year, Intel and Wind River* decided to open source most of the code of their telecom industry cloud platform, Wind River Titanium Cloud, replaced those components unopened with advanced open-source based alternatives, and named it StarlingX*. StarlingX provides edge computing services for telecom carrier-class applications running in virtual machines and containers, and supports high reliability and high performance. The OpenStack Foundation absorbed StarlingX, together with another project called Airship* initialized by AT&T*, into its community at OpenStack Vancouver Summit in that month. Both projects were expected to collaborate across the community with other edge projects under the Linux Foundation Edge to develop a full-stack solution for edge computing services. The outputs of OSF Edge WG were also discussed at that summit, namely: identity, image management and hardware acceleration. The primary enhancements in Keystone, Glance, and Cyborg were identified for edge computing requirements and scenarios.

[September, 2018 - April, 2019]

At OpenStack Denver PTG in September 2018, the new deployment architecture for edge computing in OpenStack was proposed, called the Minimum Viable Product (MVP) architecture. A couple of weeks after the PTG, StarlingX, as the most important edge project in OSF that conforms to MVP, announced and delivered its first release to the world in October. Afterwards, the community highly valued edge computing, and had a dedicated edge computing track for edge topics only at OpenStack Berlin Summit in November 2018 and the following Open Infrastructure Denver Summit in April 2019.

CURRENT ACTIVITIES OF OSF EDGE WG

More than two years after the working group was founded, it has only become stronger. For use cases, it founded the use case sub-group to unify the template for describing use cases in a standard manner, to involve all industry segments, to collect characteristics, business cases, and requirements, and to identify mappings from them to reference architectures. Now, it covers mobile service provider 5G/4G virtual RAN deployment and edge cloud Business-to-Business-to-X (B2B2X), uCPE for enterprise network services, unmanned aircraft systems (e.g. Drones), cloud storage gateway for storage at the edge, open caching for streaming data at the edge, smart city as software-defined closed-loop system, augmented reality (e.g. Sony Gaming Network), analytics and control at the edge, manage retail chains, smart home, data collection (e.g. smart cooler or cold chain tracking), VPN gateway service delivery, and many others.

From an architecture point of view, the working group is still refining the architecture of Keystone for its federation with the Open Platform for Network Function Virtualization (OPNFV) community, and enhancing the architecture of Glance for its image and metadata caching.

The OSF Edge WG strongly advocates and encourages cross-community collaborations for full-stack edge solutions. The collaborations happened across communities and groups including Akraino*, the Edge Automation Group in Open Network Automation Project (ONAP*), the Edge Cloud project in OPNFV, the IoT Edge Working Group in Kubernetes*, and Multi-Access Edge Computing (MEC) of the European Telecommunications Standards Institute* (ETSI). We believe these joint efforts will bring innovations, integrated solutions, and win-win situations for all groups who participate.

MVP REFERENCE ARCHITECTURE

One of the most important technical architectures OSF Edge WG has developed so far is the Minimum Viable Product (MVP) for edge computing. Minimum means the architecture is simple and lightweight enough for edge, since under most circumstances edge workloads run on edge devices, gateways, or small-scale edge servers where resources such as memory footprint are constrained. Viable means the architecture is expected to be feasible, agile and variable for various edge requirements. Product requires that a solution based on MVP is expected to be product quality.

Because edge is not a one-size-fits-all topic, flexibility and scale drive the implementation of edge. Compared with the traditional OpenStack architecture, which is for centralized data center and cloud, the requirements of the control plane change. Sometimes, the architecture changes per edge site. Both centralized and distributed models exist for control planes. Meanwhile, the scale is also considered.

For a centralized control plane, the structure is similar to the centralized cloud: central sites located in data centers are fully functional, authoritative, and implement all cloud services, while remote edge sites are implemented with an operational control plane. Remote edge sites are minimum, but are dependent on central sites for authority and information, and are able to operate even though they are physically isolated from those central sites. From the perspective of the control plane, this type of structure has thick central sites and thin edge sites.

For a distributed control plane, the structure is more distributed: central sites are not operational because most of the cloud services are implemented in remote edge sites with an authoritative and operational control plane. Remote edge sites are likely not minimum on the control plane side, but leverage central sites for authority, image and security only, which Keystone and Glance are responsible for. From the perspective of the control plane, this type of structure is composed of thin central sites and thick edge sites.

Below we show four figures to explain the hierarchical architecture of centralized control plane and the hierarchical architecture of distributed control plane, respectively.

Figure 1.  Centralized Control Plane

Figure 2.  Large-scale Centralized Control Plane

Figure 3.  Distributed Control Plane

Figure 4.  Large-scale Distributed Control Plane

One characteristic of edge computing is the size of each edge site is small, but the overall scale is large, as we know. Small end edge sites are usually deployed with fundamental functions. They can continue to operate existing functions when they are isolated from the entire network.

Regarding large-scale deployments on the centralized control plane (Figure 2), some large or medium edge sites between small edge sites and central sites are introduced to the hierarchical structure for easy manageability. However, they can be ignored to reduce complexity when users don’t need large-scale or complicated edge deployments.

For large-scale deployments on the distributed control plane (Figure 4), the remote edge sites still keep most of the services for the control plane, but extend and offload operational functions to lower and farther minimum edge sites, which are called small edges in Figure 4.

MVP CONFORMANCE PROJECT - STARLINGX

StarlingX is a top-level OSF pilot project, and it provides high performance, low latency and high availability for edge cloud applications. StarlingX intends to reconfigure proven cloud computing technologies for edge computing, aiming at transportation, manufacturing, video streaming, healthcare, energy, retail, smart city etc. use scenarios. It provides a deployment-ready, scalable, highly reliable edge infrastructure software platform. The services from StarlingX focus on easy deployment, low-touch manageability, rapid response, and fast recovery. The following diagram shows the architecture of StarlingX. 

Note:  There are more OpenStack and Kubernetes components used than represented in the diagram. 

Figure 5.  StarlingX Release 2.0 Architecture

There are three deployment modes in StarlingX to support scalability: single server, dual server and multiple server, as shown below.

Figure 6.  Deployment Modes of StarlingX

Since StarlingX 1.0 was released in October 2018, more and more outstanding developers from companies such as 99Cloud*, China UnionPay*, FiberHome*, Intel, InterDynamix*, Red Hat*, SUSE*, and Wind River* have joined the community and contributed code. In September 2019, StarlingX announced its 2.0 release. In this release, the integration of OpenStack and Kubernetes* has enhanced the platform by providing flexibility, robustness, and related support for hybrid workloads, which, in turn, leverages building blocks to build the open source infrastructure. With the release of StarlingX 2.0, the number of out-of-tree patches continue to decrease since it has been aligned with the OpenStack Stein release. Out-of-tree patches are expected to be completely eliminated in StarlingX 3.0, which will be aligned with the upcoming Train release when it is released in December 2019. In a nutshell, the continuous growth of the StarlingX community has benefited all industry users, developers, and operators.

OSF EDGE WG IN APAC AND FUTURE WORK

With the growth of OSF Edge WG, more and more people are attracted by the working group and the work related to edge computing. However, language and time zones are still the major barriers for people in the Asia-Pacific (APAC) region to connect and communicate with the people in North America and Europe. The OSF Edge WG created a sub Edge WG for APAC in April 2019 to better serve the people in that region. The objectives of OSF Edge WG in APAC include:

  • Offer a forum for more vendors, deployers, and users to collect, share, discuss and sync up on user requirements, case studies, scenarios, gaps, reference architectures, and others.
  • Deliver documentation and white papers of use cases and stories, de facto references for publications, and requirement inputs for open source implementations, including but not limited to StarlingX, KubeEdge, EdgeX, CORD, Akraino, etc.
  • Activate edge discussion in the APAC region, build the edge ecosystem, and accelerate edge landing and business.


The OSF Edge WG in APAC adopted a rotating model to manage the sub WG and organize events for it. Right now the rotating chairs are Shane Wang from Intel, Shuquan Huang from 99Cloud, and Qihui Zhao from China Mobile. The top three priorities of the sub WG for the rest of this year is to build the local ecosystem, deliver whitepapers and make edge computing ready.

Currently, the sub WG has shared and discussed a few topics at the regular meetings, including a comprehensive comparison of different edge solutions, OpenNESS introduction and Akraino Integrated Cloud Native (ICN) by Intel, Big Cloud integration with StarlingX and its sigma edge architecture by China Mobile, EdgeX Foundry introduction by VMware, KubeEdge deep dive by Huawei, and a case study about shrimp farming with edge by 99Cloud, and so forth. All related presentation documents can be downloaded from the GitHub* location for the OSF Edge WG in APAC.

In the future, we believe the sub WG will provide great assistance to the OSF Edge WG in the APAC region to advocate and promote edge computing. As stated earlier, edge is not a one-size-fits-all opportunity, so we believe more and more open source edge solutions will be proposed to fit the abundant edge scenarios through cross-community, cross-project, and cross-company collaborations.

The OSF Edge WG is established by OpenStack Foundation to identify use cases, develop requirements and seek product-quality viable architectures for edge options. At this time, it worked out the MVP architecture based on OpenStack to meet the needs of many edge use cases. StarlingX is the project for edge computing incubated in OpenStack Foundation, which  conforms to the MVP architecture. We’re looking forward to seeing more people who are interested in edge computing or working on edge computing join the working group, contribute to the community, try out StarlingX and provide more feedback for its improvement.

REFERENCES

Author

Shane Wang, Individual Director of OpenStack Foundation Board and Engineering Manager at Intel System Software Products