The API War in Virtualization

TIANOW, in conversation with Hema Kadia, VP and Head of Strategy and Practice on how to deal with the API war

How do we resolve the laundry list of API specs vying to be the virtualization industry standard? Hema Kadia, Prodapt’s VP & Head of Strategy & Practice, speaks with TIA (Telecom Industry Association) about the risks and rewards of winning the API battle and how to proceed in the meantime.

Video Transcript

Clarence: Hi everybody, welcome to TIANow. I’m Clarence Reynolds. There’s a long list of specifications vying to be the standard in virtualization, but will there be a single winner or a range of interfaces? Hema Kadia is the VP and Head of Strategy at Prodapt, and she joins us to discuss the API war in virtualization. Hema, thank you for being with us today.

Hema: Thank you for inviting me.

Clarence: Absolutely. Hema, how do you resolve the laundry list of specs vying to be virtualization’s industry standard?

Hema: So, broadly, before I address that question, we can categorize the APIs in the virtualization industry in 3 categories. One is where we lack specifications; second category is where we have some well-defined standards for specific services; and the third category is where, as you rightly mentioned, we have competing interfaces. So, let me give you an example of each of the categories, and then come to the solution.

So, lack of specifications: Some of the examples would be an API for, say, a service such as bandwidth calendaring or business application APIs for a layer 2 VPN service or even base configuration for MPLS network and contain media delivery services.

The second category, where we say that we have some specifications, an example would be carrier Ethernet. Recently, TM Forum and MEF along with operators have teamed up to define lifecycle service orchestration API specifically focusing on the carrier Ethernet services.

And the third category, where we see competing interfaces, an example would be IP address management, billing, VNF lifecycle management, network virtualization, or orchestration. Additionally, when physical network functions and virtual network functions need to interoperate, what happens is we need to do a lot of customizations on these competing APIs. So, coming back to your question of “how do we resolve this issue of competing APIs,” one of the solutions could be open APIs with Microservices architecture, although we see that open API adoption is still far-sighted in the industry.

Clarence: And that’s really the question. Can the industry actually merge these competing interfaces down to a single winner or will there need to be just a range of interfaces that we deal with moving forward?

Hema: So, collaboration between industry bodies is definitely needed, and it’s already happening to some extent. Recently we saw ONAP with Linux Foundation is collaborating with MEF to define lifecycle service orchestration APIs. They’re focusing specifically on the northbound interface between the orchestrator and the OSS/BSS stack.

Additionally, as I mentioned in the previous response, MEF, TM Forum, and operators are defining lifecycle service orchestration API specifically for carrier Ethernet services. So, as the solutions mature, we will see more open APIs readily available. The operators will also start adopting those APIs instead of investing their development budget into those APIs. And as operators start adopting, we’ll see a larger merger of these competing interfaces.

Clarence: So, are there risks or rewards to winning that battle, and so, how would you proceed with your product in the meantime?

Hema: So, there are multiple ecosystem players in the SDN/NFV API development space. One of the key players is the service provider, second being the infrastructure vendors or the hypervisors, the third being the network equipment vendors, the fourth the system integrators, and fifth the standard bodies. Now, depending on which ecosystem player we are referring to, the risks and rewards are going to arrive. So, let’s focus on the rewards for the service providers.

The key reward is going to be agility, operational efficiency, as well as time to market. Ideally, what we see in the market with our customer base is, it takes around one to three months to deliver a service. Primarily because, it’s the time it takes to integrate the multi-vendor, multi-domain, and multi-cloud ecosystem. The additional reward would be cost savings, because now operators will be directly able to use these readily available APIs. The risk is because of the lack of availability of these APIs due to the IT overhead and the vendor locking.

Clarence: So, will the open APIs get its entrance to carrier-grade network solutions, or will it be vendor-developed API?

Hema: Yea, so open APIs in the network virtualization industry have gained adoption primarily because of the white-box appliances, but we still see issues related to security and then being carrier-grade. So, with Microservices architecture, we think both can be used. Vendor-specific APIs can focus on inter-component communication, whereas open API initiatives can focus more on the user-driven service and capabilities.

Clarence: So, what are the key drivers for open API initiatives?

Hema: So, we see three primary key drivers. One is the digital transformation. Within digital transformation, it’s customer experience; it’s internal operations; and of course, the partner channel management. The second key driver is a 5G related network transformation, and the third is the IoT services. So, together these three drivers are pushing for adoption of open API initiatives.

Clarence: Well, we’ll have to have you back and talk more about the war as it progresses through. Thank you, Hema Kadia, for being with us.

Hema: Thank you very much Clarence. Really appreciate it.

Clarence: And thank you for watching. We’d like to hear from you. So, reach out to us on Facebook or Twitter and you can also see more videos at TIANow.org and on our YouTube channel.

footer logo

Log in with your credentials

Forgot your details?