The Evolution of NaaS APIs and What it Means for the Enterprise

As connectivity demands explode, Network-as-a-Service (NaaS) is expected to play a critical role. Similar to cloud computing, NaaS eliminates the need for an enterprise to buy and manage WAN routers, switches, next-generation firewalls, VPN boxes, and more. However, enterprises that want to take advantage of the benefits NaaS offers, and the providers who deliver the services, face multiple challenges. Industry efforts to address those issues will be front and center at this week’s Global NaaS Event organized by MEF.

Why the great interest in NaaS, and why now? It's the booming connectivity requirements enterprises face. It is not just the need to connect more users and more sites. The advent of 5G services and the increased use of IoT and smart devices, combined with many organizations wishing to instantly access and analyze that data to increase operational efficiencies, improve customer experiences, and more, is expanding the need for secure connectivity.

"Enterprise requirements for cloud-like experiences are driving an industry transformation to secure dynamic services across a global ecosystem of automated networks. Secure NaaS platforms, for example, are particularly reflective of this trend as they combine on-demand connectivity, application assurance, cybersecurity, and multi-cloud-based services,” said Stan Hubbard, Principal Analyst at MEF, in a statement.

Meeting such connectivity needs with NaaS is reflected in recent studies and forecasts. The global NaaS market is projected to grow from $18.70 billion in 2023 to $155.17 billion by 2030, at a CAGR of 35.3%, according to Fortune Business Insights. Others known for tracking the market have similar projections. For example, Mordor Intelligence pegs the market size this year to be $19.29 billion, growing at a 32.36% CAGR to $78.38 billion in 2028.

The problem with such expected growth is that the manual processes that have long been used to subscribe to, deploy, manage, and secure the services cannot keep pace as the volume of users and services increases. Specifically, the lack of standardization and complex deployment procedures will impede market growth.

Industry NaaS efforts focus on APIs

The demand to securely connect users and increasingly devices has forced enterprises to rethink their connectivity strategies. Just as cloud computing has disrupted the data center, NaaS offers a similar model for networking, one where subscription-based services are available on-demand and can be easily scaled up or down to meet demands.

To meet an enterprise’s bandwidth and connectivity needs, NaaS services often must be delivered across many providers, hyperscalers, technology solution providers, and more. “The networks supporting these services will need to be fully API-driven,” says Pascal Menezes, CTO of MEF. “For this to happen, standards-based automation is required throughout the entire supply chain where all parties adopt a common, standardized set of APIs at both the business process and operational levels.”

Work on standards-based APIs has been underway for several years. For one, there is the work of the TM Forum, a group of 800+ global companies “working together to break down technology and cultural barriers between digital service providers, technology suppliers, consultancies, and systems integrators.” The organization has created toolkits and frameworks, including Open APIs, used by many cloud service providers. In 2020, the group developed a NaaS API component suite to support functions and capabilities responsible for the complete lifecycle of services.

Taking NaaS API efforts to a new level

Having APIs to automate common functions like order processing, service provisioning, security, etc., can make it easier for an enterprise to order and use NaaS services. And from a service provider's perspective, it accelerates service delivery and eliminates potential errors inherent in manual processes.

But what MEF and others have found is that many providers took the APIs and then customized them. In many cases, they would develop one-to-one APIs with many of the providers and applications they worked with. In the MEF State of the Industry Report released this year, it found:

Setting up proprietary APIs just with a single partner can take a year to 18 months for large service providers. Customizing the APIs for each partner and for multiple types of services with these partners would be prohibitively expensive and time-consuming. Some of the largest SP buyers, for example, have hundreds of seller partners.

The report cited an unnamed API expert at a large pan-European provider who noted, “If I had to set up proprietary APIs with 200+ partners, we’d still be here working on it in 100 years.”

MEF is building on the work done by the TM Forum. “We’ve focused on defining more prescriptive, contextualized API standards on top of TM Forum API standards so that service providers have tighter interoperable solutions for automating business and operational functions with partners,” says Menezes. To that end, MEF has created or is in the process of creating standards for more than 20 business and operational APIs that leverage and enhance TM Forum APIs.

Using MEF’s standards-based APIs and frameworks, service providers have been able to implement multiple APIs in as little as 3 to 5 months (vs. 18 months or more, customizing APIs for each partner). Such improvements have a great impact on the enterprise. Those looking for secure connectivity services will likely have more choices, and they will be able to sign up more easily and use those services.

All of this work sets the stage for this week's conference, where these issues and more will be discussed. (Look for a follow-up article later this week.)

The bottom line: Service provider using standards-based APIs and frameworks to automate common business and technical functions can more easily provide global NaaS services. That makes more services available to enterprise users and makes it easier for an enterprise to order and use those NaaS services.

Related articles: