Aspiring NaaS providers must invest in their multi-cloud networking and API-based automation capabilities

MEF plays an important role in helping to define what network-as-a-service (NaaS) should like look as well as standardising APIs that will enable service providers to build their NaaS offerings. The organisation’s Global NaaS event takes place in Dallas, Texas between 28–30 October 2024, where Analysys Mason will participate as one of the organisation’s analyst partners alongside members of  the MEF community that will be highlighting their recent work on NaaS. This article explores some of the important market trends and topics that we expect to be discussed at the event.

Evolving enterprise-related multi-cloud connectivity requirements are leading to early NaaS adoption 

Enterprises are running applications in a growing number of public, software-as-a-service (SaaS) and edge clouds and therefore need to connect these environments with each other and their on-premises data centres. However, traditional connectivity solutions are proving inadequate due to the complexity of stitching together underlay networks from multiple service providers and because these solutions cannot offer the required agility and flexibility to mirror that of the cloud. Enterprises are instead demanding multi-cloud networking solutions that allow them to rapidly provision connectivity on-demand and apply traffic engineering and security policies in a consistent and programmable manner across their networks and cloud environments. These requirements coincide with shifting network buying power – with CloudOps and DevOps teams gaining greater influence on networking spend – as well as a move to application-driven networking.

Service providers can fulfil these networking requirements by offering multi-cloud NaaS solutions. In alignment with the MEF, Analysys Mason defines such solutions as those that support the following features and functions: any-to-any connectivity, self-service, single-pane-of-glass management, flexible consumption models, value-added service marketplaces and exposure of network capabilities through APIs and software development toolkits (SDKs).¹ This definition goes beyond simply allowing enterprises to avoid building and maintaining their own networking infrastructure; NaaS enables them to set up and consume performant, secure and service-level agreement-based (SLA-based) connectivity through a cloud-like experience.

Many service providers are investing in underlay and overlay capabilities to develop their NaaS offerings

Multi-cloud NaaS imposes requirements on both underlay and overlay networks. The need for programmability means that underlay networks must be software-defined and highly automated – to the extent that many telecoms operators have found that they need to transform their existing underlay networks before they can begin offering NaaS. NaaS providers may own and operate their own underlay networks and/or partner with other service providers to utilise their underlay networks. In addition, NaaS solutions mandate intelligent, cloud-native overlay networks. Service providers can build these overlay networking platforms in-house, buy software platforms from vendors or take a hybrid approach.²

NaaS is an opportunity for more players than just traditional telecoms operators. A variety of specialised B2B connectivity providers, software-defined interconnect providers, co-location/internet exchange providers, multi-cloud networking software vendors, multi-cloud SD-WAN managed service providers and public cloud providers also play key roles in the NaaS value chain.³ However, all of these providers struggle to fully address enterprises’ NaaS requirements and, as such, they are actively working to expand their NaaS offerings, for example, by expanding their geographical presence, adding new Layers 4-7 application provider partners, enhancing the programmability of their underlay networks, improving self-service capabilities and exposing a greater range of network capabilities via APIs.

Automation that is based on standardised APIs will be essential for NaaS providers

NaaS providers must implement automation that streamlines how enterprise customers order connectivity and how it is delivered by service providers using their own or partners’ networks. This requires service providers to build their NaaS solutions around API-driven automation. To achieve the vision set out in the MEF NaaS Industry Blueprint, MEF has developed Lifecycle Service Orchestration (LSO) APIs, which support business process and operational automation. These LSO APIs build upon and extend TM Forum’s APIs and can be used alongside those from TM Forum and CAMARA.⁴

NaaS providers will need to implement both north–south and east–west APIs. North–south APIs act within a service provider, facilitating communication between their BSS, OSS and underlying network. For example, this might include APIs to instantiate new network services, manage performance and monitor faults. This API-driven operational automation will replace the manual processes traditionally used to configure services, which often resulted in customers waiting weeks or months for connectivity. In contrast, east–west APIs are used by enterprise customers and developers to interact with NaaS providers, as well as by NaaS providers to integrate and orchestrate their partners’ networks. Enterprise-facing APIs simplify how enterprises order connectivity (potentially allowing connectivity to be provisioned by enterprises’ CI/CD pipelines), while developer-facing APIs facilitate programmatic interactions between applications and networks. Moreover, these east–west APIs enable inter-service provider collaboration, allowing NaaS providers to seamlessly integrate services across partner networks, meeting enterprise and developer demands on a larger scale and geographical footprint. 

It is critical that east–west NaaS APIs are standardised across the industry. Service providers that rely on proprietary APIs for specific partners’ networks will be constrained by limited partner options and the time required to develop new proprietary APIs. In contrast, widespread adoption of MEF’s LSO APIs would enable NaaS providers to seamlessly partner with other service providers with minimal or no custom integration effort. Collaboration between standards bodies – such as TM Forum, MEF and CAMARA – and active participation from the broader NaaS ecosystem in developing standardised APIs will be crucial for enabling new API-driven service opportunities in various industry verticals. As the NaaS landscape evolves, service providers’ abilities to adapt to emerging standards and to integrate diverse network capabilities will not only determine their competitive edge but also shape the future of connectivity in an increasingly digital, cloud-driven and AI-centric world.

¹ For more information, see Analysys Mason’s What is NaaS and why is it important?

² For more information, see Analysys Mason’s Strategic pathways for multi-cloud NaaS: exploring build versus buy approaches.

³ For more information, see Analysys Mason’s Multi-cloud networking: a framework for understanding the opportunity and ecosystem.

⁴ For further information, see TM Forum (28 February 2017), MEF, TM Forum, Carriers Collaborate on APIs.