 Right, that was an awesome talk by Margaret, by the way. I can tell you only one thing about my talk is it's going to be substantially different from how Margaret's talk was. If the question is delivering microservices, and what do you need from the network to deliver microservices? I think the answer is software-defined data-driven network functions. Now, I know what a lot of you are thinking at this point is that that's the mouthful of buzzwords, and this must be a CTO on the stage. It's partly true. You can laugh if you want to. It's partly true. But really, the dead giveaway that I am a networking CTO is the use of the word software-defined and network on the very first slide. At this point, this is the first time I'm speaking at LinuxCon, and I thought that a full and proper introduction might be in order. So here goes. I am a math and systems geek. I specialize in distributed systems, performance optimization, and I do some networking as well. That's just a sense about me. I have done unspeakable things in the following kernels. You see the icons on the screen. They are unspeakable largely because most of the work I have done in my life has been closed-source. But the company, my employer Citrix, and by inference myself right now, we are involved in over a dozen open-source projects. Here is a sampling of some of those projects on the screen that you see. There are several others that we work in. Octobu is the most recent one in the area of IoT. And I'll start still as part of my introduction and share with you one of my most favorite lines of code from the Linux kernel. And what this line is doing is it prints a very scary-looking log into Dmessage from time to time. And the conditions under which this log gets printed is one of those things that very few people, especially the ones who understand networking deeply, can describe or understand. And so it makes me feel important and elite. And that's why I like this line. I have been tracking this line for several years. And what happened about... Maybe in 2008, this happened, is that they changed that line to something far more ordinary. So no more would this thing creep up on an unsuspecting sysadmin and claim treason and cloaked. It would just say something far more benign. And that day in 2008 is when I knew that some very serious chickens and people were doing some very serious things with Linux. And I knew that day that we would have a 25th anniversary of Linux and it would be great and things have progressed almost on script and it's been wonderful. I joined Microsoft a long, long time back and I moved on to Sun for a little bit. And then I ended up at Citrix about 10 years ago. I was the chief architect for a product called NetScaler. That's a load balancer. I'll talk a little bit more about it. And this is another staple of a networking CTO. It's the OSI stack. And when I joined NetScaler, what I learned is that they had fused all of these different layers together. Instead of doing layers 2, 3, 4, 5, 6 and 7, we had a single proxy stack that I call layer 27 because it had all of these layers fused together. And in return for having fused those layers together, for having de-layered that traditional PCP IP stack, what we got was the world's fastest layer 2 to 7 proxy. So this is 100% software and cycle for cycle, it is the fastest proxy out there today. I see the same, well, similar kind of de-layering happening at the compute layer, and containers plays a big part of that. About five years ago, they took away my check-in bit and they made me the CTO for NetScaler and networking at Citrix. And these days, I wander around the planet giving talks like this one. And sometimes claiming 1 plus 1 equals 3, kind of getting distanced from my math roots. So let me bring you guys back to the topic at hand which was microservices. And what do we do for microservices? I could spend a lot of time describing microservices. I'll just say this one thing. We have as software engineers and in software engineering always strived to decouple components, to decompose them, to make them composable. And now with microservices, that notion of decoupling has now been extended to not just the design and development of software, it's now been extended to the operation of that software as well. And the thing that as networking I like about all of this is that all of these different microservices, they talk over the network. That decoupling is affected by making these services communicate with each other over the network. And that's where the requirements from a networking perspective come up. Now if you look at it at the thousand foot level where rubber meets the road, if you look at it there, there are six key things that are different about networking and microservices. I don't have time to go into the detail of this slide today, but what I can point you to is my colleague and Chiradeep who is a distinguished engineer on my team is going to go into great detail about all of these different aspects, things like cryptographic micro-segmentation. The fact that you have both sides of a communication channel in your control now, you can do client-directed load balancing, you can do service discovery instead of IP address management, you can treat north-south versus east-west traffic differently. The depth of all of these topics will be covered in great technological detail in this talk tomorrow. Be sure to attend that. What I want to do here today is to up-level it a little bit and talk about how does an enterprise think about adopting microservices and what does an enterprise need at the outset to be able to succeed with that project. The first thing that you need, and this might sound obvious to all of you in this room, but believe me when I talk to my enterprise customers and when I see how the vendors in this industry have been shaping up, it's not at all obvious. And the obvious thing to me and you is that in order to be a networking component for microservices, the network has to be in software itself. And the way I say it is that micro application services require micro network services to support them. So if the application went from monolithic to micro, the network will have to go follow the same route. So now you expect the network to also be small, independent, composable and disaggregated just like the microservices themselves. And here I introduce the notion of what I call lots of little. What does it mean for the network to be small and disaggregated? Instead of a few big boxes, you are now going to have a lot of little boxes is what it means. And here is a bit of an eye chart, but let me talk about it. I have got two graphs going, one of which is upside down. And what they are trying to show is that the data plane of microservices is becoming smaller, it's getting containerized, it's going in the direction of micro. But at the same time, the problem of managing these micro instances is becoming bigger. If you could manage 10 or 15 in the past and now you are being asked to manage 10,000 or 100,000, it's substantially a different problem at the management level. The way I describe it is with the pet to cattle transition. You guys have heard this applied to compute in the past. This is the idea that pets are individually named and individually cared for, while cattle have serial numbers. And if your cattle falls sick, you don't nurture it back to health, you shoot it. And I know you hear it from the mouth of an Indian that you shoot the cattle, but that's the way it goes. In the pet to cattle transition, you shoot the cattle. And in the networking world, the way I would like to say it is that your cattle has grown more and more stateless and expendable. While at the same time, your management system has now taken on the burden of tracking all of the state that was here to forecapped in those instances themselves. So this separation of stateless and software defined at the top and centralized and intelligent at the bottom is fundamental to the change of adopting microservices for networking. Another way to say the same thing, if you have lots of these little components in the network, you need something that will take all of their distributed state and be the caretaker and keeper of that state. And on top of something like that, a management and analytics system will be born. Now, this is distinct from a provisioning and life cycle management system of which every container management system provides some. This goes a step further. It says that if I'm going to be operating these things at scale in production, I don't just need to manage their life cycle. I don't just need to provision them and scale them on demand. I need to know how well they are operating. I need to be able to anticipate where problems might occur. It's a large distributed system. And this is a large distributed systems problem, especially when it comes to networking and double specially when it comes to networking that has to do with high availability of the kind that we build, et cetera. So with that said, here is something else which is not really a technology problem, but it is solved with technology. And I call it the power of two. And what that means is that every enterprise customer that I talk to and I say, hey, John, are you using containers? The answer I get is yes, we are using containers too. Are you using virtual machines? We are using virtual machines too. Are you using the public cloud? Yes, we are using some public cloud too. Every answer ends in a two, because as an enterprise, today they are forced to use all of these different technologies to be ahead as they undertake the digital business transformation. So the power of two is important. And the latest thing that the analysts are seeing is that operations of the traditional IT kind and of this new dev kind are very different. They call it mode one versus mode two. These are Gartner's terms. And the theory is that mode one is the traditional IT mode two, is the dev-up side of it. And these two shall never meet. These are two parallel universes, and they will continue parallely. I was talking to another customer, and he says, well, he scoffed at me. He says mode one, if you start counting from mainframes to client server to all the other transitions that we have gone through, it's not mode one or mode two. It's more like platform nine or platform 10 that we are on right now. And that was my opportunity to say, well, how about a platform nine and three quarters in the middle? Something that can be the bridge between your existing infrastructure and your emerging technology that you would like to adopt. And this bridge today, beyond containerization, beyond taking the network functions and putting them into containers, this bridge has to be built in terms of management and operations of these services, in terms of unifying the processes that the enterprise is used to with the new paradigms for software development, for putting stuff into production, for managing, for operating these things, monitoring them, and doing all of the same kind of things for the next generation of network services. That's that bridge. Finally, to summarize what I have said so far, the digital business transformation. For all of you guys, I know many of you are techies, and you understand things like Perl. So I wrote it up in Perl. The business imperative is change or die, and you have to use short circuit evaluation and you evaluate this one. It's change or die. That's the business imperative. They see all the shiny new objects. We show them. They would like to adopt them. Microservices is one of them. The way they are going to adopt them is through a bridge that we built from what they have today to where they want to take it. And finally, in closing, what I would say is this. I started out by saying that micro-application services require micro-network services. Micronetwork services are of the form that our software defined, data-driven, and network functions. And today, as Citrix, we are announcing Netscaler CPX Express. That's the fully featured version of Netscaler. It runs in a container. It's specifically targeted for people implementing micro-services, and it is completely free for you to go to this website and download. Thank you. Thank you. One question. One question I have for you is we have a whole bunch of SDN projects at the Linux Foundation, and as you are aware, one of the things that we find is that software developers who are very savvy about network architecture and how networks are built, we're having a hard time finding a ton of these people. What can we do to get more developers to care about the networking layer and the networking stack? That's a great question. You are not the only ones having a hard time finding such people. Citrix is hiring. But here is how we have approached the problem. What we have realized is that in the recent times, a majority of the innovation and a majority of the breakthrough in networking has not been about inventing new protocols or doing things faster. It has all been about making existing technology more agile. And when you think of the problem that way, it becomes even more important to separate the software-defined proxy, for example, from the APIs that anybody can use to control such a proxy. And by doing that decoupling, you lower the skills bar. Not everybody that you hire now has to have memorized the RFC for TCP anymore. As long as they can talk to APIs of the same kind, restful APIs that they are used to talking to for the rest of their application and microservices development, they can similarly control the network with APIs that are universal in that sense. Very cool. Thank you very much. Enjoy your talk.