Convergence of NetOps and DevOps – Yousuf Khan, Cisco

This is texturing TV. Hey guys. Thanks to the throw.

We're here when you subcons vice president technical marketing for Cisco. We're going to be talking about all things related to apis networking and infrastructure. You said welcome the show.

Thank you. Mike. Glad to be here.

One of the things we are seeing is that developers and devops teams are getting more access to the underlying Network infrastructure and also the compute and storage and everything else through apis. As that happens. Do you think that the way it teams are structured is going to change over time?

Because we're not asking everybody to master some graphical user interface per se we are giving them a little more control at the developer level is more things ship left. So what's the ultimate impact? You're absolutely right Mike.

I think that is already a change that we see in the it organizations and also not just it organizations in our customers but also in our own teams that there is a shift from the traditional networking experts to more devops type of expertise that we're looking to bring on board and this is reflected in the same way in the it organizations of our customers. We're customers are bringing more devops capabilities within their teams that can bridge the gap between the typical networking operations Paradigm as well as the development, right? And I mean given this trend of consuming API for the infrastructure management is definitely fueling this requirement of bringing in more devops capabilities within the environment and then on top of that you also see that there is a little bit of learning the Lions of the traditional networking of security office versus Cloud off sources devops.

So there is a convergence that is taking place and the speed of convergence is definitely different in different entries and different customers based on Are Comfort level but that is definitely a trend that we are seeing and as I said like I mean, we not only seeing it in our customer but this is also reflecting in our hiring practices within the vendors within the companies were developing the tools and these facilities for our customers also. This is that mean it will just be a team sport or a different type of team sport or are we gonna see the emergence of some sort of super administrator that uses apis to manage everything just exactly how will that team get structured or can I narrow it down or a handful of people? so I think this all as I mentioned that depends on the from Enterprise to Enterprise from customer to customer and that also is a factor of Where they are coming from I mean are they coming from traditional network operations perspective of their coming from more of a like?

Okay. This is how we manage our server infrastructure. And this is what the same as practices that we would require on the networking infrastructure site also, so which end of this spectrum they are coming in from and what expertise they have in the team so that that is the deciding factor and how they're adopting these practices and how quickly they are moving in that direction.

Also, I mean, definitely we see our customers given that we have customers on all all end of these spectrums and everywhere spread across this spectrum also, right? Is that changing the economics of it? Because it seems like we should be able to manage more at scale using the same number of people that we traditionally had or with boats with slightly different skills, but it almost feels to me like we have more compute resources and capacity than we can currently manage.

So we just need a different approach to do it. more efficiently I think and again you already brothers that this is a response to the edit complexity that we see in the it environment today, right and given that how our environments are progressing how applications are progressing given like from Mainframe applications to distributed Computer Applications to microservices to the Advent of public Cloud first then private Cloud then hybrid Cloud Mar Tech Cloud. I mean the environment is getting more and more complex and the Opex of these it organizations are not increasing or matching up the complexity that they are required to manage.

So as a result automation as a result infrastructure as a court at the necessary elements that they need to adopt in order to scale themselves and match the complexity of the environment that they're required to manage. So I think this is absolutely necessary and for the it organizations to adopt these best practices so that they can manage the complex environments because I mean, this is the conversation that I have with many customers about the shadow it because Organizations which are not able to manage and top these best practices. They see that people swiping their credit cards from the development side and then building a shadow it infrastructure and managing it themselves.

So I think this is definitely necessary tool set that everybody should adopt to be able to manage these scale. How does this manifest itself for Cisco you have a Nexus cloud and a bunch of apis but one exactly does the developer see when they go use that. So I think from a manifestation in Cisco perspective, I mean, we have a had a very strong Focus for the last like I would say five or six years.

