All right. So, now we're gonna dig a little bit deeper into the individual networking security services, and I've got additional content out there that goes a lot deeper in the individual services. I just want to set things up for you and give you an idea of the the full scope at this point without going too deep. When networking comes to VRA, multi-machine, single-machine, none of that matters, right? We can do bindings, we do live bindings, dynamic bindings to single-machine or multi-machine in the exact same way. We'd have multiple machines, multiple applications or components that are multi-humped, title multiple networks, any combination of networks. What we'll talk about what some of those topologies look like in a bit. But the idea is, as I drag those components onto that canvas as you saw, the result of that is that nice topology until it gets requested. When it gets requested, as I mentioned end-to-end automation of all those components, and we're talking a very basic example, something that would normally take one or two weeks at least in my old environment. Some of you might know where that environment was, very strict and controlled environment. Now I'm doing it in three minutes, four minutes networking and all those great things embedded. That's game-changing. So, full automation would also extend into third-party. You remember when I opened up, I said this is not a ribbon replace proposition, right? So, with that in mind, and something VMware has stuck very carefully to, with that in mind, maybe my networking security automation strategy includes some external third-party tools, for example, IPM will integrate very natively and very well with info blocks, as a native plugin that our friends at info blocks have provided. VRA just consumes that, and you've got your IPM integration. Load balancers. Third-party load balancers, we've got plugins for some well known vendors that could now be incorporated into that design. What I'm suggesting is that this is not just NSX or go home, VRA gives you this opportunity to automate the entire ecosystem, but VRA and NSX together just make things so much more streamlined and quicker to value or quicker to market. So, consistent policy drives all of this. This is where we get past those conversations of fright, where the security folks in the room as soon as I mentioned networking and security automation, they're the first to get up and walk out and they said that just doesn't work here. But in the same breath, they're talking about provisioning to public cloud and I say "Well, what did you do there? Did you define the vendor? Are you choosing all the things you're choosing for private Cloud?" Of course we know the answer to that why. That's not behaving like a real cloud folks. Isolation, this is a big one, a significant one and it will get a whole slide in itself. Isolation means that let's take it back to that test dev use case. I'm deploying a ton of applications. Every one of those applications actually should look and feel exactly the same, down to the neck and the IP address on that neck. The problem is and what happens typically, is that they're all landing on a common L2 network, common VLAN broadcast domain whatever. While I can control firewall policy across tiers with an application or a user into the application, if I am taking that and I've built it into my blueprint, I deployed dozens of those or hundreds of those, there's still a problem of the East-West traffic, right? If I'm deploying 100 web tiers with the security posture or security policy that says protect my web tier 443 and only from the outside in, what about all the web tiers that land on that same network if I'm not using an on-demand routed network? That I've jumped ahead, I'll get to that I'll show you that. This is the path to the SDDC, and that's ultimately what we want to get to, right? We've got our networking components, we've got a lot of complexity tied into that for both networking and security, automate at end to end and you'll hear I say app centric a lot. I say app centric everything. But just remember, the application is king. Okay. The application has to be the entity that you define the security policy around. Of course you've got your edge, multiple edges maybe and those primitive firewalls that are protected. So, that's not what I'm talking about here. I'm talking about application provisioning and the security that lives right around that application. So, absent of security and networking takes you closest to the app which is the most vulnerable in this case. If I get through that edge or that perimeter, everything on the inside, we used to call it the gullion side. We've got the eggshell given to gullion side. So, these solutions together are designed to fix and solve them all in this automated way. Okay. So, the services, individual services that are exposed through VRA. So, if you're coming from a networking or NSX background or if you're coming from VRA background or if you're familiar with both, some of this might register but on-demand networks. So, give me an L2 network and just leave me alone. Essentially, on-demand networks. So on-demand netted, on-demand routed, from that, we support one-to-one, one-to-many, and we can build entire networks, multiple tiers and very complex. All in this bubble, all in this world that is app centric, and only survives as long as that application survives. Now of course we can get a little bit deeper and more technical and talk about how we can make on-demand networks persistent. Sure, but ultimately, app centric means that that application owns the network or owns its network, and then those networks survive only as the applications survives. On-demand load balancers. And it's not just about dragging and dropping and automatically configuring a load balancer, which is what we're doing here, but it's also what happens when I scale out my web tier, I automatically scale out my load balancing tier. This is painful, not just because this is solving a painful problem, not just because of the manual processes associated with setting up the vip and setting up load balancers in a very traditional way today, just myself working with customers we see that as a huge pain point, because it's typically a whole separate team and if you are on that team, there's a lot to gain here. But it's also what happens in day two, right? I need to change something, I need to change to fit vip, modify the vip. I updated my app now I have a new health URL. I need to update my health policy. Maybe I need to load balance a new protocol. All of those things just take forever in a traditional world. So, the on-demand load balancer is not just about day zero, day one on-demand load balancer, it's about the load balancer service and the load balancing capabilities and policies that are going to survive with that application as it scales out, goes into production, comes back in and it gets retired. That applies for anything I'm talking about here. And of course my favorite security. NSX went all in on security, and you know that you've probably learned about NSX and security before you realize NSX is actually a networking platform. But this is huge when it comes to app automation and cloud automation in general. When I'm wrapping that security perimeter around each and every single application, not only am I gaining all those great things that I talked about up until this point, but think about the value of all of that being undone when I pull those applications offline, or I decommission an app. I will ask you to do something right now. Think of, if you have access to it. Think of your ACLs, think of the many tiers of firewalls and the firewalls you've built either in any topology, network topology in your environment, and then tell me what happens to those ACLs when you retire an application, whether it's an old legacy physical box or a VM. Is there a process in your business, in your environment that takes you through undoing and pulling back and extracting all those ACLs, because you know what those what can happen with that later. You provision a new application or a new physical pizza box, doesn't really matter. But in this case, you provision a new VM, it happens to have an IP address of an app I decommissioned a year ago, and guess what, I've now had an old ACL that because I'm too scared to touch and cleanup and remove firewall policy, typically I'm going to wait to run into those issues before I go and clean it up. So, if I'm automating upfront day zero day one, I'm automating, modifying, those policies throughout the life cycle in day two. I also want to modify, I want to automate decommissioning end-to-end. Give me every ACL or pull every ACL, every policy, every network, on-demand or not, my load balancers, anything I've orchestrated in the environment, pull it all back so I have a clean state and I'm end-to-end. I've orchestrated decommissioning end-to-end so that when an application comes and takes its place, I'm starting over. It's very important and often leads to an attack service that you are not expecting. Anyways, I can spend all day on that. So, the security groups, security policies, they live with the application very important thing, as I provisioned it, I can decommissioning. So, just a quick highlight here, we've got our connectivity with our on-demand networks. Now, of course, we can take baby steps. We can do existing networks, and we can use NSX and deploy all biological networks in the back end and vRA will say, "Oh these networks all exists," and you can just consume them all, right? We can consume existing security groups. We can consume existing NSX backed logical networks. So, we don't have to jump all into the on-demand, all of these use cases will apply, okay? For you who are ready, it's a maturity model. It's dragging drop-on-demand. It is quite great. So, just to summarize. We've got our load balancers, our networks, our security and all the policies wrapped around this. So, here's a use case, automation for network operations. Now, when network operations itself gets to enjoy the fruits of this labor, gets to enjoy the automation that's brought with CMP. Let me reset that up, we have customers who actually have a need to drive compliance by controlling who's actually doing the provisioning of the networks themselves. Now, this may or may not be application lead or application triggered, this might be just controlling the networking and security services in a way where I can now align it with business. So, if I want to provision a brand-new network on an NSX, for example, I can actually deliver that thing as a service, I'll touch back on that later. But it also allows me to take an application topology, hand it to my networking security team and say, "Hey, built the network around this the way you would normally build it." But from this point forward, your network is blueprinted, it's versioned, it's lifecycled, it's totally controlled and you build it the way you typically build it, we're not asking you to just go about doing things in ways you're not comfortable with. So, network operations has a lot to gain here, right? You call the shots but we're just automating it when it comes time to provision. Security operations, same thing, don't have to spend too much time here, you get it, right? Then, DevOps, I've touched on this a few times already. The developer use case where I'm provisioning dozens and dozens if not hundreds of very complex multimachine topologies that can add a ton of overhead especially or manual networking security provisioning can add a ton of overhead and time especially if we are trying to pinpoint exactly which parts need to be opened, how do we modify this when we go from TestDev which would have some security posture into DMZ which have a much different security posture, what about if I start in one phase and then I provision to multiple ISO gnats or DMZ user or networks or data centers globally. If you want to, they all might have their own unique requirements and this allows me to set baselines and then be able to build on top of it. So, the cloud operation models, another very important one. A lot of our customers say, "That presentation was great. I got a demo. Man, I want in my biggest problem is that I can't get InfoSec to the table. I can't get my cloud, " if I'm the cloud admin, for example, "I can't get the security folks to agree that this is the right thing to do." So, how do we address that? And the solutions when we're talking about automation and we're talking about software find everything and the CTDC in general. They're designed to align with the operational model that exists today, but just me, and this is my advice, bring everybody to the table. Security and InfoSec and networking, they need to be at the table with your Cloud teams and cloud architects from the very beginning, right? They need to own this component, you're not taking anything away from them. If you are the vRA champion and you're trying to convince your network and security team that they really have to do this, that's not the way it's going to work. You bring a menu, give them ownership, with that ownership comes an opportunity to excel and an opportunity to learn possibly and an opportunity to drive efficiency through their organization. This is where we find the greatest adoption and success for our not just an NSX customers or just vRA customers or cloud management when these guys come together and girls. So, your network admin, right? Your security admin, they all play a role here. All of this can be those baby steps, remember, I can just build all this in back-end and I can consume it. I'll get comfortable with it and then I can start automating. The cloud architect can work with networking security to bring all of these together in a unified blueprint. In fact, you can give them access to that blueprint, show them how to consume and provision their own services through vRA, give them that comfort level. If you are a networking security admin watching this, there's a ton of opportunity here for you to shine, for you to be able to take your infrastructure to the next level. It's very important to have these conversations, right? Be the BFF of the cloud architects. All this stuff has done as an infrastructure play and then the consumer is just going to come in here and consume. For the vast majorityof environments, that consumer's no longer manually interacting or opening those tickets or having to do any of those long drawn out red-tape wrapped processes because I just want two applications on a particular network. I just go and request and because you've done all the work up front, which is drag and drop, all of it's automatic and by the way your inboxes are laid up, you know exactly what's happening, you've automatically updated your ITSM tools of choice, you've got an audit trail, you can do whatever you want to do and you can have that based on trigger regardless of the role you play here, visibility is key, right? Automation will fail without that visibility component. So, being the enterprise tool it is, this is designed to give you end-to-end visibility.
