 Hello everyone and welcome to another edition of Azure Unblogged. In this series covering AVS or Azure VMware Solutions, we are looking at different areas of AVS. Today, we're going to be discussing automation with Scott Holden. Scott, how are you doing? Going well. Thanks for having me. Yes. Sorry about disturbing your early morning, considering you are in Australia and I'm in Canada. That's the nice thing about the virtual world is there is no distance between us. Definitely. Got to make those time zones work. That's right. AVS and automation. Basically, how does our automation fit into the AVS picture? It's actually a really interesting question. For a lot of customers when they first get hands-on with AVS, they'll run through and they'll manually spin up an AVS private Cloud. They'll manually configure everything and to be perfectly honest, it's a great way to get started, to learn the nuts and bolts, to actually understand how everything fits together. But when you want to begin to look at production environments, cross-regional environments, when you want to be spinning up DevTest prod, or even environments that are temporary or only for a short period of time, all of a sudden manually waiting for a private Cloud to deploy and then spending hours upon hours just to configure a private Cloud becomes really unwieldy. So rather than having to manually drive that first level of configuration, Automation for AVS as part of the Enterprise Scale Landing Zone, really focuses on how can we take the low-hanging fruit, the things that should be repeatable, reliable and stored as configuration rather than in people's heads, and deliver it in such a way that customers can take the best practices and begin to run with them. Now, you may not necessarily want to automate everything inside of AVS day one, but a lot of customers that are especially looking for an infrastructure as code first approach in this Cloud world, and that's what the Enterprise Scale Landing Zone for AVS Automation section is really focused on. How do we do this thing without having to boil the ocean at once? Okay. So what you're talking about really is like setting up like CICD pipeline to deploy the VMware cluster on Azure or is it deploying the guest inside or is it both? Fantastic question, and it was one of the really interesting conversations we had when we were putting together the best practices. How far do we actually go down this rabbit hole of automation? Exactly. Yeah, we can deploy just the private Cloud, or we can go right down to the virtual machine level over in sub workload level. The majority of the guidance and the best practices we have are around the private Cloud so that top level deployment, because a lot of customers actually have existing automation strategies for guest and VMware level deployments today. If they've got those best practices, they have those strategies and approaches, we want to encourage customers to continue to use those pieces where appropriate. Whereas private Cloud automation, the actual spent deploying the Azure resources themselves, that's the new thing. That's the thing customers are not too sure about there. Hey, we've used Azure, we've used VMware, but how do we use the Azure VMware solution? How do we actually get this thing spun up? So it's really about targeting that middle area of how do we deploy private Clouds, take care of networking? Customers if they want to automate VMs can bring all the tech they know and love already. That was one of the major goals. It's also rather interesting. Oh, sorry. No, it's okay. That's deployments. So what are you targeting that? What kind of scenarios you're targeting? Is it for like say a development team that is testing a new app, or what scenarios are you looking to really focus on with the guidance on automation and deployment? Definitely. It was an interesting one because we originally started off by building out what we call the Greenfield scenario, which was a customer that wants to come along and deploy an entire environment net new from scratch, and that could either be as a temporary dev environment, or as a production environment that they have documented as infrastructure as code. We have had customers that have gone through and said, hey, our proof of concept was manual, our production deployment rather than configuring it by hand, let's just roll out the automation and get it done. But we do realize that, hey, it's not just net new customers that want to take advantage of this automation and begin to move towards that infrastructure as code style approach. We also have a series of modules as well or sub scenarios, where you can pick and choose the parts you want to automate. You may have an existing private cloud ready to go that your production team is deployed, but you really want to automate the networking or you want to automate service health alerts and monitoring. The operational side of it is just as important as actually deploying the private cloud itself. So as well as having the massive Greenfield scenario, we do also have a series of sub scenarios, the customers can pick and choose and use for individual components rather than having to deploy the whole thing. Okay. When you're talking about creating that deployment package, if you will, are we looking at, is it like an ARM template? Is it like a YAML file? Yeah. JSON, what format are we looking at? This is one of the highly divisive questions that we had internally is what format do we release this in? I mean, we've got so many options these days from the Azure CLI through to ARM and Bicep templates. What we ended up doing is releasing in a few different formats. So we have both Bicep and ARM templates available and that gives customers the flexibility to deploy using in-house Microsoft infrastructure as code in a declarative manner. We do also have some samples for PowerShell in the Azure CLI for particular sub scenarios where we found customers have really needed an example or something to work upon when they're building out environments. Hot off the press, we are also working on Terraform modules as well, giving customers the ability to use the tools they know and love to deploy these environmental components. This really opens up the slather to any tech a customer wants to work with. The fact that we've got Bicep means that it's really easy to build and extend upon but also having Terraform means that, hey, if you're not built into the Azure infrastructure as code ecosystem, you can still work with the landing zone. I'm a big fan of that mostly because it removes a lot of the friction for adoption. So if you're used to Terraform, then here's the Terraform module. If you're a Bicep or ARM guy, then here it is. I do prefer declarative to imperative mostly because it's a little quicker because things run in parallel versus having to wait for item number one to be done to move to item number two, but to each his own really. So you've mentioned Terraform, is there anything else that we're working towards? This is the interesting thing because AVS is a constantly growing product with the new technologies that are coming out and integration with other services. Today, we do have a ton of sub scenarios, everything from, as we mentioned, private cloud deployment to automating network into connectivity, to setting up connectivity between multiple regions, right down to things like, as we said before, service health alerting and operational monitoring. And that's been one of the big things that customers are looking for. It's, hey, we've got the private cloud deployed. How do we take care of all the ancillary tasks that actually sit around the solution itself? And that really comes down to the architectural decisions that are beyond just, hey, we want to use AVS. So we've been working on a ton of the add-on capabilities. So having the ability to roll out HCX and SRM as part of your AVS deployment rather than having to do it as a secondary step afterwards, having the ability to utilize V-WAN Hub for site-to-site VPNs as well as for egress control via Azure Firewall as part of your deployment. So all of a sudden you can begin to deploy an entire end-to-end environment including your networking stack as a single template rather than necessarily having to jump backwards and forwards between different components just to get an AVS environment stood up. And that's the main thing we're looking at now is that ecosystem of technology is that actually surrounds AVS. So that is actually very, very interesting but what just popped into my head now is we've talked about automating the deployment of the AVS cluster or the VMware cluster running on Azure, dedicated on Azure. Is there a tie-in to Azure automation in terms of the operation of said cluster once it's up? Yep, definitely. And one of the nice things about AVS in particular, so the Azure VMware solution is that we can treat the virtual machines sitting inside the cluster in the same way we treat an on-premise virtual machine. There's nothing stopping you rolling out the OMS agents, log analytics agents, Azure Automate agents. And we do have customers that are using Azure Automate to run DSC on top of AVS workloads. That gives you the ability to take that modern cloud first approach through Azure Automate rather than necessarily having to build out your own DSC focused infrastructure just to build up those workloads. So yeah, there is that massive tie-in. One big thing that I'm looking forward to down the track is that deeper integration between all of these systems. Today, I like to call it a little bit of a two-click operation. You do need to consider the fact that yes, it is a VMware virtual machine rather than an Azure native virtual machine but that does come with benefits by itself. So really looking forward to down the track that deeper integration and automation is key to making that happen meaning that we can do things as ideally single-click or in a perfect world, a zero-click operation where it just happens as part of your deployment rather than something you need to manually orchestrate. That's wonderful. Wonderful. I'm interested in looking at it. I'm sure some of our audiences are also interested in looking at this. Where does one go to get started? Yeah, so we've released the Enterprise Scale Landing Zone for AVS now which contains an Automation and DevOps focus section that runs through some of the best practices, some of the guidance from many, many customer deployments we've had externally today but also has a little bit of a path to adopting automation for AVS. Not every single customer will go to deploying AVS via CI CD pipelines overnight. A lot of customers will find that it's a little bit of a journey. You may manually deploy it first. You may choose to manually deploy templates, still using infrastructure as code but having it as a kicked-off operation rather than something you execute via a pipeline all the way through to that continual deployment of infrastructure which is kind of the golden state that everyone wants to head towards. I know you did mention at the beginning of the conversation that the first time you do something it's often a good idea to do it manually so that you understand how all the pieces work together and then kind of graduate to a automated deployment. So I'm really a big fan of that approach as well. Do we have as part of the Enterprise Landing Zone are there samples for me to look at and basically steal and pillage from? Yes, there is. And this is the other half of the Enterprise Scale Landing Zone if you will as well as the best practice documentation and now our best practice recommendations we've also released a series of artifacts and that's really the core of the Enterprise Scale Landing Zone. So we have these scenarios built out and documented ready to go as an open source GitHub repository. This means you can clone, you can fork, you can take them and modify to your heart's content. We've also tried to make it as easy as possible for customers to test out this technology. So a lot of the scenarios and especially the big Greenfield scenario actually has a single click deploy to Azure button. So rather than even having to clone the repo you can just click deploy to Azure, flip over and actually roll out a full AVS private cloud using infrastructure as code. The whole goal is for customers to be able to get started quickly but then have these templates available to modify to extend to build upon as they see fit. Yes, because it's not unusual in the industry to have like a common ground kind of underpinning of your environment saying, well, if you replied, did this type of application requires AD network storage and database, boom, go out. And if you wanna add or remove some stuff then editing the samples becomes fairly easy. That's exactly it. We've even seen organizations that may not necessarily have a DevOps strategy today take advantage of things like Azure template specs importing the templates and basically giving them a rubber stamp to go around creating environments with AVS. And that's really the whole goal is we don't wanna say, hey, you have to be running Azure DevOps or GitHub actions to deploy this thing. We wanna give you the artifacts to adopt in the way that makes sense for your organization but give you best practices at the same time so you don't fall down those common traps or common pitfalls. Yeah. Well, thank you very much, Scott. This was enlightening. All the links will be in the description below. So hopefully all of our audience will go and try it and possibly automate the deployment of the AVS solution. So thank you very much again for taking the time this morning. And thank you very much. All right. And for you at home, go try it out. Go check it out. All of the samples are there and try for yourself in your own environment. So thank you very much. Have a good day.