I mean with the start of sdn or the start of the portfolio that we started tripping back in 2014 and and very strong focused to us programmability. And the first thing we opened up is all the different programmability interfaces and API then we start building some Automation and we started building some out-of-box Integrations so that we can offer it to the customers. So yeah given that We had we had this Focus right from the very beginning but then we were like looking at okay how quickly customers are adopting it how quickly the tool set and the ecosystem is maturing for us right as a result.

Now, I mean where we see some of the customers who are very very advanced in adopting the devops as well as infrastructured escort practices and not only they want to consume the API and your question about how what customers see is like, I mean, for example when developer is quoting an application and they're like, I mean instantiating a VM they want to be able to use the underlying networking infrastructure also in the same way as they're using a VM and they should be able to call those resources and when they are done using that application and they decommission their application, they should be able to decompose that infrastructure also, so that is what we are doing and from a development perspective from a rendered perspective. What it means is that when we are developing these tools and these resources and the products. We have API first approach, right?

And I mean I have used this word in API first approach and somebody asked me the other day. What is that mean that you have an API first platform what it really? Means is that we develop the API first before we develop the buoy on top of it or a user interface on top of it.

And anything that we developed in that user interface or a GUI is basically using the API that we made it publicly available and we don't stop it over there. But we also make sure that all the features in the API are clearly documented and examples are there so that's customers can consume it easily. Also we maintain the examples we maintain Court sample.

So that customers can easily adopt it. So there is a very very strong emphasis in making sure that it is an API first platform and second thing is that it is clearly documented and making it easy for customers to consume those apis also. Do you think this is becoming more important as we move to more modern application environments?

It seems like they're a lot more latency sensitive using microservices and developers need to have more control over the network bandwidth because it actually has a direct impact on application performance. Well, you had absolutely right. I mean this is one example, I mean, but it is also I mean for the I mean other use cases which is I mean, everybody is demanding agility, right?

I mean as applications are getting decomposed into microservices and those microservices are at different places within the environment whether it is sitting on one public Cloud versus the other public Cloud versus on-prem, I mean There is an expectation from the network that networks should be treated as a single entity whether it is on Prem. Just like I mean customers are the developers are using microservices and they are like able to exploit those different Services irrespective of the location. They want to use the networking elements irrespective of where they are setting whether it is on-prem or within the cloud also and all the attributes that we offer whether it is a throughput it is it is policy but it is segmentation whether it is bandwidth.

All these elements should be available to the developers based on the application characteristics. They should be able to manipulate and manage the networking elements underneath We hear a lot about service meshes these days. I'm not sure many people are using them just yet, but I'm curious from your perspective.

Where does that fit in this equation? Because some people are looking that that is like the new single abstraction layer to go and vote all these different networking services. So when I use the API will I use the service mesh as the service mission instantation of the API walk us through it a bit.

I think it's a very good question Mike and I think we also reacted to the initial. The demand and initial at the introduction of these service mesh that look service mesh would be the new way through which the network should react Network should be able to reconfigure itself based off the changes within the application layer and service mesh is a way to get it done and we did base Integrations with the leading service mesh, but what we have not seen is is a wider adoption from our customer base towards that so while we are ready on our end and we have done some Integrations with surface a couple of the leading industry leading service measures. I mean, we are waiting for customer use cases.

We are waiting to understand how customers are going to adopt this technology so that we can build more on top of it. But at the moment I think there is a little bit Slower than expected response from the customers towards the adoption of the service mesh as means of manipulating Network underneath underlying technology. There's no joke that says that the one thing that an IT administrator and a developer can agree on is that it's the network guys fall.

So the question that I would come back with is how smart is the network gonna get I mean, can we just get to the point where we'll declaratively say, we need an application that has these attributes and performs to this level and then the network will respond or how much expertise do I have to have to really optimize the network. I think it's a very very good question. And that is one of the design principles that we have and we are designing Nexus cloud.

Is that how quickly we can give the we call it like I mean Go to innocence for the networking admin that because as you said I mean every problem is the network problem whether the applications is slow whether the application has a reachability problem everything comes back to the to the network and how how quickly we can able to identify the networking components that is being utilized by a certain application. And what goes through it. What is the route it is taken what the true code bandwidth packet drops that is happening along the path of that.

