 Hey everybody, welcome to this edition of Azure Unblogged. Stay tuned where I'll be talking to Matt McSpirit about Azure Stack HCI. Hey everybody, I'm Sarah Lean and today in Azure Unblogged, we are talking to Matt McSpirit. Now, Matt is a Program Manager in Redmond. Welcome to the show, Matt. Hi, thanks for having me. Program Manager is one of those titles we hear at Microsoft quite a bit, Matt. Could you give us a bit of an overview about what your role is please? Yeah, sure. So I'm based in Redmond, although the accent might not give it away. So I'm here in just outside Seattle. As a Program Manager in my side of the business, I'm focused on working with our enterprise customers and partners around two specific early adopter programs for two specific technologies, one of them being Azure Stack HCI, what we're going to talk about today, and another being the Azure Kubernetes Service or AKS on Azure Stack HCI. So we're running some early adopter programs for those technologies where we work really closely with customers and partners to help get their feedback about the products and help them deploy, run, operate those technologies. In some cases, quite early compared to when they actually release. So we've been working with customers across both of those technologies for some months now and we'll continue to do so as we go forward. So it's awesome that I get to see all of these different scenarios from different customers and see them really evolve, help us evolve the technology as we get forward to get closer to release, which is just great. That sounds like a really interesting job, Matt. Yeah, it is. Now you mentioned Azure Stack HCI and that is our topic of discussion today. Now, Azure Stack HCI is something I think I know a bit about, but I think I've got some miskeceptions. Cole, could you just give us an overview of what Azure Stack HCI actually is, please, Matt? Yeah, of course. Azure Stack HCI is our newest member of the Azure Stack family, which includes Azure Stack Edge and Azure Stack Hub. So think about those three components offering solutions for different use cases and scenarios. And Azure Stack HCI, as I said, the newest member of the family and it's a new subscription based piece of software that you run on your infrastructure, whether that be in your data center, whether that be in a remote site, an edge location, whatever it may be. Being a subscription, it's essentially paid for through your Azure subscription. So you choose to register your Azure Stack HCI infrastructure to Azure, and that opens the door to a number of additional Azure services, integration points with Azure from monitoring, updating, cluster management and more as we go forward through integration with Azure Arc. And what you essentially install on-premises, you download the Azure Stack HCI software, you put it on some validated hardware, which could be existing or it could be new hardware from a wide variety of ROEM partners. And that's one of the amazing things about Azure Stack HCI, it's just the sheer flexibility you've got to deploy this software. But it is HCI, it's hyper-converged infrastructure, meaning all of your compute, all of your storage, all of your software-defined networking is within the x86 server infrastructure. This isn't external storage like sans, this isn't external networking specialized components. Everything is defined and contained within the hardware itself. So, and we layer that software on top. So our Azure Stack HCI software installs, registers to Azure and then you've got this amazing hybrid solution to run both traditional workloads like Windows and Linux virtual machines, but also as a platform for more modernized, more cloud native applications like Kubernetes for instance, which is my other focus area as we discussed earlier. So I think it's really interesting that we're taking something from Azure, so Azure Stack HCI is an Azure service and actually running it on-prem. Where do we see this fitting into our customers' problems and being a solution for them, Matt? Yeah, from a Microsoft standpoint, we would love for all of our customers to embrace Azure because it's an incredible place to run a wide variety of workloads from VMs through to serverless and microservices in a variety of other different applications. But that's not the case for every customer. Not every organization can run everything in the public cloud due to network latency, compliance, there could be data gravity, regulations, there's all sorts of reasons. Even environments that may exist completely disconnected from the internet can't reach Azure for instance. And so for scenarios like data gravity, regulatory, compliance, do we want to tell an organization that you have to stop your cloud journey, the cloud adoption, the cloud models? No, we don't. We want to enable organizations to harness cloud technologies but do it in their own environment. And that's one of the primary goals of the Azure Stack family in general, Azure Stack Hub, Azure Stack Edge and now HCI. So the beauty of HCI is you can put it in your data center and run those workloads that do need that local experience, whether that be big databases that need to exist in close proximity to application front ends and the round trip time to the cloud is just too much, it's too sensitive. Or it could be just I'm a financial institution or a medical organization, a healthcare organization and I just can't put that data in the public cloud. A lot of other stuff I can, but this has to reside on premises. And I want to do that in a way that's consistent with Azure as possible, as integrated with Azure as possible from a billing, from a management perspective. And that's one of the key enablers of Azure Stack HCI and not only for large data center environments but also those remote sites, those two node clusters in a medical office or a retail store that can now be part of the overall cloud picture for that organization. And that's there's some of the key strengths and use cases I see at a high level for Azure Stack HCI. I think we've all worked in environments where those remote branch offices have had some kind of server installed on them. So it's great to be able to hopefully integrate your larger cloud scenario or solution in with this Azure Stack HCI solution as well, Matt. Now for me, I think a few months ago I thought Azure Stack HCI only ran Windows Server and that was all it did. But listening to you talk here you're saying that it's actually got Kubernetes functionality within it. And I think there's also data services built into it as well, is that right? Yeah, to a certain extent. And so I'll help clarify for people as well. So Azure Stack HCI 20H2 to give it its full catchy name is the new OS that we're releasing. And it's a new OS instance. It's a new version of essentially an operating system to put on that hardware. Historically, however, you could build hyper-converged infrastructure using Windows Server 2016-2019. So that evolution has moved towards this new 20H2 Azure Stack HCI operating system. But you're right, it's not just for Windows workloads on top, as I described. You could virtualize Windows, both client and server and a lot of Linux-based workloads just like you can in Azure. And that's more of the traditional VM infrastructure that you would run on-prem. But as you rightly called out Kubernetes is the kind of poster child in the industry right now. It's everybody's talking when you talk about containers the next word that's synonymous with that is Kubernetes. And we've got an incredible solution in Azure, in AKS, where I abstract a huge amount of the plumbing and the complexity of Kubernetes. So, so much so that I as a developer or as an IT admin who's versed in Kubernetes can very quickly deploy new clusters of Kubernetes without needing to worry about all of that plumbing and the under the cover stuff that's notoriously complex. We've brought that kind of approach, that automated deployment, that streamlined efficiency of laying down Kubernetes clusters to Azure Stack HCI in the form of AKS on Azure Stack HCI. So if you think about a layer, you've got Azure Stack HCI 20H2 at the base running on the metal. And then on top, we provide you the software to deploy AKS on HCI so it lays down the management infrastructure deploys your nodes, your worker nodes to run your applications, your workload clusters in Kubernetes. And then as you called out again, there's another layer where if you're interested in running containerized applications for yourself, for your own business, you can go ahead and build those to Kubernetes standards and run those on our platform. But if you want to consume some of the additional pre-built services from Microsoft that natively typically run in Azure, we can now enable you to bring those down to run on Kubernetes on premises. One of those is what we call Azure Arc Data Services and that brings both SQL managed instances which normally only reside in Azure and Postgres hyperscale which again only resides in Azure. These are native Azure Pass services essentially. We've decoupled those from Azure and we allow you to deploy them down to Kubernetes running anywhere but for the purpose of this discussion, Kubernetes running on AKS HCI, running on Azure Stack HCI at the base. So a lot to digest there but think about it in those layers. Azure Stack HCI, AKS for HCI and then other applications and Arc Data Services on the top. And this is just the beginning in terms of using Kubernetes as an enabler to bring additional services to non-Azure environments, let's say, not just on-premises environments. That actually sounds quite interesting. It sounds like it will speed up customers implementations and adoption of some of these technologies as well. So that sounds really, really interesting. Now you've been, you've mentioned Arc in this story with Azure Stack HCI and I think Windows Admin Center is also part of the story which is one of my favorite tools within our product range. How does Arc and Windows Admin Center sit in with the Azure Stack HCI story map? Yeah, so that's a great point because it is an important point that needs clarifying for a lot of organizations who've started to embrace Admin Center and now hear Microsoft talking very broadly about Azure Arc. Azure Arc is the future of management in many cases and what about Admin Center? What do I do with this? Admin Center still plays a critical part with Azure Stack HCI. You can use it to very easily streamline the deployment of Azure Stack HCI clusters. It will handle the registration to Azure which is a critical part of the overall deployment process. You have to register your clusters to Azure for billing and for enabling some of the additional services and capabilities. So Admin Center plays an incredibly important part in that and it can continue to play an important part in the monitoring, the provision of VMs, additional roles and services for your workloads. The core Admin Center stuff that it does really well and it's also an integration point for our partners like ROEM partners who build extensions that expose additional hardware functionality to your Azure Stack HCI clusters essentially running on. So there's elements of Admin Center that will stay incredibly important and will be a permanent fixture, I think, for Azure Stack HCI, at least for the foreseeable future. But then you've got Azure Arc. So as soon as you register your Azure Stack cluster to Azure, there's a specific resource provider in Azure. So if you go to the portal and you search for Azure Stack HCI, you'll see all of your registered clusters there, not only from a billing and a cost management perspective, but also you'll see the number of cores that have been registered. In the future, you'll start to see workloads that are running on that cluster and you'll be able to perform more globally-scaled approaches, let's say, such as managing updates across all of your clusters, managing, monitoring across all of your clusters, onboarding those workloads and clusters into those additional Azure services. We're looking to streamline as well. So there's really a, it shouldn't be seen as an or with Arc, or Windows Admin Center. It should really be seen as an and. And Admin Center, I think, will provide a lot of core functionality, especially in the first few releases of HCI 20H2 and beyond. And then it's always going to have a part to play and then Arc, I think, will, as we build more functionality in for HCI, you'll see incredible capabilities come in. But they can develop in different cadences. They're not tied to one another. We can do a lot of Azure work, even if we don't release a new build of Azure Stack HCI in the meantime. So that's an important differentiator point for the new Azure Stack HCI as well. It's a subscription. So you've always got access to the latest versions and we aim to release a new version of Azure Stack HCI on an annual basis. So as an example, HCI 20H2, 21H2, 22H2, etc. But the Arc elements can evolve kind of separately from that. So that sounds really interesting, Matt. If I wanted to try it, if I wanted to test it out and evaluate it, do I have to buy hardware because you mentioned validated hardware or is there a way that I could kick the tires and test it out today without doing that? Yeah, so in terms of evaluation, in terms of testing, just like Windows Server of old, Azure Stack HCI will work on a significant amount of hardware out there. And we have an older Windows Server catalog where we have a variety of different certified components. So using that as a guide would be very helpful. But we have a new Azure Stack HCI 20H2 catalog that has systems both new and perhaps in some cases, previous generation systems from our OEMs that they validated for working well with Azure Stack HCI and being supportive. So even if your hardware isn't brand new, you got it last week, there's a very strong chance that if it was certified in our previous generation catalogs for Windows Server, that it's going to be certified and validated essentially for 20H2. So getting started, I think I don't see hardware being a blocker for too many. If you've got some spare hardware, obviously, if there's nothing running on it already. The one or the biggest consideration is bear in mind this is a hyperconverged solution, meaning we get some questions around, can I use existing hardware? I've got some really good compute nodes with lots of memory and compute and CPU, but my storage is on a sand. Well, unfortunately, this is HCI. So the storage needs to be in the chassis. It needs to be at least perceived as internal to the individual nodes. So in that respect, you would need that from an architectural perspective, but we're pretty flexible on what the storage can be, hard drives, SSDs, NVMe, et cetera, but you wouldn't need to be internal at least to the operating system in each individual node. If you've not got any hardware, does that mean you can't evaluate? Absolutely not. We know that Azure supports nested, which is great. So we've got a great eval guide as well, published on GitHub, where you can essentially go and follow the steps either for nesting on a small amount of hardware you may have, even like a laptop. You can fit this on if you want to just do some basic functionality testing. But in addition, you can also run this in a larger VM and nest a couple of HCI nodes, build a cluster, deploy admin center, et cetera, connect to ARC. So you can really experience the whole thing bar any kind of performance testing in an Azure VM and then shut it off when you're done to save some money and just power it up when you want to do, when you want to have a play. So it's a way that we're actually enabling customers who've not got spare hardware at the moment to at least understand the different building blocks of Azure Stack HCI. That sounds good. I think that's going to be our project over the next couple of weeks for me to test out and try out Azure Stack HCI. If people wanted to find out more about the product, is there any getting started resources or places you'd recommend that they head to, Matt? Yeah, the official documentation for Azure Stack HCI has been updated and is available. And you can follow all of the steps within there in terms of identifying hardware. There's links to the catalog. There's some guidance on there in terms of hardware characteristics and minimum specifications, which is really useful. And then we've also got the eval guide that I referenced that we can provide the links for as well. And that's, I would say, is a great one-stop shop if you're looking to understand more about nested. I can't account for the author of that document. You know, it's, but I'd say it's a pretty good guide. Cool. Awesome. Thank you so much for your time today, Matt. You've certainly cleared up a lot of questions I had around Azure Stack HCI. And hopefully you've done the same for our audience. And as Matt said, any of the resources that we've mentioned will be put in the description box. So definitely check them out and have a go. And please do subscribe to our channel for future videos of the Azure on Blog series.