Verizon Communications Inc. (VZ) Earnings Call Transcript & Summary

Welcome. This is -- I'm Beth Cohen from Verizon, and I am a software-defined networking product strategist for the company, which means -- to people other than Verizon, it means that I get to create new and cool products that are based on software rather than hardware. And of course, being cloud-native is definitely part of that conversation. So here, I'm going to be talking about how companies can move from physical-based applications and networking applications to cloud native and how they could take advantage of open source and reference architectures to get there. And I'm also going to talk a little bit about Verizon's own journey into cloud native as we go. So why should a telecom operator use cloud native? You think, well, telecoms are fundamentally engineering companies and they're also fundamentally very innovative. They do tend -- because they need to service so many companies, they are -- tend to be very cutting-edge about adopting new technology. And cloud native is absolutely a new technology that is just taking over. And what you have to understand is that cloud native is based on open source. So the open source community drove the cloud-native capabilities. So it -- a lot of people associate cloud native with Kubernetes and containers, but that's only just one small piece of cloud native. Cloud native is really anything that is based on the cloud. So all the other cloud native -- Amazon, which is based on -- also based on open source components is cloud-native as well. And of course, the major cloud-native cloud system, OpenStack is widely used within the telecom industry. So on -- layering on top of the open source and the cloud-native capabilities is industry adoption. And that's where industries, the telecom industry, including its ecosystem of vendors, adopts these standard reference models to further its ability to deliver services to their customers. So let's talk a little bit about building that cloud-native ecosystem. Who is part of that ecosystem? Of course, the telecom operators. And that includes the big ones like Verizon, but it also includes the smaller regionals and the smaller telecom operators within smaller countries. And then within that ecosystem, there's also the vendors. So there's the established players, the larger vendors, and increasingly, start-ups. Start-ups are the ones with the big ideas, and telecom operators have become much more willing to look at those smaller start-ups, incorporate them. Verizon just bought BlueJeans just recently, which is a relatively young company in the teleconferencing or videoconferencing space. So clearly, the telecom operators and the larger ecosystem vendors keep an eye on those start-ups as they come about. And of course, there is the other component that people often forget, which is the testing and validation companies. Those are the companies that build the tools that make sure that the ecosystem, the telecom infrastructure runs at peak efficiency. And then downstream are the enterprise customers, the systems integrators. And finally, there's the academic institutions doing their research. All of these players are part of the ecosystem. So let me just kind of give you an overview of -- there's lots of open source out there and there's lots of cloud native out there. And this is just a small sampling of some of the projects that have open source -- that are open source. All of these are open source projects. And all of them has some cloud-native component in them. I'm just going to talk a little bit about -- going to dive into the Cloud Native Computing Foundation, the CNCF. This is a foundation that really has driven the adoption of containers and cloud-native Kubernetes tools. And Kubernetes is, of course, is just an orchestrator tool, a management tool for containers. And think about it, it was founded in 2015. So literally, in 5 years, containers and the concepts of containers and cloud-native tooling has really swept the world. So the cloud native foundation has a whole system where it incubates new projects, so those are on the left, some of the new projects that they are in incubation stage. And then eventually, not all of them will be graduated to become full-fledged certified projects that are used by a larger community. So Kubernetes, of course, is a perfect example of one that's widely available. And Helm is another one, which is -- manages the packaging of the applications. But there's plenty of others, particularly around networking, because containers have -- in the early stages was really thought of as a way of developing applications, not specifically networking applications. So the CNCF has been working hard to develop applications that are focused on the needs of the telecom industry more, recently created a TUG, a Telecom Users Group, to really focus on those types of applications more. So another one to look at which is, of course, widely used by the telecom industry is OpenStack. OpenStack is about 11 years old now and it has -- it's a -- at this point, we'd call it a traditional cloud platform that supports virtual machines. So the telecom industry has adopted it widely because it's allowed it to take many of those components that were traditionally on physical devices and port them into virtual machines. One thing about going cloud-native that's important to understand is that there's a 3-step process in the migration of applications into becoming cloud-native. The original one, of course, is that many of these applications have started on physical machines, the traditional appliance, the router appliance. They then migrated to virtual machines. Fairly typically, there was not a whole lot of work around optimizing those virtual machines to work within the cloud environment, although that has actually picked up as companies adopt virtual machines and cloud more widely in their infrastructure. And then the next step is to containerize those applications. And that one, for many vendors, require -- particularly the networking vendors requires a real architecture of their fundamental application and how the application actually works. The classic example, of course, of a difficult one to bring into containers is firewalls. Firewalls are very self-contained. They're obviously very concerned with security, of course. And they -- to bring them into containers has been problematic for many of the vendors who want to go fully containerized. So personally, I think there will always be a mix of containers, virtual machines and other types of microservices in a cloud-native ecosystem. So moving along, I'm going to talk a little bit about a project that's near and dear to my heart, which is the Cloud iNfrastructure Telco Taskforce, which is a joint effort by the Linux Foundation Networking, the LFN, and the GSMA. And this really is a joint effort by the telecom industry and the vendors that support the telecom industry to really define a reference architecture for supporting cloud-native applications. So it's been a gap in the -- and CNTT has been around for about a year. There was a gap that was identified in that there was a lot of tooling to support cloud-native applications, but there was really very little attention paid to the infrastructure itself. So there was a reliance on vendors and the open source community to build infrastructure. I mean, OpenStack's been around for a while, but there was not a lot of attention paid to the infrastructure that was needed specific to the telecom to support telecom applications, so the so-called VNS. So the CNTT project has now defined 2 reference architectures: one is based on OpenStack, and now the second one is based on containers and Kubernetes. So we're very excited about this new project, and there's been a lot of interest in the community. So let me talk a little bit about how the cloud-native life cycle works. So cloud native is -- because it's not based on -- it's disaggregated from the physical hardware. The life cycle is different than the traditional hardware-based applications, where you buy a box, it sits there and does whatever it's supposed to do for however long you can get away with having that box in place. The cloud-native life cycle really allows you to do in-place upgrades and speed the life cycle of development of new features and new applications. Because the hardware is just kind of an underlying component, you don't have to invest in new hardware every time you do an upgrade. You can just do the upgrade in-place. So the life cycle really starts with those reference models, which is a very high level model, and then moving down to the reference architectures. And right now, we have 3. But over time, we'll have more as changes in the technology over time. And one nice thing about this life cycle is it does support the concept of technology is going to change over time. So the life cycle of a VM, a virtual machine, to a container is we understand that, that's an evolution and that things need to happen over time as the applications migrate. And of course, there will be something later. Who knows what it will be. But it's incorporated into the life cycle management. So moving on to a little bit more about the CNCF. It has a test bed and a conformance program. So I mentioned earlier the incubated projects and then the graduated projects. So this is the mechanism to do that. So it has a program to get the incubator projects to be certified, to be -- support the cloud-native principles. But it also has a certification program that allows companies to go in and take their applications and take their infrastructure and go through a series of tests to say that they are certified to work with Kubernetes. That gives the operators and the end users of these products peace of mind knowing that these applications -- vendor applications are, in fact, compatible with the basic principles of the underlying Kubernetes infrastructure. Talk a little bit more about some more testing and automation. And this is a very important part of the adoption of these cloud-native applications because operators need to be comfortable knowing that the applications that they're buying from the vendors are, in fact, compatible with the principles of cloud native and will, in fact, work with them properly. So there's expanded role of the open source community to have tests that -- what we call badging. I think there's a little bit of a sense of shying away from certification. But a vendor can tell that they have completed a set of tests and then the -- can have -- or badge to say that they do pass these tests and can support the open source cloud-native applications. So let's talk a little bit about how this gets translated into product. So why is it important? So cloud-native components develop more agile development. So I'll just use an example of a product that Verizon has called Virtual Network Services. So this diagram is literally how it was originally envisioned, and so it's very high level. But all the components were then created to support this, and all the components are all based on open source and they were all conceived as being built on a cloud infrastructure right from the beginning. So it's very cloud-native because it combines all those components. It also is -- you can see it from the beginning to be as automated as much as possible. So it uses automated provisioning as much as possible. Obviously, at the edge, universal CP edge requires somebody to physically plug it in. But to the extent that it can be automated, it is. And an important -- another important component is that the -- for -- that the management is also automated as much as possible. And here is the finished product. This is the architecture of the finished product. And finally, just a little -- touch base a little bit on some of Verizon's products that are -- all use these cloud-native principles, our 5G and MEC program is all conceived -- again, conceived originally in the cloud infrastructure, on the cloud infrastructure, taking advantage of the efficiencies of cloud. To be honest, 5G really has to be done with cloud. We have -- the Virtual Network Services has developed, at this point, 30-plus service chains. The nice thing is we can create new service chains as technology changes very quickly. So we have a whole program to incorporate new vendors and test. We do a full performance test suite on them. And we can bring up a new vendor and a new service chain that Verizon can back with its SLAs within a couple months. We also have, of course, SD-WAN and other types of networking tools that we've developed, all based on these cloud-native principles. So with that, I'd like to close and thank you all for listening.