We are pleased to announce that Aarna.ml, a 5G/EdgeOps company, has raised financing via an angel round. The lead investor is Subba Reddy, a noted angel investor and technologist who also led seed rounds for i2Chain (cybersecurity) and Xaptum (IoT).

‍

This funding will let us 1) build our 5G/edge product, based on the Linux Foundation open source ONAP4K8s, that will orchestrate, manage, monitor, and automate cloud native 5G and edge computing workloads across multiple Kubernetes edge clouds, 2) complete a public 5G PoC, and 3) complete a private LTE/5G PoC. This round will also instill confidence within our customers and partners.

While the coronavirus is a global tragedy, it is going to provide 5G with a big boost as telemedicine and emergency response become hot topics. 5G with its high bandwidth, ultra-reliable low-latency, and IoT support promises to revolutionize healthcare through AR/VR, edge IoT analytics, faster communication, and even futuristic trends like remote surgery. Similarly, emergency response is expected to be revolutionized by 5G through accurate IoT data, analytics, drone control, AR/VR etc. And our Aarna.ml ONAP Distribution will help accelerate the move to 5G.

The three work streams listed above will help us get to the next milestone. I will summarize the goals and expected outcomes of these activities in subsequent blogs.

There was a Linux Foundation Edge Akraino face-to-face TSC and 2020 planning meeting last week held at Facebook in Menlo Park, CA. It was a fascinating meeting where I got to see the state-of-the-art of edge computing; here are my key takeaways:

1) The dominance of Kubernetes (K8s): I think it might be safe to say that K8s will be the default NFVI on the edge. Most blueprints (the term used by Akraino to signify projects) were based on K8s. The few that were based on OpenStack used a containerized version of OpenStack deployed on K8s. So essentially it is safe to say that K8s will dominate edge environments.

2) Focus on a small footprint: Edge environments could be quite constrained. There were several blueprints focusing on very small environments such as on-prem. Specifically, see slide presentations on the ELIOT (Edge Lightweight and IOT), uMEC (Micro MEC), KubeEdge, and others.

3) Centralized infra controller: With 100s to 100s of thousand edge locations, it is impractical to install K8s on each edge manually. Almost every blueprint had some notion of a centralized infrastructure controller that would automagically install K8s on a given edge cloud. See IEC and ICN blueprints as example.

4) Diversity of applications: Another interesting aspect was the diversity of applications. Apps ranged from LTE, 5G, SD-WAN, AR/VR, gaming, V2X, IoT, and more. The edge is indeed going to a lot more than just network functions.

5) Framework wars: From general frameworks, e.g. TARS to specialized frameworks, e.g. Kubeflow for AI/ML apps, I expect numerous edge application frameworks to jockey for position. I expect full blown edge application framework wars to emerge in earnest in late 2020. These wars will be critical to establish control points, similar to IOS and Android for phones.

6) Interest in dataplane acceleration: RAN and UPF network functions are expected to put heavy demands on datapath computation. For this reason, hardware acceleration is expected to play an important role on the edge. Dataplane acceleration will come in numerous flavors ranging from software techniques, SmartNICs, FPGAs, GPUs, inference engines, and more.

Overall, I truly enjoyed the event and believe Akraino will play a key role in moving the industry forward. Aarna is involved with the Akraino ICN Blueprint helping with ONAP4K8s from an orchestration, lifecycle management, and automation point of view. Contact us if you want to learn more.

‍

I was recently interviewed by AvidThink on the top 5 NFV Trends in 2020.  You can watch my interview or read a summary here:

1. Disaggregation in earnest: We have heard about the trend where customers will buy  hardware from one vendor, virtualization software from another, VNFs from yet another set of vendors, so on and so forth. But this has largely not materialized. With 5G/edge, I am definitely seeing serious interest in disaggregation. From our stand point, ONAP is well suited to address this trend from an orchestration, management, and automation point of view as it is vendor agnostic.

2. Cloud native: The conventional wisdom is that the move from VNFs to CNFs (cloud native network functions) will take a long time—perhaps 3-5 years. I am seeing something quite surprising, some customers are betting the farm on CNFs and cloud native applications for 5G/edge in 2020! ONAP definitely has the lead on K8s and CNF support, so I find this trend very promising.

3. Open source: Several operators are starting to adopt an open source "first" methodology. In other words,  technologists at these companies need to justify to the management team why they want to use proprietary software instead of open source. Open source is not for the faint of heart though, and I am hoping more and more customers will understand how to engage effectively with open source projects such as ONAP.

4. Widespread adoption of automation: Automation is now new. A lot of aspects of SDN/NFV have been already been automated. However, we are yet to see widespread adoption of automation frameworks. With 5G/edge around the corner, it will not be viable for humans to manage fault and performance management issues. For this reason, I feel automation using frameworks such as ONAP DCAE +AI/ML will be adopted starting in 2020.

