 So I see a bunch of F5 people in the audience. If you're not an F5 person, put your hand up. Good, we'll talk to you. You automatically can have a stress ball because we have a lot of them. Very quickly, over the last several summits, we have come and talked to people about how a company that is as brick and mortar and service heavy as F5 deals with the cloud migration and specifically open source pieces. We've given you conversations about how we've moved to GitHub, how we're doing collaborative development with our customers. We've talked about how you do full-opt deployments with our virtual edition where the ADC functionality is embedded in the single tenant right next to the app. We've talked about operational deployments so you can do service-based scale-out of even North-South gateways. And our management looked at us and said, you're getting into the weeds too fast. And they wanted to make sure that the messaging came clear. So they said, please put this slide in all of your presentations. So this is the obligatory slide. You will notice that F5's message is very clear. 85% of enterprises are committed to a multi-cloud strategy. So no matter what I tell you, we have to figure out a way if you want to utilize F5 functionality to put it in the cloud of your choice. But having said that, we have our own thing called state of application delivery that we talk to. And when we talked to 2,300 of our customers, we found out a couple of things. We categorized their work in getting to self-service cloud. And we can argue about the phases, but we kind of put it in their terms. And when we asked them, it became very clear that there was indeed an impedance problem or there was a barrier for them getting towards cloud deployments. It didn't matter if it was infrastructure or service or platform as a service, 61% of them are in a phase where they have between zero to 25% of their workflows in cloud. Again, it didn't matter what kind of cloud, but that means a huge enterprise backlog of workloads are still trying to find its way into self-service, still trying to figure out how they end up taking this journey. Now, for us, we also found another interesting thing in here and we've experienced this when we talked to our customers. If you've noticed the way people answer the cloud surveys now, two things have come to the fore. Used to have a lot to do with cost and used to have a lot to do with things, but the big important things they're stating now across the board is they want agility and application deployment and they want the ability to introduce new technology in their application stacks. They want to move very, very fast. The problem is, for the last multiple decades, whenever we had something that didn't fit inside the app team, either because it was an ISV based app or the app team wasn't going to build that functionality into the application, what did we do? We threw it at the network. That's why you have things like application level firewalls. That's why we didn't build those things directly into the application. You said this was a function that had a separation of concern and it was somebody else's job to worry about putting together the security profile for that application. So what do we do? We've got the demand for agility. We've got app teams who are sitting there saying that they're going on this journey to go as fast as they can to deploy and as fast as they can to introduce new technologies, but on top of that, we've got the inertia of corporate governance. We've got all of the policy that has to stay in place. We've got all of these things that say you have to pass an audit. We have all of these things that say, by the way, if I'm gonna move a workload from existing deployment into a cloud, I can't just throw away all this governance, all this policy. So what do we do? Again, the problem's this. I want the agility to deploy the applications to do service decomposition, to do cloud-first methods, even to get into an infrastructure as a service cloud, but at the same time I have to support corporate governance to let the slow side be slow where it should be methodical and it is a policy decision, but let the fast side be fast. Does the problem space make sense? Because again, enterprise is struggling to get into cloud. So what are we gonna do? Well, it depends on what APIs are available to us. If this is, this is OpenStack after all, what are we gonna do inside of OpenStack? Well, for a long time now, we've been supporting Elbez and we've been supporting the Elbez V2. We're going to give you an API that's called only through OpenStack because the developers get the API they want and yet we're going to have a way for them to clue in the provider policy in such a way that corporate governance can still control the upflow. If it's not OpenStack, let's say it's Kubernetes or MeSos that are doing that, guess what? Again, because we know we have to deploy in multiple clouds, even in public cloud, we have to have a way to inject this same point of control to give you back corporate governance. If not, we have this built-in impedance of decades of inertia and policy that is impeding enterprise from getting into cloud. So let's talk about the OpenStack solution for just a second. This is clearly targeted to folks that want to do infrastructure as a service. We know we have the Elbez V2 API, so what do we have to do to do this? You have your components down there. The first thing we have to do is we actually have to support orchestrations to put in the corporate governance policies. So you'll see us do things where we have a lot of Ansible modules. We have ways for you to orchestrate these things. What's the speed of this orchestration? It's slow. It's supposed to be slow. It's supposed to be methodical. You don't change crypto standards every day. These are the things that support corporate governance. But once that part's there and once that infrastructure's there, what did we promise to the app guys? Agility, using the API they wanted. So what do they see? Well, they see neutron APIs. Why? Because you don't want your app teams changing corporate governance. We've had a separation of concern for decades and we have a separation of talent and we have a separation of expertise that still needs to be maintained to pull enterprise into cloud. So again, my developers, they build a load balancer using the typical OpenStack APIs. They build a listener. They build their pools. Nothing new yet. They use the L7 policy. And we're gonna show this. They use the L7 policy and the point of the L7 policy is to simply create a named-based tag that they can tie the application flow into corporate governance. Because should they, again, should they be able to change this? No. But they want the agility to be able to self-service deploy the application behind these services. So let's go ahead and look at this in action. And let me entice this. Now, here's our box that's doing corporate governance. So this is at the edge. This is the box that's doing Elbez. Notice I didn't even start with OpenStack things. I'm showing you things the box does by default. For instance, DDoS protections. If your corporate edge in your cloud doesn't have L3 and L4 DDoS protections, even in locally, get rid of it. These are protections that get taken care of for you because you're using a box that's providing corporate governance. Let's go a little further into application level policies. Here I'm gonna show you what we call traffic policies. I have a couple just to illustrate what we can do. This one is a no export policy. So this is an application that you cannot allow access outside of the country. This is huge in finance. This is huge in places where things are exported control. Notice this one. Build in GOIP databases so that this application can pass the audit because you've actually have something blocking all client IP addresses that aren't from North America. Again, corporate governance. Does the app guy care about this? No, separation of concerns. Let's go even further. This is a policy concern. See this one? This is an exploit for Ruby on Rails. It got blocked at corporate governance so they didn't have to update the framework. Look at this one right here. We're injecting JavaScript dynamically so that you can do debugging by injecting a rule directly into the application. Let's look at this one. This one right here, make sure that when your servers have 500 errors, no matter what the application, they don't leak the stack so that they can get exploited. We rewrite the stack so that they don't leak data. This one right here, I use this to show you the thing called a data group. This is kind of a contrived one, but you can do complex policies. This is a lookup table. It could be a half a million records. You could do a very complex policy for corporate governance to pass audit, to be able to secure the things. And again, these are all maintained as part of the ESD policy. Now we're gonna shift over to OpenStack. I already deployed the Elbas piece, and here it is. You notice I changed it to a tenant folder because it is separated, it is multi-tenant. But again, it's really kind of boring. This is Elbas. This is vanilla Elbas. They just deployed it. Now I'm gonna shift. You'll notice it doesn't have any interesting rules on it, no interesting persistence. It's just kind of there. That's Elbas. Now I'm gonna shift. Notice this is my ESD definition. And you'll notice it's a JSON policy. Why? Why don't I show you a GUI? Because we want the app developers to be able to move with their tools. We want them to do CI CD. That doesn't lend itself to CI CD when you poke a GUI. Notice the different ESDs. They do different things. They apply different things based upon tags. Who sets these tags? Corporate governance. The app guys only know that they have to live behind the policy. They don't know what's all in it. Now we're gonna deploy this one called DMZ Mobile. It's kind of complicated. It's got a bunch of rules. It's got policies associated with it. It's got L4 optimizations. It has corporate crypto standards built into it. How does the application developer and put that policy onto their application? They use OpenStack APIs. Why? Because that's what you want them doing. They want the agility to be able to use the self-service APIs to do it. All we're doing is using the community supported LBAS L7 create policies. And notice here's the magic, ready? All they have to do is tag it with the policy that's named with the corporate policy. When they tag it and we're gonna put, you have to put a default action on it. We don't really care. This is getting taken care of on the front end. Watch when they deploy this. That's all they know. They get told that this is a DMZ mobile application deployment. Boom, they're done. What do you think happened on the front end box? Let's go look at their VIP again. Oh, it's got L4 optimizations set up for it already. It's already doing the mobile spec. Notice it's got corporate crypto standards set up. It's using corporate certificates without Barbican. It's doing re-encryption on the back end. You can't live without that in finance. Again, governance. It's got a policy put on there so it can steer traffic. It's got all those fancy compliance rules on it and it's all part of the VIP. How do you think you'd get rid of it? How do you think you'd take off all that corporate governance? You'd use the Neutron API. Again, self-service to let the fast part move fast but allow corporate governance to keep the policy. You're gonna delete it? It goes away. What do you think the big IP is gonna do? It's gonna go back to plain vanilla Elbez. This is how you can dynamically attach these policies to protect your applications in OpenStack. Separation of concerns. Let the guys worry about governance, do governance and audit. Let the guys deploying the application use the framework they want and let them run as fast as they can. Let me go back here. Now, again, we told you it had to be multi-cloud. So what happens if you wanted to do this with, let's say, Kubernetes? We have a way for that. What do you do? Same thing. We're orchestrating the provider side of this policy, the governance side, but we do it with the APIs that are part of Kubernetes. We're not using Elbez anymore. We're now using native APIs as part of the infrastructure of Kubernetes. What does the app team see? They just deploy their application with deployment of Kubernetes and the equivalent of attaching an ESD with Kubernetes is attaching a config map YAML. They get to do what they want to do, but it gets tied in to corporate governance. So let's show you how that works. And again, I'm getting close to my time so I'm going to see if we can't get all the way through this. Notice I'm starting with Kubernetes because again, I'm tying it in. I didn't have to show you Elbez. You guys have seen us do Elbez for a long time. We have system containers that launch to give us our integration directly into Kubernetes. Notice I'm in the Kubernetes namespace and notice I'm deploying these system containers. So what happens is a little control plane gets installed on every Kubernetes pod, ties in to CNI, ties into the MessyStream. All of a sudden when I go to deploy my app, oh, I'm back to YAML. I'm back to API driven things. Why? Because that's the agility of continuous deployment. We'll put you back in. Here we started a little application that's doing a guest book with Redis, just kind of a contrived example. You see it, it's there. We can go look inside of Kubernetes and say it's running. How do we get corporate compliance? Notice we changed to a default domain. We're no longer in there. There's your application running. Now the equivalent and you'll see it on the big IP. You'll see it present. I'm going to run at a time. All they do is attach a Kubernetes config map, a YAML file that says this is the corporate policy I'm tying in to my deployment. Separation of concerns. Allow corporation policy to be corporation policy. Let the app guys run as fast as they can run. Because that is why we're on this march. Because don't forget, every time we've come to enterprise, 61% of our enterprises have only zero to 25% of their workloads deployed. The impedance isn't just the complexity of installing the cloud. We're working very hard with our partner vendors to get through that. We have certified installs where we'll come in for instance on OpenStack. We'll do the LBAS install. We'll run the Tempest test. We'll give you a report that says your cloud install is working. We can do all that work. But when it comes to the change in culture, when it comes to the corporate governance, when it comes to the part of the corporation that needs to move slow and should move slow, that needs to answer the auditor, that needs to do all of those things that's truly impeding enterprises from making self-service cloud a reality, you have to have a way to inject it. So we're going into all of our cloud infrastructures. We're looking at what APIs are available to us. In OpenStack, it's LBAS. We're attaching policy through ESDs. In Kubernetes, we're attaching config maps to put the front end. If you went into AWS, we can certainly work with, we can set up a deployment inside of a VPC. And if we can't get it to work there, we have arrangements with Equinox to where we can put things that could be orchestrated right next to your VPC inside their cloud. Again, to give you the governance you need. Separation of concerns. The auditor talks to the people he's always talked to. The application teams use the API they want, use the deployment mechanisms they want. They get the agility they want. Keep the hot side hot, but keep the cool side cool. So that we can get your app workloads moved from your data center into some form of self-service cloud. Infrastructure or POS. Now, I promised I would give three minutes worth of Q and A at the end and I'm at 320. Are there any questions? I talked really fast. Does everyone understand why we need to separate these concerns? How many have organizations where there is an impedance mismatch between how policy will be deployed and how the app developers want to push code? We're finding it all over the place. So please, come to the booth, come talk to us. We'll show you different architectures, how we're integrating in those different architectures. Even how we're putting in free, you can go to Docker right now on Docker Store and put a little thing called ASP to steer your applications even east-west so that we can steer into your governance policy for your app. Thank you for coming.