Add to RM Ch03 as a sub-section of Introduction Ch08
Alt: RM Chapter08 – PR #2118 | Please make your comments on the PR and not here.
X.3. Hybrid Multi-Cloud Enabled Edge Architecture
The GSMA whitepaper on "Operator Platform Concept Phase 1: Edge Cloud Computing" (January 2020) states, "Given the wide diversity of use cases that the operators will tasked to address, from healthcare to industrial IoT, it seems logical for operators to create a generic platform that can package the existing assets and capabilities (e.g., voice messaging, IP data services, billing, security, identity management, etc. ...) as well as the new ones that 5G makes available (e.g., Edge cloud, network slicing, etc.) in such a way as to create the necessary flexibility required by this new breed of enterprise customers."
Cloud computing has evolved and matured since 2010 when NIST (http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pd) published its definition of cloud computing, with its 5 essential characteristics, 3 service models and 4 deployment models.
The generic model for an enterprise cloud has to be "hybrid" with the special cases of purely private or public clouds as subsets of the generic hybrid cloud deployment model. In a hybrid cloud deployment, at least two or more distinct cloud infrastructures are inter-connected together.
Cloud deployments can be created using a variety of technologies open-source (e.g., OpenStack, Kubernetes) and commercial technologies (e.g., VMware, AWS, Azure, etc.). A multi-cloud deployment can consist of the use of more than one technology.
A generic Telco cloud is an hybrid multi-cloud. A better designation would be a federation of clouds - a federated cloud:
a collection of cooperating, interoperable autonomous component clouds
- the component clouds perform their local operations (internal requests) while also participating in the federation and responding to other component clouds (external requests)
- the component clouds are autonomous in terms of, for example, execution autonomy
- execution autonomy is the ability of a component cloud to decide the order in which internal and external requests are performed
- the component clouds are loosely coupled where no no changes are required to participate in a federation
- also, a federation controller does not impose changes to the component cloud except for running some central component(s) of the federated system (for example, a broker agent – executes as a workload)
- also, a federation controller does not impose changes to the component cloud except for running some central component(s) of the federated system (for example, a broker agent – executes as a workload)
- the component clouds are likely to differ in, for example, infrastructure resources and their cloud platform software
- workloads may be distributed on single or multiple clouds, where the clouds may be colocated or geographically distributed
- component clouds only surface NBIs (Please note that VMware deployed in a private and a public cloud can be treated as a single cloud instance)
X.3.1. Characteristics of a Federated Cloud
In this section we will further explore the characteristics of the federated cloud, architecture and architecture building blocks that constitute the federated cloud. For example, a Telco Cloud that consists of 4 sub-clouds: Private on prem, Cloud Vendor provided on prem, Private outsourced (Commercial Cloud Provider such as an HCP), and Public outsourced (see diagram below). Such an implementation of a Telco Cloud allows for mix'n'match of price points, flexibility in market positioning and time to market, capacity with the objective of attaining near "unlimited" capacity, scaling within a sub-cloud or through bursting across sub-clouds, access to "local" capacity near user base, and access to specialised services.
X.3.2. Telco Cloud
The Figure below presents a visualisation of a Telco operator cloud (or simply, Telco cloud) with clouds and cloud components distributed across Regional Data Centers, Metro locations (such as Central Office or a Colocation site) and at the Edge, that are interconnected using a partial mesh network. Please note that at the Regional center level the interconnections are likely to be a "fuller" mesh while being a sparser mesh at the Edges.
- The Telco Operator may own and/or have partnerships and network connections to utilize multiple Clouds
- for network services, IT workloads, external subscribers
- On Prem Private
- Open source; Operator or Vendor deployed and managed | OpenStack or Kubernetes based
- Vendor developed; Operator or Vendor deployed and managed | Examples: Azure on Prem, VMware, Packet, Nokia, Ericsson, etc.
- On Prem Public: Commercial Cloud service hosted at Operator location but for both Operator and Public use | Example: AWS Wavelength
- Outsourced Private: hosting outsourced; hosting can be at a Commercial Cloud Service | Examples: Equinix, AWS, etc.
- (Outsourced) Public: Commercial Cloud Service | Examples: AWS, Azure, VMware, etc.
- Multiple different Clouds can be co-located in the same physical location and may share some of the physical infrastructure (for example, racks)
| Type | System Developer | System Maintenance | System Operated & Managed by | Location where Deployed | Primary Resource Consumption Models |
|---|---|---|---|---|---|
| Private (Internal Users) | Open Source | Self/Vendor | Self/Vendor | On Prem | Reserved, Dedicated |
| Private | Vendor | HCP* | Self/Vendor | Self/Vendor | On Prem | Reserved, Dedicated |
| Public | Vendor | HCP | Self/Vendor | Self/Vendor | On Prem | Reserved, On Demand |
| Private | HCP | Vendor | Vendor | Vendor Locations | Reserved, Dedicated |
| Public (All Users) | HCP | Vendor | Vendor | Vendor Locations | On Demand, Reserved |
*HCP - Hyperscaler Cloud Provider
- Each Telco Cloud consists of multiple interconnected Regions
- A Telco Cloud Region may connect to multiple regions of another Telco Cloud (large capacity networks)
- A Telco Cloud also consists of interconnected local/metro sites (multiple possible scenarios)
- A Telco Cloud's local site may connect to multiple Regions within that Telco Cloud or another Telco Cloud
- A Telco Cloud also consists of a large number of interconnected edge nodes
- Edge nodes may be impermanent
- A Telco Cloud's Edge node may connect to multiple local sites within that Telco Cloud or another Telco Cloud; an Edge node may rarely connect to a Telco Cloud Region
X.3.3. Telco Operator Platform Conceptual Architecture
The Figure below shows a conceptual Telco Operator Platform Architecture. The Cloud Infrastructure Resources Layer exposes virtualised (including containerised) resources on the physical infrastructure resources and also consists of various virtualisation and management software (see details later in this chapter). The Cloud Platform Components Layer makes available both elementary and composite objects for use by application and service developers, and for use by Services during runtime. The Cloud Services Layer exposes the Services and Applications that are available to the Users; some of the Services and Applications may be sourced from or execute on other cloud platforms. Please note that while the architecture is shown as a set of layers, this is not an isolation mechanism and, thus, for example, Users may access the Cloud Infrastructure Resources directly without interacting with a Broker.
The Cloud Services and the Cloud Resources Brokers provide value-added services in addition to the fundamental capabilities like service and resource discovery. These Brokers are critical for a multi-cloud environment to function and utilise cloud specific plugins to perform the necessary activities. These Brokers can, for example, provision and manage environments with resources and services for Machine Learning (ML) services, Augmented/Virtual Reality, or specific industries.
Note: The functions shown on the left are not intended to represent that there is a single, say, integrated security framework across the layers
Glossary
PowerPoint Files:
Conceptual Architecture
Multi Hybrid Cloud
4 Comments
Walter Kozlowski
Comprehensive view. What is missing in my view, is allowing for a participation of several players (not only a Telco and a HCP) in this model (there is only one sentence somehow implying such an option: "some of the Services and Applications may be sourced from or execute on other cloud platforms"). A sophisticated "federated model" is for example a foundation for the Platform Model considered by GSMA OPG (Operator Platform Group). This also raises a question: do we really need a new model? Shouldn't we just adopt (or adept with some modifications agreed with OPG via OITF) the OPG model, and focus our efforts on developing further the infrastructure aspects of the the OPG model (keeping in mind of the hybrid multi-cloud character)? Happy to discuss this further...
Pankaj Goyal
Walter Kozlowski Thanks for raising some interesting questions.
I agree that we need to have a discussion with the OPG folks but to do so should we have a strawman of what we think is required. I think the high level architecture still needs to be fleshed out more before we are in a position to discuss with OPG.
W.r.t. "participation of many players" I apologize if the content somehow glossed over that. I thought there are multiple places where it is so stated but maybe requires strengthening. Examples,
W.r.t. Federation, I will add some context on what that entails.
I think it would be nice if we can discuss our proposal at some length – maybe in a special meeting.
Walter Kozlowski
Pankaj Goyal I am arranging an OITF technical meeting with OPG guys (hopefully still in Dec). The alignment of these models could be one of the topics? Doing this at a relatively early stage could save us much more efforts later on. Would you agree with this and to participate in such a meeting?
Pankaj Goyal
Walter Kozlowski Agree. BTW Cloud brokers for multi-clouds exist including Cisco CloudCenter (formerly CliQr); there are other multi-cloud brokers. I have some experience with that and hence the introduction of Cloud Broker in the Conceptual Architecture.