5. Convergence of management and orchestration layers. There are so many layers of management and orchestration, e.g. LSO (MEF Lifecycle Service Orchestration), NFVO for VNFs, NFVO for CNFs, MEAO (Multi-Access Edge Computing Application Orchestration), and SDN Orchestration. There just isn't enough room for so many different platforms. My prediction is that all of these platforms will get collapsed into one framework such as ONAP. Of course there will still be cloud orchestration using OpenStack or Kubernetes, but the rest should get consolidated.

Curious to know how ONAP, more specifically the ONAP4K8s profile, can help with CNFs, 5G, and edge? Come see us as ONES in Los Angeles in April where we will have several demos/presentations on these topics. Set up a meeting with us (scroll down to the contact us form).

If you are a VNF vendor (or for that matter PNF/CNF), establishing interop with ONAP can be stressful. Sure, there is excellent documentation to help you (VNF Requirements project) and easy-to-use tooling to establish baseline compliance. But given our busy lives, it can be a bit difficult to figure out where to start. You might have questions such as:

• What is ONAP?
• Why should you bother about interop with ONAP?
• What is the OPNFV Verification Program (OVP)? Why should I care?
• How does OVP help with interop testing with ONAP?
• How do I get started?

A recent webinar titled "How the OPNFV Verification Program (OVP) Can Boost VNF Interoperability" featuring yours truly as one of the panelists answered these questions. But that was not a hands-on experience. To help address the above questions in a 100% hands-on manner and to help you get started on your OVP VNF interop journey, the ONAP community is organizing an OVP VNF hacking track at the upcoming free LFN Developer and Testing event in Prague this January.

There will be ONAP and OPNFV environments available, experts at your beck-and-call, and guidance to get you testing your VNF against ONAP. Although there is a formal test plan, you can do as little or as much as you want (this format is inspired by ETSI Plugtests). It's a judgement free zone and no vendor names will be associated with results in the post-event report. CNF/PNF vendors are welcome too, though there is no equivalent test plan for you.

‍

Our (Aarna.ml) engineers will be at the event to help out. So what are you waiting for? Ask your engineers to sign up for this free event and experience the beautiful city of Prague in the dead of winter (the average temperature is a balmy -2C, so should not be too bad).

#ONAP #NFV

In this final installment of our series of blogs related to the 4th ETSI Plugtests held in June 2019, I’d like to discuss the successful testing done between the Benu Networks Virtualized Multiservice Edge Gateway (vMEG) and our Aarna.ml ONAP Distribution (ANOD) 2.0. Benu Networks participated in the VNF category of the Plugtests and ANOD participated in the MANO category.

The vMEG series is Benu Networks’ virtual software deployment option for the SD-Edge Platform, which runs the Benu Operating System (BenuOS) for fixed and mobile broadband service providers looking to deploy next generation IP services to the edge and core of their networks.  The solution can run in OpenStack or VMware and on common industry hypervisors. The platform can support multiple services simultaneously. The vMEG provides new scale and economics for Benu Networks’ virtualized IP service & network applications and offers service providers a fully virtualized deployment for the most demanding networking and IP service applications.

ANOD is Aarna.ml 100% pure play commercially supported distribution of the Linux Foundation Open Network Automation Platform (ONAP) project. ONAP provides fully automated orchestration, lifecycle management, and monitoring of edge workloads and network services.

ONAP has a detailed set of VNF requirements that include packaging requirements as well. The VNF descriptor can either be in OpenStack Heat template or TOSCA. The testing used the Benu Networks’ vMEG packaged using a Heat VNF descriptor. Using this VNF package, we were able to onboard the VNF to ONAP’s design studio. Next, we created a Network Service (NS) consisting of that same VNF. ONAP then deployed the entire NS onto a commercial cloud vendor’s OpenStack platform.

Do you have a VNF but are not sure how to interoperate with ONAP? Check out our VNF Onboarding for ONAP whitepaper.

Learn more about Benu Networks’ vMEG at https://benunetworks.com

If you are curious about the business of open source software, I would highly recommend Peter Levine and Jennifer Li's blog titled, "Open Source: From Community to Commercialization." This exceptional blog, that uses the "As Software Eats the World, Open Source Eats Software" line, covers a number of topics ranging from growth of open source software in both revenue and across verticals, the virtuous cycle of open source, business success KPIs, business models, and finally open source go-to-market.

I am going to attempt to evaluate the ONAP project across the above metrics. ONAP, for those new to it, is a Linux Foundation Networking open source project that provides fully automated orchestration, monitoring, and lifecycle management of NFV, SDN, and edge computing services.

At least a quick scan of Levine's and Li's blog will be useful to get some context around the rest of my blog.

Open Source Renaissance

This one should apply to ONAP with ease. There is every reason to believe that open source will impact 5G and edge computing in the same way it has impacted other industries. With analysts such as Chetan Sharma predicting that over the first 10 years in their lifecycle, the edge computing economy will be more than 4x bigger than the cloud economy, the prospects for open source software in this segment are promising.

