Multi-x

Motivation

The telco environment is a rough, varied union of applications and use-cases, and as the goals for 5G technology are established, the list of tiny but fragmented target markets is expanding. On the other hand, network operators are committed to moving the remainder of their deployments to an open framework that will allow them to break free from vendor lock-in. Our rationale for adhering to multi-x frameworks, as in multi-vendor and multi-version, is the variety of business applications and use cases, as well as the requirement for interoperability.

Various containerization solutions have evolved, addressing various problems such as performance, security, and isolation-level while participating in a variety of deployment patterns, some of which intersect with telecom concerns and needs. This brings up another aspect of multi-x in terms of multi-container to support cherry-picking of containerization technology, possibly based on internal policies and business contracts, or influenced by specific concerns addressed by that technology, or even for utilizing 3rd-party software distributed only under a specific stack of technologies. Multi-x may also refer to multi-node, multi-distribution, multi-runtime, multi-cloud, and multi-instance, all of which have been addressed by advanced cloud-native tools and orchestrators such as Kubernetes, but they are dispersed and require proper treatment to actually deliver on the promises required by the telco domain.

One of Hydra's major missions is to provide native, multi-x support for telecom applications in the cloud-native sector.

Domain

The multi-x concept captures the following domains:

1. Multi-vendor: Hydra supports a variety of suppliers for telecom services and components. Currently, OpenAirInterface (OAI), Amarisoft, and Software Radio Systems (SRS) are supported. Please contact the Trirematics project administration if you run a telecom software stack and would want to become a partner and receive full, interoperable support in Hydra.
2. Multi-version: Hydra also allows interoperability across various versions of the aforementioned software under the restrictions imposed by the protocols.
3. Multi-container: Hydra customers will benefit from a variety of compatible containerization platforms, such as Snap application containers and Docker process containers. As a consequence, one component of a network can be deployed using one containerization technique while the other components are based on different classes. Support for LXD system containers and Podman process containers is already included in the beta version, and future releases will include LXD virtual machines, Kata lightweight virtual machine containers, and other containerization and virtualization technologies.
4. Multi-node: Hydra can deploy workloads on multiple machines known as nodes by using an appropriate orchestrator such as Kubernetes. Hydra is not directly involved in deployment; rather, project Athena includes sophisticated deployment methods such as Helm Charts, Operator Framework, and native deployment files for Kubernetes, Openshift, Docker Swarm, Docker Compose, Podman Play, and Podman Compose.
5. Multi-distribution: Advanced orchestrators are also agnostic to the operating system at the distribution level, which means that Linux workloads should be executable on any Linux distribution, including but not limited to Ubuntu, Red Hat Enterprise Linux, and CentOS, all of which are fully supported in the Trident project stack for automatic testing and verification.
6. Multi-runtime: Support for multiple container runtimes has been added to Kubernetes as of version 1.22. This extends the containerization technology subject into the runtime responsible for container execution, particularly containerd and CRI-O.
7. Multi-cloud: In future versions, Hydra intends to allow cross-cloud deployments. The clouds might be public, private (on-premises), or hybrid, and provided by a variety of providers such as Google Cloud Engine (GCE), Amazon Web Service (AWS), Microsoft Azure, Openstack, and VMWare Sphere.
8. Multi-instance: By following the best practices in the cloud-native domain, Hydra provides means of scalability through multiple instantiations.