So, these controls for both NAT networks and for security groups and tags as a day two option were added NAT-703, and I think there're just hugely significant path forward. One of the driving factors behind this, is that also what happened in vRA 7.3 and six, three plus, that we've moved over to an API relationship. So API to API, there's no orchestration or anything happened in the background, and it's given us the ability to get a lot more granular and have a lot more controls and visibility into all these pieces. So, let me show you a couple of day two examples. All right. This time, I'm going to go to the inbox tab and expand one of the machines that I've already deployed. Highlighting that machine, I can go to the actions and change the security. This will take me to the day two operation for changing or modifying the security. I could change the existing security group or I can change or modify the security tag. Here, I'm going to just select an example security group to add and hit submit. If data's being governed, it'll go through the approval process. Okay. Next, I'm going to demonstrate the day two operations for a NAT policy. So, selecting an existing NAT network, I am going to change the NAT rules. Here, as you can see, I could add or modify the NAT rules as I need for the use case. In this case, I'm going to add a new NAT policy for SSH traffic and allow it into that web tier. Hit okay and submit, gain, that'll go through all the necessary processes or be completed right away. All right. So, this next topic, I got a couple more slides. Next topic is Extensibility. This is an all day lesson in itself, but I'm going to put it in a couple of slides. Extensibility is one of vRAs as I mentioned, seems like hours ago. Extensibility is so critical to what we're delivering in vRA, because it allows me to go and plug into that ecosystem, right? It's absurd to think that you're all in on VMware and nobody else. It's not even possible I would I would suggest. Whether that's Legacy Tools, whether that's Shared Infrastructure, whether that's not the load balancers that are shared across physical and virtual, et cetera, et cetera. Being able to plug into those resources and wrap those around the application in a very similar manner, is a key component here. As I mentioned, integrations in the InfoBox, and F5. And ITSM tools, and so on. All of those can be incorporated in here. The existence of any one of those services could also trigger the business alignment, the governance and policies et cetera. Based on something being integrated in, I can create all kinds of breadcrumbs. So, this happened exactly for this. So, my ability to audit all of it. Then, I'm going to wrap those services around that application. So, I'll treat it exactly like I would the integrated NSX capability in this conversation. But it's external, right? It's added on. Now, there's different ways to treat and consume extensibility options. Now, we have a lot of partners that have built plugins. Those are easy. You get in, you can consume for example vRealize Orchestrator workflows as a service, and I'll talk about that next. Once that's done, you can drag them and drop them or we can basically just call out and send the properties payload to any workflow and say, "Hey, I'm going to hand this off to NSX now" I mean, you can actually provide extensibility policies against NSX as an external entity as well, very common use case. But for example, F5. So, I know that my design requires F5, I go ahead and provision these machines. One thing I didn't know yet was the IP addresses because it's all on-demand. Then, I hand that over to vRealize Orchestrator. I tag the the F5 plug-in and say, "Hey, here are four IP addresses, and here's the policy I want. Go do." It'll go do, come back, and then I'll send that inbox message say, "Hey, your app is done" When I decommission, I undo all of that. Very important part of it, I keep emphasizing that. We're going to also use extensibility to modify how we consume NSX in itself. Right? So, we can use extensibility options, and some may not even call this extensibility but custom properties to modify the behavior of the resulting edge devices. So for example, I can use custom properties to modify the HA for my NSX edge devices that are deployed for NAT and load balancer. NAT networks and load balancers. I can use custom properties to define whether it's a small medium or large deployment. Right? So, a lot of things we can do there. But the vast majority of the time, policy-based lifecycle extensibility means just plug into everything, make it all about the application, and then undo it all when you wanted to. So, I did mention plugging into NSX and delivering it as a surface. We introduced in previous version, previous platform actually, this thing called ASD, which is the Advanced Service Designer. In vRA 7, that's called the XaaS. So, X-A-A-S where anything as a service. Essentially, Again, I can spend hours on this. But essentially, if I have a vRO plug-in, I can control presentation layer through vRA directly. So, that workflow presentation layer. I can then entitle that or publish it, and title, it and consume it in my catalog just like any application Blueprint. For you network and security folks, think of the tools that you use, that you have to touch every time an application or new service request comes in, all of those things can become services in about five or six clicks if that plug-in already exists. Right? In this case, I'm showing NSX itself as a service. Remember, I mentioned that you can't really create a security policy within the unified canvas? Well, there's a workflow for that, and I can build an XaaS service for that. So now, for a very specific subgroup, I can say you're allowed to create security policy. That security policy gets created, it gets collected in inventory by vRA. Guess what? Now, it's available to be added to security groups on my canvas. So you have full loop, right? It's all intent-based design, intent-based automation. There's a lot of like, hey, this is really cool, but the vast majority of it is designed to solve real, real, problems. Summary is, I go to number four right away. vRA and NSX are absolutely better together. Look for #BetterTogether on Twitter. Tons of resources out there. Please take your time and go through a lot of them. I blog heavily about this topic on VMware, VMware blogs. Tons of stuff out there. Of course, this whole series has just a tremendous amount of information. Of course, reach out to your favorite VM or rep near you for whatever else you might need to dig into, and I really appreciate you hanging in there. Good luck.
