Implementation of HTTP as a replacement for AMQP in Telco Event Bus
Here in this blog, We are going to learn about how the implementation of HTTP as a replacement for AMQP in Telco Event Bus.
More frequently than not, deployments at the Far Edge can be compared to appliances than to standard Kubernetes workloads. This lens may examine the workload’s characteristics and deployment models like Single Node OpenShift. At Telco Far Edge, many of the deployments are packet processing devices. For instance, the RAN DU connects to the radios on the Fronthaul that your User Equipment connects to wirelessly and sends packets to the Midhaul. In order to transfer packets from the Fronthaul network to the Midhaul network more effectively, it uses technologies like SR-IOV and DPDK.
These systems require PTP for greater synchronization and precision because they are more susceptible to network synchronization problems. They want a better awareness of the total platform health, encompassing both software, notably PTP, and hardware and being sensitive to network timing.
With OpenShift, we used Red Hat Advanced Message Queuing Protocol (AMQP) to resolve this issue. We were able to provide this general messaging component with events produced by the OpenShift PTP infrastructure and the Bare Metal Event Relay (BMER) component, which converts Redfish HW events into messages on the messaging bus, by introducing this generic messaging component.
We created and released a sidecar container image that CNF apps can include in their definitions of Pods. This sidecar container image will subscribe to the message bus and make it easier for CNF applications to consume events.
We have to reconsider our solution because the Red Hat Advanced Message Queuing Protocol (AMQP) Operator is currently deprecated. We came to the conclusion that we required a leaner solution because of the decreased CPU budget allotted for the CaaS platform in Telco Far Edge installations.
We are happy to announce that a native HTTP messaging system has taken the role of the AMQP. The HTTP Protocol Binding for CloudEvents – Version 1.0 is used by the RH event bus architecture, and this won’t change as we switch from AMQP to HTTP. We deliver these messages directly to the consuming sidecar rather than placing them into the event bus.
Before the AMQP Operator is removed from the catalog, this new course gives us a way to move forward and offers a better answer than the prior architecture.
It is preferable because it eliminates a significant reliance, which decreases complexity, and because eliminating the AMQP processes lowers the solutions’ compute requirements, which is a constant goal at the Far Edge.
Starting in 4.13, this is the way to go if you’re a CNF vendor who wants to learn more about the operating system.