I mean if there is an unreachability is an unreachability because of a routing issue or there's an unreachability because there is a security configuration. And again, the engagement is sitting on Prem or whether it is setting on public cloud or hybrid Cloud environment as you said earlier. So how quickly we can give the power give the visibility to the network that men so that he can quickly trace the path of an application and see what all going on within the network all so and then second thing on top of it.

Is that how we can do the integration to other assets. Gives you visibility into the application such as app the right and like for example with aptly integration that we have done on the Nexus platform and that's going to be available on Nexus cloud in future. Also, you can quickly identify that for this given application.

Is there a network problem happening or not? Right. And then again the second step is that now we haven't done integration with elements such as service now.

So if there is an problem then how quickly you can create a ticket and then automate that process also, so there is a lot of effort. I mean if I mean, I would love to give you and walk you through that's Cloud one day so that we can tell you that how quickly I mean we have a concept of network and normally is that you can identify that look there is a network anomaly for on this application path. And this is three pieces of information that we provide you that what is the impact who is impacted and how we can solve it quickly.

So again, this is like path to innocence but enough since this is all we are doing is that this anomaly is causing this in this If this Leaf has this application running on it, and this is the integration. We're happy integration comes into the play and then how quickly we can resolve it was the recommendation. So there's a lot of effort that is that we are putting in that place.

Do you think this shift-to-edge Computing and there's multiple flavors of edge but as we put more workloads out at the edge will force a lot of this conversation. A lot of these issues to be resolved because the it environment will be more distributed than ever. It is this but I mean if you'll go to like for example the 5G environment the Telco environment, it is extremely distributed at that time.

And there is a lot of like Edge Computing that is taking place and in the in the 5G environment, but at the same time then again there is a need for uniform governance policy connectivity model and visibility across the distributed sites as well as the central side, so I think and the only thing that in I see that becomes unique in a distributed environment is the scale because now we have customers and especially the service providers who have thousands of these remote sites hundreds of these remote sites and they want an aggregated View and they want to make sure that when they they apply a policy it is uniform across that and they want to make sure that they have visibility across all those sites. So the networking problems and the networking Solutions are similar except that now we have to scale it a whole whole much What is your best advice to folks then about how to get from where they are today to this Brave New World that we're moving towards. How do I get started?

What do you see customers doing? And what do you wish they knew beforehand so they didn't run into a gotcha. Well, there's everybody really good question.

And again during our conversations with the customers. A lot of customers ask us that look I understand. I want to adopt these best practices.

How does where do I start? How do I how do I do it? Right and my answer is always that look.

Okay. com. But this is weird we take you step by step in terms of what is infrastructure as code means to you.

Right how you can adopt these best practices. How what is API gives you how you can adopt some of these best practices around apis what Integrations that we are delivering out of the box because automation is something that we have tools that deliver out of box automation, but there are things that we make you make available on our platforms that can help you build custom integration such as we have sdks for Nexus Cloud which python as well as go online SDK is so that customers can build custom Integrations on top of the automation that we deliver on the platform out of the box. Similarly.

I mean, we have indications that we have built in with and simple from redhead as well. Terraform from hashikaur. So devnet is the place where we I asked the customers to go because this is where we have code examples.

We have sandboxes they can try it before even they purchase those solutions. They can try it in a safe environment and there we have keep the boat samples also, which is maintained as well as built by Cisco professionals. So that is where they should start and they should try to experiment it and build the skill sets within the organizations so that they can harness the power of automation harness the power of infrastructure as a code to to keep up with the complexity level that they have in their environments today.

All right, folks. You heard it here first. It's taking a while but netops and devops are finally coming together Yusuf.

Thanks for being on the show. Of course, my pleasure. Thanks for having me.

All right back to you guys in the studio.