Communications & Troubleshooting Solutions Blog | IR

Value of the Microsoft SDN API [podcast]

The Microsoft Lync SDN (Software-Defined Networking) API allows developers to build applications and services to monitor, isolate and correct issues that affect the user experience on Lync / Skype for Business. 

In this episode from the IR-Podcast, Eric Bauer, Global Head of Product Marketing, discusses the benefits the SDN API brings and how it is being used to deliver outstanding Universal Communications experience.

Audio Transcript

Scott Baker: Network administrators may have questions about Lync SDN API and it's compatibility with your environment. Here to discuss that is Eric Bauer, Global Product Director with IR. Eric, what value does Lync SDN API bring to the table?

Eric Bauer: Boy, that's a very broad question, but I think it's one that you really need to separate out to be able to answer. The Lync SDN API started really as the Lync network diagnostics API. You've seen there's been a change when it comes to naming and there's a reason for that change, but now if you look at it, there's three different areas that it really provides and adds value. One is in the diagnostic capability. The other is automated quality of service, or the quality of service to the area and then the third is really orchestration.

You can take each one of those individually, the one that we, as IR focus on is around diagnostics and bringing tremendous viability in a very scalable and centralized way to the table.

Scott Baker: What are the impacts on the network?

Eric Bauer: You know, that's a question that we get all the time. When you start talking about SDN, people get scared. It's this hype, it's kind of like WebRTC, it's something that's hyped out there and people don't really know, so they're a little bit leery of it. We continue to get that question because we base a lot of our capabilities around the SDN API and a lot of the response we get is, you know what, SDN, I don't do SDN on my network, but if you really look at it and you look at the various roles and you focus on the diagnostic role, it really has very little if any impact on the network.

It doesn't do anything to your network, it doesn't change anything. What this particular role does is provide a highly scalable access to information that's already collected today. Realistically, in the customers that we've worked with and the environments that we've deployed, some of them being exceptionally large, hundreds of thousands of phones, there's little to no network impact.

Scott Baker: When you talk about diagnostic, are you talking about the identification and resolution of problems?

Eric Bauer: That's where it starts, so it starts with the diagnostics and it starts with the understanding and the identification, the quick identification of problems, and that's really what that role's for. The automated QOS and the orchestration is really then taking that and being able to solve it. They're working with a number of network vendors to be able to do dynamic QOS policy and that's something that continues to crop up, so when a problem is identified, they can make dynamic changes to the network here to smooth out that problem. It really starts with diagnostics. It starts with understanding and identifying the problem and then moves over to that automation and that orchestration.

Scott Baker: What are some common problems that it usually see and identifies and eventually fixes?

Eric Bauer: You know, latency is a big one, right, so congestion on the router or on the network paths and being able to dynamically change the route that a particular call or a particular interaction's taking. I think it's probably the number one issue that we see. Some of it has to do with policy settings on the network where things change. Policies were set up to handle quality of service but not necessarily executed correctly and so I think that's probably the number one issue that we see is that latency and just congestion in the network that requires an alternate path to make the highest quality communication.

Scott Baker: You said before that some customers are a little bit wary or unsure, are there downsides, are there risks involved here?

Eric Bauer: You know, we haven't seen any risks or downside. Speaking from our solution, we rely on it heavily, so it's probably a pretty expected answer from my standpoint. It continues to become, we're up to version 2.1 now, and it starts to get more and more integrated. We expect with the release of Skype for Business even further integration. It's a real foundation piece of capability from a Microsoft standpoint. In fact, they recently made some structural changes within the organization to bring the development teams for the SDN API under the overall Lync or now Skype for Business teams to make them more integrated instead of having two different teams.

As it becomes more integrated, the risk becomes even less. It's something that's going to be installed by default, turned on by default. It's not something that requires after the fact worker activity, but again, we haven't experienced any risk and I think that's going to continue to lessen over time. You know, I think it's a really powerful aspect and something that again, has a lot of misunderstanding. Not a lot of great messaging yet around what Lync SDN API can do.

I think some of the key things, especially in the service provider market that are worth highlighting is the fact that by leveraging this and the other capabilities or the other data exposed within Lync, you can really drive end to end visibility from the application layer, the communication layer, all the way down to the network layer without probes and taps and for those of you who know and understand some of the challenges of the probes and taps, they can really start to see that value. It's a non-intrusive way to collect and pinpoint problems within your environment very, very quickly.

Scott Baker: For more information about performance management solutions, check out the resources available at IR.com.