Brandon Wick is a Senior Director of Marketing at Aarna Networks where he leads the organization on digital media, content and automated marketing, and communications strategy and execution. Prior to Aarna, he worked at the Linux Foundation for seven years building and growing open source projects and communities across the networking, cloud, and energy verticals. Before joining the Linux Foundation, he worked for multiple marketing agencies and an international NGO providing volunteer services around the globe. He holds a master’s degree in international relations and a bachelor’s degree in psychology. He resides in the Hudson Valley of New York with his wife and daughter.
“Cloud Native” computing represents paradigm shift for the computing ecosystem that continues to spur innovation and drive new business models. Edge computing is intricately woven into the cloud -- and driven by use cases like multicloud networking, cloud adjacent storage, and cloud edge machine learning -- has taken this concept to the enterprise edge. But edge computing environments have compute, connectivity, storage, and power constraints, necessitating new approaches and a new set of "Edge Native" principles.
The edge native infographic below highlights the work of the IOT Edge Working Group to explore what it means to be edge native, the differences and similarities between “Cloud Native” and “Edge Native”, and offer an initial set of principles for the industry to interpret, apply, and iterate upon. You can get the full whitepaper here. The group is now working on a set of Edge Native Application Design Behaviors Whitepaper. Stay tuned!
Sriram Rupanagunta
Sriram Rupanagunta is a co-founder & SVP Engineering at Aarna Networks, Inc, and heads their engineering team. Prior to Aarna, Sriram was the Head of India Engineering at Data Center Business of Western Digital Corp. Prior to Western Digital, Sriram was with the SSD based startup Virident Systems (which was acquired by Western Digital). Earlier to that, Sriram was also the co-founder of start up Aarohi Communications which was acquired by Emulex Corporation, and was the Vice President, Technology at Emulex. He lives in Bangalore, India with his wife and a daughter.
Sriram Rupanagunta
Jun 19
·
3 min
read
Demystifying Orchestrators: Navigating the Landscape of Management and Orchestration Solutions
We often tell our stakeholders that Orchestration is a general term, and we need to clarify what are the different types of Orchestrators available to apply in their network architecture.
In this blog, I will give an overview of various aspects of Orchestrators, since not all are created equal.
This can help decision makers choose what works for their organizational needs.
So what do orchestrators do?? In short, they perform things like:
Infrastructure Orchestration, which includes physical functions (servers, storage, networks etc.)
Cloud Orchestration, which includes tools that can spin up resources on clouds. All public clouds have tools available for this functionality.
Network Service Orchestration, which include network functions that are virtualized or containerized. They include Telco domains, such as 5G Core, Radio Access Network (RAN), Fronthaul/Backhaul networks, etc.
Application Orchestration, which typically include MEC (Multi-access Edge Computing) applications, that run on Edge clusters (e.g., CDN, computer visio,n etc.)
All or some of the above, can be also be done using a single Orchestrator
Next comes the scope of Orchestration functionality. This can be simplified into Day-0 or Day-N management. Some Orchestrators (typically the ones used on public clouds) usually perform only Day-0, which is to spin up the required resources for the operation of the function (Infrastructure, network functions, etc.). If any changes need to be made during the life of these resources (e.g., they need to be reconfigured, either manually or based on some configurable policies), there is no mechanism for doing so. The latter functionality is known as Day-N orchestration/management, also referred to as LCM (Life Cycle Management).
This itself has two distinct functions -- monitoring and taking actions (open loop or closed loop). Either the Orchestrator performs both of these functions, or it relies on other tools/utilities to monitor, and can simply perform corrective actions, such as the reconfigurations. In the virtualized world (VNF/CNFs), the reconfiguration could also include healing, scaling-in, scaling-out, etc.
Scalability is another important factor in choosing the Orchestrator. If your use cases need to be run on Edge networks (Enterprise Edge or Cloud Edge, also known as the New Middle Mile), it needs to be a lot more scalable compared to Cloud scale (those confined to few public cloud locations and clusters). The number of Network services and Applications (including the vendors) is also an order of magnitude more in case of Edge networks (1000s as opposed to 10s).
There is another twist to this tale -- some Orchestrators may be vendor or cloud-specific, which work well for the proprietary vendor or cloud resources, but obviously cannot be used for other vendor products or clouds. So if your environment is multi-cloud/multi-vendor, this option may not be suitable for you.
Independent of the above (but somewhat related in reality) is the openness of the Orchestrator implementations -- whether they are closed source implementations (proprietary) or open source based. In theory, the Orchestrator could be working with proprietary target functions but could be open source based (or vice versa). But in practice, they go hand in hand.
Lastly, some orchestrators may be specific to a particular domain (e.g., 5G Core, Transport or RAN). O-RAN Service Management and Orchestration (SMO), as the name implies, is an example of an Orchestrator that is specific to the RAN domain.
There is another category of vendors who offer Cloud Networking, which are also sometimes referred to as Orchestrators. But their functions are typically meant for specific networking use cases such as SD-WAN, MPLS Replacement, etc.
Regardless of their specific functions (which includes any of those mentioned above), there is another nuance to the way the solution is offered, which could be either as a Technology provider or a Service Provider. The former provides a level of customization that may be necessary for specific use cases or environments, whereas the latter (though well-packaged) is typically a fixed function.
With so many variations and nuances, users need to think through their specific organizational needs (present and future) before deciding on which solution to choose from the choices available.
I hope this sheds some light on the topic and gives some clarity on how to go about choosing a vendor. At Aarna.ml, we offer open source, zero-touch, orchestrator, AMCOP (also offered as a SaaS AES) for lifecycle management, real-time policy, and closed loop automation for edge and 5G services. If you’d like to discuss your orchestration needs, please contact us for a free consultation.
Brandon Wick
Brandon Wick is a Senior Director of Marketing at Aarna Networks where he leads the organization on digital media, content and automated marketing, and communications strategy and execution. Prior to Aarna, he worked at the Linux Foundation for seven years building and growing open source projects and communities across the networking, cloud, and energy verticals. Before joining the Linux Foundation, he worked for multiple marketing agencies and an international NGO providing volunteer services around the globe. He holds a master’s degree in international relations and a bachelor’s degree in psychology. He resides in the Hudson Valley of New York with his wife and daughter.
Brandon Wick
Jun 12
·
read
Aarna's participation in Linux Foundation Networking Developer and Testing Forum.
Aarna.ml participated in the recently concluded Linux Foundation Networking Developer and Testing Forum. The community gathered virtually June 6-8 and had the opportunity to collaborate to advance open source networking initiatives. Just like the previous virtual D&TFs, this was a gathering for community-generated sessions and discussions in order to address the challenges, opportunities, and future roadmaps for the projects and key initiatives.
The 5G Super Blueprint is an initiative to prototype and integrate open source software to address real-world use cases. It gives projects an opportunity to demonstrate their value to end users and gives end users an idea of how they could leverage the open source projects. During the February 2023 we had an initial brainstorming session to figure out how Nephio might fit into the existing blueprint work. Since then there has been some progress on the blueprint, and it is time to go to the next level of details on leveraging Nephio's as well as ONAP capabilities to enrich the blueprint.
As part of 5G SBP efforts, Aarna has worked in the community to develop E2E network slicing of the Core network and RAN using open source components. In this presentation, we demonstrated how to create an E2E network slice with cloud native network functions (CNFs) using EMCO. The Core Network (CN) will be an open source version of Free5GC (v3.2.1), and the RAN will be an open source version of UERANSIM (v3.2.6) with an integrated gNB.
The community is investigating Nephio's suitability for new use cases for network transformation as it develops. For the forthcoming O-RAN SC plugfest, a brand-new project is currently being developed that investigates how O2 IMS can expose a cloud-native declarative interface and combine with FOCOM in the Service Management and Orchestration (SMO) for administering the O-Cloud. This is applicable to both wireless and wired core IP networks using the IMS transport plane. We will discuss ideas for implementing and driving a declarative O2 IMS interface using Nephio Design Principles in this talk. The integration of the FOCOM in the SMO layer with the IMS implemented as Nephio is then discussed.
In part 1 and part 2 of this blog series, we mentioned the three use cases for the cloud edge (or the new middle mile) – edge multicloud networking, storage repatriation, and cloud edge machine learning. We discussed both the edge multicloud networking and storage repatriation use cases in more detail as well.
In this blog, we will cover the remaining and perhaps the most exciting use case – cloud edge machine learning.
Today, by and large, users run machine learning inferencing or light training such as for large language models i.e. LLM on-prem or in the public cloud. Both approaches have pros & cons.
Cloud Edge ML: OnPrem vs Public Cloud
What if there was a third-approach? Here the machine learning processing would occur at the cloud edge. See blog titled “AI and 5G Are Better at the Edge” by Oleg Berzin and Kaladhar Voruganti that addresses this scenario. While the blog links machine learning at the cloud edge to 5G, most of the blog applies to other access technologies as well. The authors cover three use cases – smart parking, AR/VR for predictive maintenance, and V2X and make a compelling case for the cloud edge.
In my view, the benefits of performing machine learning processing at the cloud edge include:
The ability to process data close to where it gets produced; this location is not as ideal as on-prem from a data proximity point of view, but it is a lot better than the public cloud. For the use cases listed above and for computer vision applications, the cloud edge can be a boon.
Ease of use features at part with the public cloud.
OPEX model.
On-demand, pay for what you use.
The benefits are further magnified when we talk about generative AI:
By using open source models such as Llama or Dolly, the user can have full control over the LLM model.
0% (ZERO) probability of data leakage – one of the biggest fears of commercial LLMs is that a company’s intellectual property might leak into public models. By using a private model, there is 0% probability that sensitive IP leaks into the public domain.
Given that the cloud edge can be easily connected to a company’s private data by using a private link to their datacenter cage or through SD-WAN breakout (see figure below), a cloud edge LLM might have much easier access to sensitive data for training purposes than a private or public LLM running in a public cloud.
Cloud Edge ML Implementation
The above figure shows a Cloud Edge ML implementation with connectivity to the company’s on-prem locations over SD-WAN. The ML workloads could be LLMs like Llama or Dolly or computer vision ones such as NVidia Metropolis.
Aarna Edge Services (AES)
The AES SaaS offering provides machine learning at the cloud edge. It features an easy-to-use GUI that can slash weeks of orchestration work into less than an hour. In case of a failure, AES includes fault isolation and roll-back capabilities. A private beta is coming soon with support for:
Equinix Metal Servers with GPUs
Equinix Fabric & Network Edge with Azure Express Route/AWS Direct Connect
Our partner Predera provides support and professional services for the ML workloads. Reserve your spot today to get on the private beta list as we will initially be enabling just a few users!
Brandon Wick
Brandon Wick is a Senior Director of Marketing at Aarna Networks where he leads the organization on digital media, content and automated marketing, and communications strategy and execution. Prior to Aarna, he worked at the Linux Foundation for seven years building and growing open source projects and communities across the networking, cloud, and energy verticals. Before joining the Linux Foundation, he worked for multiple marketing agencies and an international NGO providing volunteer services around the globe. He holds a master’s degree in international relations and a bachelor’s degree in psychology. He resides in the Hudson Valley of New York with his wife and daughter.
This blog highlights the key points we discussed in our recently concluded webinar on O-RAN and its business opportunity. The proliferation of cloud-native technologies and the adoption of open source in 5G networks are driven by the need for scalability, flexibility, service orchestration, cost efficiency, collaboration, and interoperability. These trends help address the challenges posed by the scale and complexity of 5G deployments and foster innovation. The cloud native approach allows for the efficient allocation of computing resources, enabling dynamic scaling and on-demand provisioning to meet varying network demands.
O-RAN the Final Frontier
O-RAN is the "final frontier" for Network Operators' open, interoperable, virtualized, and disaggregated HW+SW solutions. By embracing O-RAN, network operators can break free from the traditional closed and proprietary network architectures. They gain the ability to select and integrate components from different vendors, promote innovation, reduce costs, enhance security, and ensure long-term scalability.
The RAN currently represents the telecom operators' largest resource allocation (including CapEx and OpEx). With ordinary radio base stations often operating at between 25% and 50% capacity, it also needs to be more utilized.
Main Benefits of O-RAN:
Openness
Interoperability
Reduces vendor lock-in
Allows for “best of breed” solutions
Fosters greater innovation
O-RAN Architecture
Fig 1: O-RAN Architecture
O-RAN architecture enables disaggregation of RAN components, thereby enabling them to run on a cloud (on-prem, edge, or public clouds). Each component can come from a different vendor but they will interoperate as the interfaces are standard. Below is a high-level explanation of the main components:
Service Management & Orchestrator (SMO)
Near-RT RIC
O-RU (O-RAN Radio Unit)
O-DU (O-RAN Distributed Unit)
O-CU (O-RAN Centralized Unit)
O-Cloud (Open Cloud)
Role of O-RAN SMO
O-CU, O-DU, and O-RU RAN functions are managed and orchestrated (Day-0/Day-N) by O-RAN SMO.
It carries out FCAPS procedures in support of RAN tasks.
The functionality of O-RAN SMO is a logical fit for AMCOP, which carries out:
Orchestration (Day-0)
(Day-N) LCM
Service Assurance, or automation using Open Loop and Closed Loop
AMCOP is a fully functional O-RAN SMO as well as capable of orchestrating other Network Functions.
RAN-in-the-Cloud
"RAN-in-the-Cloud" refers to the concept of deploying Radio Access Network (RAN) components in a cloud-based environment. Here the RAN functions, such as baseband processing and control functions, are virtualized and run on cloud infrastructure instead of dedicated hardware. This virtualization allows for more flexibility, scalability, and cost-efficiency in deploying and managing RAN networks. Instead of deploying and maintaining physical equipment at each cell site, RAN-in-the-Cloud enables centralized control and virtualized RAN functions that can serve multiple cell sites.
O-RAN-based implementations must use an end-to-end cloud architecture and be deployed in a genuine data center cloud or edge environment in order to be more valuable than proprietary RAN. RAN-in-the-Cloud is a 5G radio access network running as a containerized solution in a multi-tenant cloud architecture alongside other applications. These can be dynamically assigned in an E2E stack to improve utilization, lower CapEx and OpEx for telecom carriers, and enable the monetization of innovative edge services and applications like AI.
During periods of underutilization in a RAN-in-the-Cloud architecture, the cloud can run additional workloads. Power usage and effective CAPEX will both be greatly decreased. With the ability to support 4T4R, 32T32R, 64T64R, or TDD/FDD on the same infrastructure, the RAN will become versatile and programmable. Additionally, MNOs can employ a GPU-accelerated infrastructure for other services like Edge AI, video applications, CDN, and more when the RAN isn't being used to its full potential.
RAN-in-the-Cloud POC
This Proof of Concept (POC) was commissioned by Aarna.ml along with its partners Nvidia and Radisys. The left-hand side reflects a peak hour scenario, where there is an SMO, a CU and DU, and two servers. The Radio Units are connected through a switch. There is a 5G Core running with the SMO. During the off-peak hours (as shown by the right-hand side), when the utilization reduces, the vendor-neutral, intelligent SMO monitors the metrics of the underlying network, and based on certain predefined policies it can migrate some of the functions dynamically. For example, the DU2 and CU2 are utilizing 50% of the server capacity, then SMO migrates the DU to the first server and CU1 serves both the DUs. Since Server 2 gets freed up and thus it can be used for other applications (for example AI Edge App).
Fig 2: Enabling Multi-tenancy with Dynamic Orchestration of RAN Workload
AI/ML is a Game Changer
Artificial intelligence is revolutionizing every industry. Not only can a COTS platform with GPU accelerators speed up 5G RAN, but also can be used for AI/ML edge applications. This offers a simple method for speeding 5G RAN connection and AI applications using the same GPU resources. Network Operators running AI/ML applications with no additional resource cost, and using the output from the AI/ML models for critical business decisions will have a competitive advantage.
Role of AI in O-RAN
O-RAN Architecture supports interfaces for running applications through standard interfaces.
These applications can be developed by multiple vendors, thus encouraging a vendor-agnostic ecosystem. For example, rApps/xApps are developed by various vendors for RAN optimization.
Additionally, the RAN data or network data may be fed into a Data Lake and connected to an MLOps Engine for further data analysis. An additional function of AI and ML is what we discussed above – improve cloud (running RAN) resource utilization by using analytics and run cutting-edge AI applications using the same resources.
Requirements for AI/ML in O-RAN
General purpose compute with a cloud layer such as Kubernetes
General purpose acceleration, for example NVidia GPU, can be used by non-O-RAN workloads such as AI/ML, video services, CDNs, Edge IOT, and more
Software defined xHaul and networking
Vendor neutral SMO (Service Management and Orchestration) that can perform the dynamic switching of workloads from RAN→non-RAN→RAN
The SMO also needs intelligence to understand how the utilization of the wireless network varies over time.
Sustainability is no Longer a Luxury
Reducing carbon emissions in network deployment is an important consideration for mitigating the impact of information and communication technology (ICT) infrastructure on the environment. Here are some strategies and technologies that can contribute to carbon reduction in network deployment:
Opting for energy-efficient hardware
Enabling multiple virtual network functions or services to run on a single physical server
Designing and operating data centers with efficient cooling systems, optimized airflow management, energy-efficient servers, and use renewable energy sources to power data centers
Transitioning to renewable energy sources such as solar, wind, or hydropower for powering network infrastructure
Implementing energy management systems and monitoring tools to track and optimize energy consumption
Using fiber-optic networks as they use less power to transmit data over longer distances
Implementing energy-efficient protocols, such as Energy Efficient Ethernet (EEE)
Optimizing network routing and traffic management to reduces unnecessary data transmission
Encouraging infrastructure sharing and collaboration among network operators
Properly manainge lifecycle of network equipment
Here, the SMO can have a dramatic impact on the O-RAN Capital Expenditure (CAPEX).
O-RAN implementations lend themselves to sustainability and energy efficiency by using:
Standard off-the-shelf servers rather than specialized hardware logic
Optimal resource utilization by leveraging them to run other tasks
Software/Virtualization of RAN components reduces power consumption
On-demand scaling is made simpler by container and VM workloads
Amar Kapadia is the CEO and Co-Founder of Aarna Networks, a SaaS solutions provider that offers zero-touch edge and 5G services orchestration and management at scale. Amar has over 20 years of experience in networking, storage, server, and I/O technologies through marketing and engineering leadership positions at Mirantis, Emulex, Philips, and HP. Amar is the author of three books: "ONAP Demystified", "Understanding OPNFV" and "OpenStack Object Storage (Swift) Essentials," and holds an MS EE degree from the University of California, Berkeley. He lives in San Jose, California.
From the AvidThink New Middle Mile report that features Aarna.ml we see the following three use cases emerging for the cloud edge (aka the new middle mile) orchestration:
1. Edge MultiCloud Networking
2. Storage Repatriation
3. Cloud Edge Machine Learning
In part 1 of this blog series, we discussed the Edge MultiCloud networking use case.
In this blog, we’ll explore the storage repatriation use case. In an insightful piece by Andressen Horowitz titled “The Cost of Cloud, a Trillion Dollar Paradox”, the authors observed how the cloud is a powerful vehicle for a growth stage company to accelerate their journey and yet the same cloud is a drag for later stage companies by compressing their margins. The article continues with some best practices that include incremental repatriation back from the public cloud. In another article David Heinemeier Hansson discusses why Basecamp abandoned public clouds.
While we are not suggesting anything as radical as completely abandoning public clouds, we are suggesting that repatriating storage (and in future databases) to a datacenter location should be considered. You could also call this design pattern cloud-adjacent storage. By being on a neutral site, the user can enjoy numerous benefits:
Run compute in public or private clouds and access storage without paying egress costs (thus cutting OPEX).
Even if you plan to use the public cloud, you can take advantage of cost arbitrage and move your compute to different clouds on an almost daily basis, again slashing OPEX.
Get the ideal storage performance you want. Spot pricing makes this option especially attractive, and using spot instances is only possible if the persistent storage is in a neutral site.
Get the data closer to the edge, where Gartner predicts 75% of the world’s data will be created by 2025, thus saving on bandwidth costs of moving the data to the public cloud. For example, by using log filtering, most logs could be stored on the cloud edge while just a subset could be sent to services such as Splunk or to the public cloud.
An example of cloud adjacent storage is as follows:
Aarna Edge Services (AES)
The AES SaaS offering provides initial orchestration and ongoing management of topologies such as the one shown above. It features an easy-to-use GUI that can slash weeks of work into less than an hour. In case of a failure, AES includes fault isolation and roll-back capabilities. The first version of AES supports the following digital products (with more to come):
