ETSI Hyper Orchestrator (HypO)

A Module Development Group of ETSI SDG OpenSlice

ETSI HypO is an open-source service orchestrator for managing the lifecycle of end-to-end services atop geo-distributed heterogeneous infrastructures.

HypO stands as a module on top of ETSI OpenSlice, both establishing a powerful orchestration platform that combines Resource-as-a-Service and neat end user application abstractions to greatly simplify application deployment, lifecycle management, and observability.

Landscape

Cloud computing has been rapidly expanding towards the end users, forming a "stretched" compute continuum across two extremes: IoT swarms and hyper-scaler clouds. Across this long path, connectivity is of paramount importance to ensure that modern geo-distributed services - deployed across multiple and heterogeneous domains - operate in a truly end-to-end fashion.

Figure 1: ETSI HypO landscape.

Problem Statement

Today's complex systems pose several challenges in the way service onboarding, deployment, and lifecycle management (LCM) is performed in an end-to-end fashion, as shown in Figure 2.

Figure 2: Problem statement.

Pain points

Continuous delivery pipelines of modern services - no matter how complex they may be - fall short to address 4 key issues:

Establish secure connections towards multiple testbeds - potentially owned by different administrative domains (aka stakeholders) - without suffering the pain of waiting for manual establishment of VPNs.
It is hard to cover a large set of deployment environments. For example, to move a service from a vanilla Kubernetes cluster to OCM, might require tweaks in the way your service is packaged. Imagine how complex this might become when dealing with the many Kubernetes distributions out there.
Establishing different types of underlying networks (datacenter, cellular, transport, etc.) underneath your compute infrastructure is a huge pain. This is the reason most service providers pay for network-as-a-service.
Producing many different flavours of your service, depending on where the service components need to be deployed.

Key question: Why spend so much time for these matters and not just devote this time to write new features for my service?

Mission

To address the growing complexity of geo-distributed service orchestration across the compute continuum.

Why you need ETSI HypO

ETSI HypO offers:

Service developers/providers an easy way to split a set of service components across distributed clusters, without touching your service package. All you do is interacting with the ETSI HypO Portal.
For services split across multiple private domains, ETSI HypO ensures on-the-fly encrypted connections among service components in different clusters, thus realizing true end-to-end service mesh communication in a secure way.
For services that pose certain network requirements, such as 5G with certain service-level agreement criteria for their users, ETSI HypO combines compute services with 5G-as-a-Service with a simple click on the Portal.
Upon a successful service provisioning, the ETSI HypO Portal offers real-time telemetry dashboards and service logs for increased service observability.
Adding a new domain with compute and network resources under the ETSI HypO realm is greatly simplified via neat and short ETSI HypO Portal workflows.

Ecosystem

The ETSI HypO ecosystem is based on 3 main pillars as shown in Figure 3.

Figure 3: ETSI HypO ecosystem.

In a nutshell, ETSI HypO offers service orchestration services to industries, large enterprises, SMEs, and start-ups that may potentially belong to different vertical market sectors, such as manufacturing, energy management, agriculture, logistics, etc. These stakeholders offer the environment to ETSI HypO, i.e.,:

the software that ETSI HypO needs to provision and manage. This software may be developed in house by the vertical business stakeholder - who in this case acts also as a service provider, or outsourced to a third-party service provider.
the infrastructure where ETSI HypO will act upon. This infrastructure may fully belong to the vertical business stakeholder, who in this case acts also as an infrastructure provider, or fully/partially outsourced to third-party infrastructure providers who may offer compute infrastructure (e.g., edge/cloud datacenters), network infrastructure (e.g., a telecom operator offering private 5G), IoT infrastructure, etc.

Architecture

ETSI HypO comprises of multiple microservices, loosely coupled together via a service bus, as shown in Figure 4.

Figure 4: ETSI HypO architecture.

The ETSI HypO architecture can be divided in 3 parts:

the portal which offers a user friendly interface to interact with ETSI HypO,
the backend which comprises the heart of ETSI HypO (APIs and core services), and
auxiliary services around ETSI HypO which complement the system with additional features.

North-Bound APIs

ETSI HypO provides management APIs for:

(i) products, services, resources, parties, and locations based on open TMForum (TMF) API specifications,

(ii) dynamic peering with sibling systems via TMF's' Party Management API, as well as

(iii) secure management of secrets through HashiCorp's Vault.

All ETSI HypO North-Bound Interfaces (NBIs) are described in the NBI service.

APIs towards an underlying OSS

ETSI HypO leverages the same TMF APIs to consume compute and network resource services from one or more underlying Operations Support Systems (OSS). ETSI HypO involves its Peering API to dynamically inject the desired services from an underlying OSS service catalog; these services are described via the TMF633 service catalog management API. Once injected into the ETSI HypO catalog, ETSI HypO is able to order these services using the TMF641 service ordering API, while ETSI HypO oversees their runtime management via the TMF638 service inventory management API. Currently, ETSI HypO integrates with the ETSI OpenSlice OSS using these APIs for ordering both compute services (different Kubernetes flavours) and 5G connectivity services.

Installation Guide

Follow the guidelines here to provision ETSI HypO on a physical or virtual machine.