Cisco Systems, Inc. (CSCO) Earnings Call Transcript & Summary

Welcome, and thanks for joining. My name is Bob Everson. I'm Senior Director of 5G architecture at Cisco, and I'm happy to be here to discuss the transition to cloud native and how to prepare. I say I'm glad to be here, but of course, I wish we were all in-person together. I'll miss the live interactions and discussions. But given the situation, I think this is a great scenario. I'm honored that you joined me, and I look forward to some interaction during the session. Now no self-respecting cloud native presentation would be complete without containers, right? And then this picture, I'm especially proud of because it has both containers and cloud. So it seems like my job is done here, and this is all you need to know. Now kidding aside, there are great reasons why the container analogy fits so well and shipping containers are even in the Docker logo. Containers transform shipping, dramatically lowering cost, increasing efficiency in spanning new industries and containers and cloud-native technologies are doing the same to service delivery and operations. And in hindsight, it's easy to imagine why containers transform shipping, moving from a world of hand-loaded cargo that was terribly slow, costly and inefficient. But that way has been for many years, and there was a lot of inertia in that. So I can imagine that people back in those days didn't even envision the change that containers would make. And I think we're in a similar state where containers have been well used in the cloud world and in the application world, but as they're moving to networking, we're just starting to imagine the impact that they're going to have. And it's important to note that the container is only as useful as the infrastructure that it runs on. So one of the fantastic things about shipping containers is you can use that same container, whether it's traveling by ship across the ocean, whether it's on a truck, going down the highway or whether it's on a train going down a railroad track. And so it allows that portability across the various mechanisms of transport. And maybe even more important are the changes across the entire ecosystem that were required to support this. Operational systems are critical. You need a way to move, load and offload these containers. You need a way to inventory the containers, both the containers themselves and what's inside the containers. And you need cranes and you need automation to actually make all of this work because there's so many there that it can't just be managed by humans alone. So it actually has to be orchestrated across the full life cycle of a container. So it is an accurate analogy to say that the cloud-native software function is a shipping container for digital operations. And it's also important to note that the real benefits require changes to the full ecosystem. Which takes me to my next point, cloud-native success is more than just the technology. It's more than just the platforms that it runs on. And we like to talk about technology, and that's a lot of what I'll discuss today, of course. But the other 2 pieces are equally, if not more important. It goes nowhere without the appropriate processes and people aligned for success. So let's look at a quick definition of cloud native and just point out a couple of things here. This is from the cloud-native computing foundation, which has done some great work around organizing and standardizing this community here. So it's about technologies that empower organizations to build and run scalable applications in public, private and hybrid cloud, so multi-cloud. There are a bunch of terms here, and I'm going to define a few of these on the next page. They enable loosely coupled systems that are resilient, manageable and observable. And then combined with robust automation, you can make changes frequently and predictably with minimal toil. So this enables a lot of the things and a lot of the benefits that we see in cloud native. Containers, of course, are a lightweight stand-alone executable that has everything packaged in it that's required to run an application. They're highly portable, just like the shipping container is across different deployment targets. Another important concept is a microservices architecture. So this is breaking monolithic applications down into individual services that are individually deployable and loosely coupled and maintainable, so they can have a separate life cycle of their own. So you can have rapid, frequent and reliable delivery of complex applications in modular channels. CICD is another popular term, continuous integration, delivery and deployment, where you can automate the integration, validation, release and even possibly deployment. And I say possibly because sometimes deployment goes down a little bit different stage of the cycle. But ultimately, the goal is to get all the way through to deployment, and it's very possible. And then the last one that I wanted to talk about briefly is DevOps and SRE. And so they're related, but they're not really the same thing. DevOps is about shortening the development life cycle for software and providing that continuous delivery with high quality. And so it integrates software development and operations together. SRE, or Site Reliability Engineering, is like taking software engineers and putting them on network problems. So this is about engineering maximum system availability, observability and scale. Now let's look at the evolution of platforms over time as we move towards containers and cloud native. We started with dedicated hardware, originally PNS, physical network functions, and then software functions running on top of dedicated hardware. Then along came virtualization and OpenStack. We started running VNFs inside of VMs. This allowed operators to virtualize the hardware layer and the compute, storage, networking and then package and application inside a virtual machine. Now that packaging is a bit heavyweight because it actually has the operating system and other components inside of each one of those virtual machines. So as you instantiate VMs, you end up with quite a bit of extra overhead inside of that VM. However, it's worked very well for applications and has helped us move into this virtualization domain. Next came containers. And we've discussed some of the benefits, and we'll spend a bit more time on it. But containers are fairly new in the networking world. And so we're still developing a lot of the required functionality for networking, for security. And so -- and also, a lot of the virtualization infrastructure has already been deployed. So a lot of people are looking at this and saying, okay, maybe I'll deploy containers inside of VMs. And so I can do that as sort of an interim step or to combine environments together. And then finally, we have containers on bare metal, which is sort of the ultimate. So you just have the host OS, the containerized system allows you to virtualize that OS, and then you can run multiple applications on top of it. So the question is, now do I only need 1 horizontal platform where I just have my OS, hardware and then I can run as many applications on it as I desire? Well not exactly. And I'll give you a couple of reasons why. Let's start by going back and looking at VNFs and OpenStack. The original vision was of a horizontal stack that was going to support and serve multiple VNF workloads. The reality that we've gotten is that, in some cases, we have multiple workloads running on top of one OpenStack system. But in many cases, there are vertically integrated stacks by applications. Now why is that? Well I would suggest that integration was underappreciated as we moved down this path. And the importance of integration, in some cases, all the way down to the NIC card level. Some of these applications actually require very specific performance down at the -- all the way down to the NIC card, all the way through the stack. And so it's required a lot of integration for the vertical system. And then as we look to combine across, it added another layer of complexity that was underappreciated. Could it be done? Well certainly, but it adds incremental cost to the overall solution and another layer of complexity. So we haven't really gotten to the full vision of OpenStack and infrastructure as a service. The next point, which is equally as important or maybe more important, is that these workloads have different requirements on the network. Services and infrastructure workloads, whether it's business services, SD-WAN, network slicing or whether it's a decomposed, virtualized 5G RAN, we have the 5G core, these all have dramatically different requirements on the network and on the underlying infrastructure, whether it's for performance or security, management, access, all these different components. And so does it really make sense to try and extend one infrastructure for all these different types of workloads. And then, of course, there are also a lot of options. This is, again, from the cloud-native computing foundation. They've done great work in this space. And you can see there are a lot of different options for each one of these modules. You may be able to see this slide. It's a bit of an eye chart, but you can go to our website and see it. Whether it's the components or whether it's the deployment models and what it's going to run on the cloud, there are a lot of different options that can be optimized as needed. So the question comes, how do you want to? Or what is the best way to consume, deploy and manage applications? We've provided a range here from a customized private container platform on-premise, where you have the maximum choice. It's typically a private solution there on site. But you have to be very, very involved in the development process and in the management process. The next step is a CaaS, or containers as a service, where maybe the lower layers up through the operating system are offered as a managed service. And so you don't have to worry about that. And it gives you a platform to run your applications on, all the way through to Software as a Service, where the environment is fully managed by somebody else and you're consuming an application. And typically, these are going to be in the public cloud. Now CaaS can be public or private, hybrid scenario. SaaS, typically public, although we've seen some private SaaS offerings as well. And my view is that most of the implementations are going to be a combination of all of these. We're going to see all of these there in deployments. And the DevOps implications are interesting to look at. So in a CaaS, you're going to have more of what I would call a coupled DevOps environment where the vendor and the operator work together on the DevOps processes for deployment and engineering. On the other side, the SaaS model allows for a decoupled DevOps. When you're just consuming an application, then the vendor of the application implements their own DevOps processes, and you don't have to worry about that. You're just consuming the application. So again, we're going to see this across both of these models here and across the full continuum, I think, and each one of them has value for -- in different ways. Moving over to people and process to some extent. Melvin Conway back in 1968, over 50 years ago, coined this law that says basically an organization will design a system that looks like the existing organization. And it's really powerful to understand this because sometimes it's hard to invent and break inertia in an existing organization structure. So how do we leverage Conway's law for reinvention and transformation that we talked about was required earlier across the entire ecosystem? Well, there's 2 approaches that are suggested here and proposed. One is an inverse Conway. So if we agree that it holds that your systems are going to reflect your organization, then maybe you start to break team -- build teams, break them out into different groups, to look like the architecture that you want. And we've seen customers and companies who are doing this with some DevOps groups. They're doing this with some groups in functional areas where they actually start to split off, and then they'll start to build the architecture and then migrate people around the organization. The next point is what I would call a reverse Conway, which says, let's architect the system and then align the organization around it. And I think this one is more common in my experience. And the important point, though, is to understand the tie between the organization structure and the system you develop. And of course, it's important to leverage the best of both worlds. I think a lot of people get confused and they say, "Oh, it's all about the cloud, and it's all about cloud operations," or "it's all about telecom." But telecommunications companies have been successful for decades, building networks, operating networks and successfully delivering services. Cloud operators have been successful for many years as well and have invented new ways to do things in the cloud with software. And so the ultimate win is the meld between these 2 worlds, where you can deliver richer services on a more agile infrastructure with more profitable operations. And there's a sweet spot there in the middle. You get a bit of both. And as we migrate from legacy systems on to new systems, we'll see that sweet spot shift a bit. But it's absolutely about bringing the 2 worlds together, and I think that's where the real power lies. In conclusion, just a couple of points. One, delivering services as a mesh of cloud-native components does give true flexibility. It gives you a lot of options, gives you that agility in your infrastructure and to optimize service delivery and to optimize operations. I would beware of one size fits all. There's a lot of magic dust that people purport to sprinkle around there. There are options, and these can be very simple to consume, if you pick the right option for the problem that you're trying to solve. The technology alone is not enough. We do need to think about people and processes. And ultimately, it's about multiple deployment models and cross-domain experience, leveraging that cross-domain experience. It's got to go across the entire network to integrate this and unify. And with that, I thank you for your time, and I look forward to, hopefully, some questions that will follow. Have a good day.