The Virtuous Cycle of Open Source

As 5G and edge computing disaggregate what has traditionally been a vertically integrated hardware and software solution, traditional benefits of open source such as no-vendor lock-in, the ability to influence the roadmap, rapid innovation, transparency, improved security etc.  come into play. ONAP brings with it a couple more advantages in the areas of collaboration with 3rd party standards bodies/open source projects and streamlining interop testing. On the first point, organizations such as ETSI, TM Forum, MEF, 3GPP, CNCF are using ONAP as a de-facto project to prove out their standards or open source efforts. On the second point, the industry simply does not have the resources to do N orchestration vendors x M Workload vendor interop testing. ONAP with its community driven compliance and validation testing of VNFs, will become the gold standard in interop test verification. In short, the combination of traditional open source benefits and a couple of unique ONAP-specific ones, should unlock the virtuous cycle of open source for ONAP.

Business Success

Levine and Li talk about three stages of business success: project-community fit, product-market fit, and value-market fit. Let me first provide my assessment of ONAP across these three stages and then my reasons for the assessment:

• Project-community fit: Proven
• Product-market fit: In-process
• Value-market fit: Not proven but promising

Project-Community Fit

If we look at project-community fit for ONAP, over the last 90 days, we see:

• 26 contributing organizations
• 30 sub-projects

The contributor growth since the inception of the project is as per the below chart. The month-to-month varies a lot, so I think the 6 month or 180 day moving average is better (source onap.biterg.io), and overall in the right direction.

Product-Market Fit

The fact that users such as AT&T and China Mobile were founders of the project shows that ONAP solves a real problem. With the latest ONAP Dublin release, the user activity looks like follows:

• 3 users state they have ONAP in production: AT&T, Bell Canada, Orange
• 12 other users state they are in PoC stage: Bringcom, China Mobile, China Telecom, Deutsche Telekom, Equinix, KDDI, Reliance Jio, Swisscom, Telecom Italia, Turk Telecom, Verizon, Vodafone

This is all promising, but I don't think we have yet seen the one solid use case where users are tripping over each other to get to ONAP. Perhaps 5G and edge computing might be it? For this reason, I'm leaning towards saying product-market fit is in-process.

Value-Market Fit

There are two questions that come to mind: 1) Is the project inherently amenable to a value-market fit? And 2) Has that value-market fit been demonstrated as of now?

The first question is interesting. As Levine and Li point out, if the project is too awesome, there isn't an opportunity to create much value-market fit. Docker comes to mind. So the project should inherently have some rough edges that require vendors. ONAP fits in this category. In fact, if anything vendors will have to do some serious heavy lifting in terms of ONAP lifecycle management and hardening.

Having established this point, the second question is whether there is value-market fit today. Based on the ONAP product revenue, I would say not yet. Other than us (Aarna.ml), I am not aware of a 100% open source pure-play distribution. However, as per the Dublin announcement, there is some level of commercial activity around ONAP at Accenture, Amdocs, Boco, CommScope, ENEA, Ericsson, Fujitsu, Huawei, IBM, Netsia, Nokia, Tech Mahindra, Samsung, Wipro, and ZTE. Many of the bigger companies are obviously dabbling; looking to see which way the wind blows. The only burn-your-ships-a-la-vikings company is Aarna.ml, where we will live and die solely based on the success or failure of ONAP.

Business Models

I expect 5 business models for ONAP:

1. SaaS: ONAP could be installed in a public cloud to manage 5G/edge and other workloads. This could be attractive for smaller customers.
2. Managed ONAP: This is between a software sale and SaaS, where ONAP could be installed on-prem, but managed by a vendor.
3. Open-core: This is a perhaps going to be the most popular ONAP business model. In fact, we at Aarna are pursuing this model at this time. We will provide support for the ONAP platform itself and provide proprietary apps, artifacts, and dashboards on top specific to a use-case. Our proprietary add-on is called AarnaStream™.
4. Services: ONAP will need a ton of professional services. We expect large SIs to provide these services.
5. Training: This is another standard business model. In fact, Aarna is the #1 ONAP training provider.

Open Source Types by Buyer

If there was one embellishment I might make to an otherwise amazing blog by Levine and Li, that is to categorize open source projects by the buyer persona, more specifically the champion.

I think the champion can be classified into three categories:

1. Individual champion: Take Postman for example. It is typically brought into the organization by individuals.
2. Team leader champion:  Jenkins for example. It is difficult to try this out individually, but a team can definitely evaluate Jenkins and bring it in.
3. Organization leader champion: For good or bad, ONAP fits here. Even the evaluation of ONAP has to be driven at high level by someone who has authority across multiple teams.

How an open source project is championed in an organization, in my view, affects the way the business success evolves:

What do you think? I'd love to hear your feedback.