Let's talk about one of my favorite topics, vRealize Automation. For the sake of this prezo and the demos, this is all going to be done in vRealize Automation 7.3 at the time of this recording, and is the current GA product. vRealize Automation, just to set that up, it's a core or top of stack depending on how you look at it of the software defined data center. It is a key component of our cloud management platform or our CMP, also known as vRealize or vRealize Suite. Again, depends on how you look at it, vRA kind of sits on top, and it automates everything underneath. But more than just automation, it's also an abstraction layer, right? If we want to start behaving like a cloud, if we want to start delivering services like a cloud, if we want to start applying SLAs that are very cloud-like to our private cloud or a hybrid cloud, this is where you have to be. And I need to be able to do deliver applications and services, on-prem as well as off-prem, so total hybrid cloud capabilities here across all of my platforms. In this case, I'm going to focus specifically on vSphere and NSX and being able to do it in a very multi-talented, very governed, very consistent and automated way. So, I can spend all day just talking about the individual pieces on this deck, but I think you can get the idea here. We're going to focus on a couple of strong spotlight components for vRA. These are core, very deeply rooted technology innovations that have been part of our cloud management platform for quite some time now, and vRA really just exposes all of that. First of all, I mentioned the abstraction, being able to go beyond the initial platform where we did the initial abstraction a dozen years ago, and be able to start treating those resources regardless of where they're sourced as a huge blob of services. So we're abstracting abstraction. So you've got virtual abstraction, and we've got our cloud fabric, which is our additional layer of abstraction there. Just like you'd go to a public cloud resource and you're not calling out individual servers or pinpointing the resources that a particular server typically should have. It's just a blob of resources, and sometimes they are globally distributed. vRA does the same exact thing across your private public clouds. So, look at it first there as your fabric abstraction layer. I build these blobs of storage computer network and security resources in this case, and I just consume. I'm consuming based on SLAs, based on tearing, based on the role I play, based on the fact that somebody hates me, and I'm using a eight-year-old hardware, it doesn't really matter. In this world, there is no hardware, it's just a fabric. Another very important component here is the native integration into the rest of the stuff that I've been talking about, so vSAN. Being able to drop an application and just let vSAN respond to that application based on its policy, okay? The extensibility, the ability to plug in and automate, and orchestrate the entire ecosystem. Those 30 different things that need to be touched and tapped and made part of the application throughout that application's life cycle regardless of what it is. We do that through extensibility in a core extensibility engine. Now, the best part of all of this and where we're going to spend the rest of this time on is networking. vRa and NSX are #bettertogether, and certainly not just because I'm up here and selling that to you, but because engineering and both of RBUs have done a tremendous amount of work aligning with the vision of VMware of the SDC, to build products that are truly integrated in a way that allows us to take this vision to fruition. We've been doing this for several releases now, VRA 7.3 and NSX, the latest version of NSX, give us native API integration, so they are speaking the same language. And we're doing a tremendous amount of work in this world. I'm going to talk about what we're doing right now. So, I kind of already wore you out on automation, we get the benefits of automation. But, just because I'm going to switch over to my networking segment here, when we're talking about networking and security and we were talking about that in the context of automation, it is end-to-end. It's about the application, it's about the use cases that are driven through test def, and then being able to release an application into production. It's about wrapping networking and security services around each and every single application in ways that it is cost prohibitive to do in a physical world. That is what happens when these technologies come together. So automation means a lot of things. I've went ahead and described it in many different ways. But when it comes to networking and security, automation is designed to drive value. It's designed to increase the time, that an application that has a very unique networking posture or security posture, reduce the time it takes in increase of value, and bringing that application to market consistently. So, it's all API-driven. As you know, NSX lives in the hypervisor. There's SDN and there's network virtualization. We're bringing these things together. NSX brings that as a networking security platform. We'll get more into that later, and you've probably learned a lot about that in other modules in this series. But so, virtual networking lives in vSphere in this case, for NSXv, and vRA is just going to sit on top of that, vRealize Automation. Based on a set of policies, just consume it. Just automate the provisioning of services, wrap them very nicely around each and every single tier on any application, and move with that application across wherever that application lives all the way through decommissioning that app. It's designed to all be consumed without having zero knowledge of what even a network is. In some cases, my architect, my app architect for example, sure, my app architect should know what kind of network, what kind of services are required maybe, or they don't have to. Or my networking security team itself could use these tools to automate their day-to-day traditional services and traditional requests. But ultimately, it's all consumed through a common catalog, a unified catalog of services that delivers all these services, and when I'm in my catalog, and I'm picking an application, a very basic or a very complex application, as a consumer, I don't necessarily have the controls on the levers of the network, and I mostly shouldn't. But as a developer, as a test dev use cases, as an engineer myself, where I'm testing applications with network impact, whatever it might be, maybe I do have those controls. So, we want to be able to provide both of those capabilities. Now, I do want to make one very important point. The demos I'm going to show you and the screenshots in such, this isn't something that I've been working on for months. So, I can come on here and impress you guys. This is truly the native integration. This is post-install of NSX and vRA, it's a tick box to integrate and type in the FQDN, vRA collects that inventory, and then allows you to start using and consuming and building your policies around it. It is very important to make that point to reiterate how these products are truly designed to be better together. So, when I come in here, I select my application and just really cool things happen, and those things may happen because of where that application landed. It could happen because this is a, I marked it as a test use case. It can happen because of who I am. I'm not trusted, therefore, I'm going to isolate this application totally, or any use case. Lab use cases, the test lab use cases, where I'm deploying literally hundreds of applications, each with their own unique network, and then promoting one or two to various roles in production or DMZ et cetera, those are real use cases are very powerful, when we talked about that kind of scale and what automation can do. When we're saving 15 minutes here, 30 minutes there, two hours here times 100, it adds up. Now on the back end, that's the consumer. In the back end, there's my design canvass. This is called the Converge Blueprint Designer or my Unified design canvas. Again, when I hit that tick box and I bring NSX into vRA, I'm setting up my policies. What's important to me? Which services will want to consume? What does that actually mean in the world of this cloud? Where's this SDC? Those services are made available or they're exposed right here in the design canvass. And if I have the rights to use and manipulate those services, it's a drag and drop. It's beautiful. If you haven't seen it, see it. Go, see it, and you'll see it in the demos I do in a sec. But ultimately, I've got my inventory of services that can be something very basic like an existing network, which is just a data collected network, regardless of the platform. It could be an On-Demand network. It can be network services, and then of course it can be the entire security stack, and again, I'll spend a little more time on that. So, I'm going to build all of this great stuff and design my application with network intent. So, the application in this case is a high-visibility application that also requires to be aligned with our businesses security strategy and posture, and therefore, I need to make a decision. If it's going to live in a DMZ, it's going to have access to the inside, it's going to be accessed by public users, or consumers, or maybe a very specific LAN source. Whatever it is, just gets baked right into that blueprint. And if you want, I can then just export this. It's exportable in YAML, so I can take the entire architecture of that app, export it into human-readable plain English, YAML text, hand it over to a buddy and say, "Look, this is now how I'm going to go to market. This is the application, the Change the World app 1.0 networking storage, the app stack, the load balancers, all of that stuff intact. I'm just going to hand to you in 100K file." This is what this world is about now, being able to build and rinse and repeat. It's quite cool actually. So, just to give you an idea of what some basic authoring looks like, basically this is an introduction of VRA itself. I'm going to show you a little bit of video now. Let's jump right in. All right. Here we are in the unified catalog. I'm going to jump over to the design tab, and we're going to go ahead and create a new application. Call this our Multi-Tier App 1.0. It's the amazing new app with NSX integration, and then open the NSX settings tab. I'm going to just select my NSX transport zone, and I only have one available at this point. Here's my design canvass. From the machine types, I can drag over vSphere machine to represent a vSphere backend template or component I want to use. But rather than do that, I'm going to go ahead and go to the blueprints category and drag and drop an existing blueprint. We'll call it a gold master or a vanilla blueprint that I want to use as a core component of my application. So, drag and dropping one of them for the database tier, and here's the other one for the web tier. Over to the software components, I'll drag and drop a whole bunch of components to make up my multi-tier app. So, we'll start with some Apache and my WordPress configuration script on top of that, and we also need PHP. And then on my database tier, I will drag and drop MySQL, and call that MySQL, then drag a WordPress database script to configure my WordPress component. With some drag and drop, I can create my application dependencies to make sure that they are built according to the application's requirement at deployment time.
