Podcast Archive - StorageReview.com - Podcast #118: Going Deep on Microsoft Azure Arc, Cloud, Managed SQL, AVD, HCI and More!

Episode Date: March 28, 2023

Brian invited Ernie Costa to join him for this podcast. Ernie is a Team… The post Podcast #118: Going Deep on Microsoft Azure Arc, Cloud, Managed SQL, AVD, HCI and More! appeared first on StorageReview.com.

. Everyone welcome to the podcast. I'm Brian Beeler and today we've got an interesting conversation. We've got an MVP in our midst. So we'll see what that's all about and learn quite a bit more about the Microsoft Cloud infrastructure, what's going on there, what's going on via Azure Stack HCI and some of

the services and other things Microsoft's offering there around SQL Server and other database offerings. Ernie, thanks for coming in and doing this today. No problem. Super excited. This is going to be fun. Yeah, so you're an MVP. In the Microsoft world, everybody knows what that means. If you're not knee-deep into Microsoft, what's an MVP? So I'm relatively new to this as well. So you don not knee deep into Microsoft, what's an MVP? So I'm relatively new to this as well. I've been an MVP. So you don't know the answer to that? Yeah, no, it's kind of like, I don't know, I gotta go Google that.

Great, great start. Yeah, right? No, so I've been an MVP for about a year now. Renewal is actually coming up. MVPs are resources that Microsoft has identified folks and individuals that have contributed to the tech community over the years that are actively engaged with customers or even just folks that maybe are running their own home lab in their basement or something. They don't necessarily need to be a professional and tech being their profession. I just happen to work for an ISV. But the two sometimes overlap, but they don't necessarily need to. You know, it's funny because the MVP program has been around forever and it's, Microsoft used to use it in a way to incentivize the use of their products amongst highly active and engaged people. Now it's probably anyone with a couple, you know, tens of thousands of followers on TikTok or

whatever it is, right, to help do the evangelization of Microsoft products. But way back when I used to be an MVP for this product called Spot. I don't know if you've ever even heard of this, but they used to put, Microsoft put transmitters in radio station tower infrastructure and it didn't do much, but it would broadcast out over the radio signals, things like weather and news. And it didn't do much, but it would broadcast out over the radio signals, things like weather and news. And I think you could even set up personalized alerts. I mean, this is before everyone had a cell phone in their pocket or maybe at a similar time. But yes, a very short-lived technology that is nowhere near relevant to much of anything today. But it's funny, that stuff, it kind of lingers around with I think like HD FM radio like you see like remnants of it still there and at

least in the U.S. so it's kind of cool tech that that you know it it moved on to something else. Yeah but you know to be fair like the radio kind of always works so while it may not cover everybody in in all places and you know if you're on the back side of always works so while it may not cover everybody in all places and you know if you're on the back side of a hill but radio is a technology is still pretty neat and highly capable for what it does right yeah so we didn't join this uh this pod together to talk uh radio and spot technology uh one other disclosure though so your your day job though, while you're an MVP and wear a cape at night, your day job is with Commvault. Yeah. Yep. So I work for Commvault. If you're familiar with our backup software, I do not, I'm not a software engineer by trade. I work for our

internal IT department. So I am using the technologies a lot that we're going to be talking about internally. It's not stuff that necessarily we're selling to our customers or telling our customers to use. It's more us as a medium-sized enterprise, what we are using internally there. Right. Well, that makes sense. I just want to make sure if you start slinging mud at like Veeam or Haiku or Cerdo that just everyone knows.

Ernie, go off the rails and start talking trash on the backup provider. We have, in the MVP community, the good thing is there's a lot of folks that do use other software and we actively are engaged with each other about, you know, kind of common things we may see acting up between or even with the various different pieces of software that are out there that do kind of the same thing. So it's not too violent.

It's not Yankees and Red Sox or anything like that. All right. So you're in the Microsoft world. We prefaced this conversation with that. And you're in the IT organization at Commvault. So that's all good background. What is your exposure then to Microsoft products? What are you using on-prem cloud in terms of hypervisor software? Just what's your consumption look like? We are overwhelmingly a majority Microsoft shop. We tend to have a very large presence in Azure for production workloads as well as some dev test type of things. But we also have a traditional on-prem. We have our own data center in our headquarters.

We have a couple of co-locations and remote offices throughout the world. So we still have a physical presence on-prem as I'm sure a lot of enterprises do. So hybrid connectivity since like 2018, 2019, since that buzzword started getting thrown out, hybrid cloud, we've been kind of right there, nose deep in it, getting our hands dirty with it in some capacity. So again, majority Microsoft, Hyper-V, and most recently Azure Stack HCI as our production hypervisor workload. That's interesting because still the predominant hypervisor continues to be VMware ESXi.

I'm curious, why Hyper-V? What has that done for you guys? Had you been on VMware before? What's the history there? Without going too much into it, the short answer, as I'm sure everyone probably knows, is licensing and pricing. So it's expensive to have a large VMware footprint. If you're committed to it and your infrastructure and automation is built around it from day one, then you may have a wrangle on it. But especially with the recent acquisition, costs go up. Maybe or maybe not, you're happy with support that may have been coming along with it. Again, we are a Microsoft Gold partner. It just seemed like a natural fit for the workloads that we were running. And this is decisions that were made before I was involved. But it just was a natural

thing. If we're going to be running a lot of Windows server workloads, and we're already paying for the, at the the time Windows Data Center licensing, why wouldn't we just use the hypervisor built into it? So that's kind of the short, sweet answer. That makes sense. And so one of the things you also mentioned there was Azure Stack HCI. So I want to understand that a little bit too, because where we're going to go is going to talk a little bit about Azure Stack HCI, Azure Cloud, and then some of the services in between.

We've talked a lot about Azure Stack HCI. We've written a lot about it. We've done a couple reviews with DataOn on some of their all-flash and hybrid configurations. I've had Cosmos on the podcast and talked about Azure Stack HCI quite a bit. And the one thing that he was excited about last time we did the pod was that in the old days, Azure Stack HCI was kind of like a feature of Windows Server, like a checkbox of turn this server from a server into an HCI node basically, and join up with some others and off you go. But it feels like when he and I talked,

it's probably been six months, and I'll try to remember to link it in the description here for those that want to check that out. But it really feels like that at that point, the intent was to really mature the product and make it its own independent stack. I'm curious how deep you are on the on-prem HCI product and whether or not that looks real to your eyes. To summarize it, we are pot committed to Azure Stack HCI at this point

from our internal IT perspective. Like I said, we've been running, do we have a VMware footprint? Of course. Is it large? Absolutely not. Have we used legacy Windows Server in the past? Yes. Do we still have some? Yes. Do we use NetApp and other SAN-based storage? Of course we do.

But there just seems to be this ease of management that our IT department has kind of fallen in love with when it comes to the software-defined defined storage stuff that you get with, uh, storage spaces direct. And then obviously the evolution of the OS into Azure stack HCI. Right. Um, there's, I mean, I can sit here and go on for hours about the, the value add in the bonuses of HCI, you know, your billing, your support experience is, is,

is significantly better than the traditional enterprise support experience that you may be getting with traditional server SKU. I think I've done a few videos detailing like top five reasons why you should move over if you're interested. From a financial perspective, again, if you're already paying for data center licensing, and you have software assurance, it kind of is free, like nothing's free, but it's you're already paying for data center licensing and you have software assurance, it kind of is free. Nothing's free, but you've already paid for it, you might as well look into it. The update cadence is significantly faster.

New features are coming to GA significantly faster than with long-term support branch. So all those things just kind of fit right into our vision. So it's kind of a no-brainer. you're hybrid though, too, it seems to me, and I'd be interested in your perspective that Microsoft with the Azure Stack HCI product, the on-prem bit is really trying hard to take the cloud Azure features and functionality and drive those into the on-prem product. And I think we're a long way from feature parity between the two, but it feels like with AKS, with virtual desktop, with some other stuff, they're trying to really push that down from what they've learned on cloud to our governance and our proper security structure and all that happy stuff that you have to worry about in the cloud. How do we wrangle it out on-prem? Because even though there may not traditionally have been a cost associated to it, you still have to worry about security policy and just kind of your posture on-prem of not letting it be the wild west like it may have been.

And a lot of the Azure Arc-related things that you mentioned have simplified that dramatically for us. Again, automation is kind of the – our fiscal year is about to start, and that's like our North Star. Like, how can we handle all this stuff? And it's kind of, oh, Azure Arc, like one line right there. We can do it all with Azure Arc. So we're excited to be transitioning to that as kind of our guiding thing. Well, you said I mentioned it, but I never said the Arc word. Oh, I'm sorry. Jumped the gun. Mr. MVP is, like I said, very deep in the Microsoft technologies.

It would be my theory, my supposition, that most people don't really understand what ARK is or the nuance there. So I know you started to go down that road. But take half a step back for me and just do a hit on, from your view as a practitioner, this will be really interesting, not as a marketer, right? In your view, what is ARK? What does it encompass? So if you were to just ask me as like a lay person explaining it to my father, who's also a lay person when it comes to tech, I would turn around and be like, it's a branding term. It's a collection, a suite, a bunch of different technologies that Microsoft has enabled to be cloud connected. So let's say you have SQL servers on-prem or hosted in AWS even, and you want to kind of control them from a single pane of glass, or you want to just monitor usage, you can leverage Azure Arc in some capacity. If you are large in the Kubernetes ecosystem and

you have maybe, again, AWS EKS stack, so that's Elastic Kubernetes Service, or AKS in the cloud, that's Azure Kubernetes Service, or even you're just running your own Kubernetes cluster on a Raspberry Pi in your basement, you can connect that through Azure Arc to your Azure subscription and tenant, where then you can, again, manage it through a single pane of glass. You can leverage command line. You can use it as a jump off point for automation, a host of other things. And those are just two of the many Azure Arc connected services that exist right now. Well, let's pick one.

Let's pick one because like SQL Server, I'm sure you guys do a ton of SQL. It's, you know, one of the most ubiquitous databases out there. When you think about how SQL is made available or visibility for SQL or manageability is made available through Azure Arc. It's a bit of a spectrum, though, isn't it? Because some you're talking about some of the visibility into what's going on in your entire ecosystem. But then there's this whole other managed services bit that I want to get into and understand too. So kind of break that down and let's just use SQL as a baseline app that most people understand. Yeah, so when you're thinking about SQL and if you were to ask someone on-prem,

hey, I need a bunch of SQL servers spun up for something, whether it's a production workload or maybe some developers are testing some software and they need just a boatload of SQL to test it against. Traditionally, if you're familiar, it's a somewhat manual process of installing SQL Server. If you want to worry about high availability, you need multiple servers to spin that up. You need the right storage and you need to worry about fault tolerance and all of that. So there's a lot of unique skill sets and fault domains you need to worry about, just to even set it up and sprawl it. With something like SQL Server managed instances

that's deployed on-prem and managed through Azure Arc, you're leveraging the, I'm going to start throwing out a lot of words here, so let's try to keep it simple as possible. You're going to be leveraging a small little virtual appliance

that lives on your hardware on-prem, and that appliance is going to be communicating up to Azure, and when you say, I need a highly available SQL deployment, it will phone home to your hardware on-prem and it will spin out a couple containers of SQL Server. So ultimately, this is running a Linux version of SQL because that's a new thing now that you can do with SQL

Server. You can have a Linux build of it. It's running inside a container image. If you're familiar with containers and Docker, it's running on a similar engine to that. And it is scaled out using Kubernetes that is also managed for you across all of those pieces of the hardware that live on-prem for high availability. And your storage, which is already clustered and configured through the magic of hyper v or if you're using vmware you can also use that um it is able to um leverage the existing high availability nature of that and now you just have these pods that are pods containers that are running across all this hardware uh certain vCPU size, certain memory size that are based on some parameters they may pass them when you said to go deploy it.

And let's say there's some kind of catastrophic failure on one of those containers. Well, the magic of Kubernetes will spin up a new one for you and your data stays resilient. So again, I'm throwing a lot of words out there, but at the end of the day, the whole architecture is built around you not needing to worry about that high availability because it's all handled for you at deployment time. So as long as your prereqs are met, which is give me a hypervisor to put this on, the product itself handles the actual management and lifecycle of it. Well, it's interesting because I think it matters who you're talking to, because if you're talking to any app developers,

what you just described, first of all, they'll probably never see it. They just know SQL's working and they don't really care. And you say things like containers and they nod along because yeah, we get that sort of lifestyle. The traditional application managers though, when they hear SQL on Linux in a container, probably had some sort of blood pressure rise of 20 to 30 points. Yeah.

What have you guys found as you've been working on this in terms of acceptance? And it's just kind of weird, right? It is. acceptance and it's just kind of weird right to think about doing it that way it what what have you seen in terms of your reaction from practitioners and their willingness to to say yeah maybe i don't want to do the legwork of installing and updating sql maybe it would be nice just to you know kind of click a button and go so that that's that's a major one. The actual not having to worry about patching an operating system and then a build of SQL that also lives on that operating system is huge because I can tell you right now we have some large on-prem traditional SQL server availability group

deployments and despite them being virtualized and us having enough high availability and resiliency to reboot one at a time and update one at a time, it's a headache. It is a very orchestrated song and dance just to get us through that patching cycle. And it's not that it's difficult, but it's time consuming. The beauty of containerization is you have something called a base image with which contains those binaries of SQL Server. And those don't necessarily have the persistent data of the database itself in them. So when you're just updating, you're just saying, hey, spin down this image, spin up a new image with the new binaries, and just attach the data back to it. And it's not instantaneous, but it's pretty darn near instantaneous.

So the patching and update cycle is reduced down to minutes instead of hours in some cases, or days depending on how many machines you're dealing with. You also mentioned the kind of obfuscation of the back end. One thing I've been trying to get through

to our developers for years now is, and this is a term that's very popular in the IT world, stop treating your servers like pets, treat them like cattle. And what I mean by that is it's a SQL server. Who cares if the operating system, like unless you're doing very, very customized customizations and tweaks and stuff on the OS, which I don't know why you would be, if something bad happens to that SQL

server or that OS, it doesn't matter. As long as the data integrity of SQL itself, the databases, the MDF and log files are still good, that should be all you really care about at the end of the day. So again, with this containerization portion, yeah, the traditional admin may turn around and kind of crawl in their skin a bit about thinking, oh my goodness, I need to be familiar with Linux now. I need to be familiar with Kubernetes and containers and how do I troubleshoot things?

You kind of don't. Again, if the data is good, kill a pod if it's acting up, and it'll just spawn a new one for you. And assuming the data is good and copacetic, it'll mount it and you'll be back up and running. And if for whatever reason that container, that specific one of N amount of containers for your high availability is not working. The natural resiliency of Kubernetes where there's health checks built in to say, hey, can I even listen on port 1433? All those things are kind of handled and it removes things from the load balance equation so that you're not hitting a bad node, for example. So those are the two biggest things for us. It was getting to the point where we don't treat our servers like pets. We treat them like cattle,

and we eliminate them when it's time to. Turn them into juicy steaks. You know, it's funny, I'm laughing because you said don't treat your servers like pets. When we started, not StorageView, but the company before, we hosted all of our own stuff. We did have some databases. We had all the stuff that growing small businesses have. And we absolutely named every single one of our servers, which is absolutely hilarious. We named them after famous pigs. Okay. Yeah. So we had Babe and we had a big storage server that was Porky and we had, I don't know, three or four other ones. The fact that I still remember the first couple is surprising. There is sometimes a fond emotional attachment to hardware. I've been in a thousand labs, and I'm sure you've seen the same, where the bezels will be there, and then there'll be the yellow tape, like the little printout tape that'll have a server ID,

but oftentimes it's a human name or some sci-fi thing of Borg 33 or whatever. Big ones for us were definitely like Greek gods. Yeah, I'm sure that's one. Transformer names. And then I think in college, my college lab, I was naming them off of budget beers. So there was like Bush, Natty, and yeah, oh yeah. Red Dog, just like ridiculous things.

But yeah, but again, we're talking, you know, when you're talking 15, 20 years ago that those were that was the norm. And I don't necessarily mean naming your computers after beer, but but the the concept of like. just treating them like they're your babies and keeping them up and running was a full-time job. And at the scale that technology has grown at now, you just can't. It's impossible. You're right. I mean, it's different if I'm sitting here with seven servers in a baby half rack in my SMB. But if I'm a serious business, you don't even have to be enterprise scale.

Sure. A decent-sized operation, If I'm a serious business, you don't even have to be enterprise scale, just a decent size operation. Having somebody go in and manually run all that stuff on Tuesday is tedious and it's expensive. And depending on how big your IT org is, and I think that's really the challenge for SMBs is the size of the IT org. You might only have one person that's skilled in doing that. And if they're not there or something happens or they quit or whatever,

you've got a problem. So I do like this notion of as-a-service consumption from an OPEX standpoint of, look, it just happens. And so long as I can get support, if something goes wrong and, and, and that's one of the things you were talking about before, then I, then I feel okay about that. In terms of what you're doing with SQL, managed SQL, or I actually, I'm assuming, are you guys using this? We, we have, we not in product. Well, it depends on what your term is production but no

we're not using it from a we are using it at our workplace for our developers and our engineers to rapidly spin up and spin down kind of like test environments for the software that we write um traditionally that would have been a vm VM with a sysprep image of Windows and SQL Server there, and then there were manual steps that needed to occur. But from soup to nuts, start to finish, that process was taking 10-15 minutes, and now it's

down to 10-15 seconds to make a SQL Server on demand using ARC and the whole suite of tools. But no, we are not running production workloads on it from a customer-facing perspective, only because of the way what we sell doesn't fit into that category.

Right. Okay. But you still see the operational benefits, even on a smaller scale for your app dev teams to be able to get in there to quickly spin things up and theoretically tear them down as well. Absolutely. So for those teams, if they were to consume this through your on-prem

Azure Stack HCI or Azure Cloud, how similar does it feel and where might there be a little bit of a disconnect, if any, maybe not? I'm not sure from a practical standpoint. So from a traditional, traditional being Azure cloud, public cloud, if you're not manipulating this through like Azure command line or Azure PowerShell, you're just clicking, clicking through the Azure portal and saying, hey, give me a SQL managed instance with this amount of vCPUs, and you've got a little slider, and how much memory can be allocated to it, and the storage account or the disk that's attached to it. A lot of that kind of bleeds over into the on-prem managed side of things. You have some similar UI portal nuances, but there's some key differences. And it's mostly, again, about the access you have to the

back-end infrastructure. So meaning you're running this on hardware that lives in your data center. It can technically live in Azure on a VM as well. I don't know why you would do that other than just to kind of like test it. But you are managing and you are responsible for the physical hardware and the networking there as well. And while I did say earlier that, you know, oh, your pods and your deployments, you know, if they're healthy, you're good, and if they're not healthy, you just delete them and you spent there, there obviously can be

like a hardware fail. Like we've if we've been in a data center, you've had a failed rate controller happen once or you've had a disk die on you, or you've had, you know, backplane issues, those types of things can still happen. And you as the customer are responsible for for administrating them so there is some back end administrative tools that you have available that you wouldn't have had available in the public cloud um you also can just directly manipulate the uh again i mentioned earlier this is all orchestrated for kubernetes so if you're familiar with Kubernetes, you can also kind of dig into it through the Kubernetes controller. It's called kubectl. It's the command line tool to manage Kubernetes. You can also get into it that way and kind of see what's going on and troubleshoot and scale things out manually if you wanted to. Again, you basically have more things exposed to you on-prem

versus in the cloud where a lot of it is, again, obfuscated behind a pane of glass. Okay. But you still, through Arc then, if you're running in your hybrid environment like this, you're still getting the visibility into all of these workloads regardless of where they are, right? Correct.

Yeah, you're going to see databases and performance stats and metrics and all of that, and you can control it directly through ARM, ARM being Azure Resource Manager. So if you had automation and templates made to say like, hey, Azure, here's a template file with these 20 SQL servers that you've made with these settings and these names and this type of performance,

these metrics, CPU, RAM, you can shove that into Azure ARM and it'll spit it out on-prem for you, again, without you having to actually be at your keyboard in a cluster typing and saying do this and a lot of that a lot of that is analogous to what you would have already been doing with azure um with with traditional azure cloud managed sql they've they've kind of like unified the terminologies yeah so when you think about managed sq, then we talked about deployments fast and easy.

It's resilient, sort of inherent in Kubernetes. Patch management kind of goes away and is automated and part of that service. Is there anything else at a high level that's really important to call out, either operationally or just you know just from a from an overall benefit standpoint so there's definitely benefits of running it on your own hardware because you get to control like the the nuance of performance um right in the cloud you tend to the traditional cloud you tend to pay a lot for uh premium or ultra SSD, for example, or a storage account that may allow you to have a certain amount of IO or even like inter-site bandwidth issues.

If it's on-prem and your workload that's touching the SQL server is also on-prem, you obviously get the benefit of it being hyper quick in terms of latency, because you're probably in the same data center. So you don't need to worry about the internet or Azure's backbone being a bottleneck. You also get to control the storage that it's running on. And that's probably something that you guys see every day. If you know that you're running something

that's like super read intensive versus super write intensive. Well, you can, if your hardware on-prem can be customized from your OEM of choice, you can say, I want this specific type of NVMe or this specific type of SSD, or maybe I don't even care about the IO or latency in the sub-microsecond range. I care more about the capacity. I have a petabyte of SQL data that is kind of right once and red never,

but it just needs to be there. So you can throw a bunch of spinning rust at your cluster and well, it's there. You just get a lot more customization for your workloads. And that's not something that you can do very easily in Azure. And even if you can,

it's going to be significantly more expensive because you have to pay for that storage in Azure on a monthly basis. That's always the rub right is you get it fast and you get it easy in the cloud but as soon as you as you say want to drip into some of the more premium offerings around storage or connectivity I mean the cost starts to get out of control. But during COVID, when we had all these accessibility and supply chain issues, the cloud was still there and it was doing a pretty good job. And I do hear a lot about trying to take some of those expensive workloads and repatriate them and put them together. For me though, Azure Stack HCI has been such an anomaly because it's so much more cost effective

than a lot of the other HCI solutions. And it's really fast. It's faster than vSAN. Yeah. Now we haven't tested vSAN's ESA, but up to that point, everything we saw, Azure Stack HCI was always faster and by a wide margin. I do think, especially for smaller orgs, SMBs, it's a great place to consider an investment if you're a Microsoft shopper, can become one.

If you have an Azure subscription available to you, it is a no-brainer to just go download the trial, install the ISO on some kit that you have lying around and just give it a spin. You basically get it for free for, I don't remember if it's 60 or 90 days at this point. While raw IO is so important to a lot of people, it's a great metric. I, in my world have found that the amount of IOPS, if I'm getting 2 million, 6 million, 12 million IOPS, that to me isn't necessarily the most important thing. It's more the latency that I can, or the lack of latency, I should say,

that my workload is possibly generating and being affected by. But again, it's also that support structure you get with the product. I can remember back in the server 2016 and 2019 days, just to just keep apples to apples here, so to speak with Microsoft. When Storage Spaces Direct first came out, there were a lot of issues, there were a lot of problems. I had to open up enterprise support tickets all the time. And it got to a point where the support experience wasn't great for one reason or another, whether I was getting someone that may not have been technically skilled to answer our unique questions, or we just had some weird bug that we ran into and we just needed to get the product group involved and we weren't getting that channel.

The difference is with Azure Stack HCI, when you have a problem, you are opening a ticket through the Azure portal. And again, it's this unified experience where it just kind of comes free with the price you're paying for Azure Stack HCI on the monthly basis. And they have a unique set of engineers that are just tailored specifically to this. You're not going to be getting third-party contractors that maybe they're outsourcing or working with on the side. It has been a night and day shift. And again, in our world where it's critical, we need to have that support that can actually hold us up in problem times. Well, that's a hard thing to articulate too because Microsoft will say in a press release

or in some sort of scope document around Azure Stack HCI, we have this stuff, but until you need it, until you use it, most people when they buy these things don't spend a lot of time creating provisional tickets just to see what the experience is like. So the story that you just told is one that needs to be told more probably because, again, that's a tremendous part of the value prop of the ongoing OPEX benefit of doing any of these things either as a service and sort of even on-prem Azure Stack HCI is sort of service-y, I think, in the way they bill it as sort of a subscription, right? So you're paying

for the hardware, but then you've got the licensing for the software that goes with it. But that needs, if you're going to deploy that model, that needs to be supported and it has to be a really great experience for customers or they'll be gone on the next week absolutely yeah i can't tell you the like if it's 365 days in a year we have a production workload running and you know five days of the year we have an outage let's say which is a lot um the aggravation and stress and the receding hairline that that is a result of all that stress causes. And if I just had a better experience, how like I could. It's one thing outages happen, but it's another thing when you're dealing with with with something that just isn't getting the movement that you expect it to.

And I just have in the past two and a half years that we've been running HCI as our primary production workload hypervisor, just the whole suite of everything. I have yet to run into that experience. I've opened up dozens and dozens of tickets, and every one of them is closed within days, like full problem resolved. Again, I'm not just blowing smoke. It has been night and day.

Well, that's an important consideration. We talked a lot about SQL. I think I might have managed virtual desktops and AKS as we sort of drove through the notion of Microsoft really wanting to take these cloud services and push them down to Azure Stack HCI. Do you have any hands-on experience with either, or are there any other services you guys are using that you're excited about that can transition between your hybrid cloud scenario? Yeah, more so than even the SQL solutions that they have. AVD on HCI, which is Azure Virtual Desktop on HCI, is the next big thing that's coming down the pike. GA has not been announced yet. It's been public preview for well over a year now.

For a while, yeah. Yeah, you can think of it as kind of the competitor to like VMware Horizon or Xen, Citrix's product. If you're familiar with AVD in traditional Azure, it's basically spin up some VMs on demand in Azure and users can RDP to them through the remote desktop client app, the new one, not the one that's built into Windows.

And you're able to have pooled multi-session machines or personal one-to-one assigned machines. So that's now available on-prem through AVD on HCI. We are very heavily interested in this, again, with remote work and kind of avoiding large CapEx purchases for like laptop recycle, hardware recycle refreshes, things like that. And then also being concerned about data governance and another one that's thrown around. Yeah, security. But then another one that's thrown around is data gravity.

And I'll explain that one in a minute. That was kind of the reason why we're like, hey, this is where we got to focus our energies on as the next thing. So it's still in public preview, ABD on HDI. We're hoping to get some more information in the next coming weeks or months on general availability and pricing and kind of what that's going to look like and then the roadmap for all the features. But we're super excited about it. Well, I mean, any more with the the thin clients are so nice now these days. Yeah, the you know, bring your own device and having just an RDP session, as you said, to get into your work machine. The technology to push pixels over the line has become so good.

Yeah, we do. We do a ton of thin client reviews and user computing where we're looking at at these you know workloads specifically and yeah i mean you you may not necessarily you know want to edit 4k ak video on your general purpose machine but you can amp these things up of course absolutely things like gpus and now if you've got a a big distributed workforce well rather than putting a you putting a several thousand dollar GPU in every system, if I had some in the data center and we just managed access, I mean, that goes a long way to making teams more efficient. And around the security bit, the pushing pixels is a lot safer, all that data stays in the data center, and it makes it a lot safer that all that data center or all the data stays in the data center yeah and it makes it a lot harder to to leave a laptop behind in a in a cab or an uber i guess

or whatever and uh for international teams you might be worried about uh corporate espionage things like that i mean those are real problems data exfiltration is the number one concern that keeps me up at night and i tell that to my security guys. Yeah, you said it best. Pushing pixels is a lot more secure than even a VPN connection. That may be encrypted, but if John Doe is using his work laptop, or I should say his personal laptop, and he installed VPN client on there and forgot to disconnect. And then his kid goes on and decides to start doing whatever on there. Lord knows what could end up happening between that tunnel from point A to

point B, you know, whether it's crypto where and you can have all the endpoint protection you want and firewall rules you want. But if you open up that door, they can get in. And the beauty of remote desktop is it's literally just like pixels and audio and video it's it's it's not really a big concern or i should say it's less i just love having i just love having the stuff in the data center so that you can back it up i mean that's well that's that too so you you mentioned um a dispersed geographical workforce and we have a

lot of that here we have a large uh we have a large workforce in australia we have a lot of that here. We have a large workforce in Australia, we have a large workforce in India, and our main data center is in New Jersey. So when these folks need to manipulate large files, tens of gigabytes in size, doing that over a VPN connection is basically like, it's not impossible, but it's pretty darn improbable to have a functioning, you know, worklife balance. You're just going to be sitting there forever. So giving them jump boxes, if you will, that live in our data center, and this is that term data gravity, the data is the big thing that necessitates performance here. So having their VMs local to that data allows them to manipulate that data significantly faster

at the cost of some latency with the RDP session. But that's just screen redraws and mouse clicks. That's a lot faster than moving 10 gigs of data over the wire and who knows how fast that pipe is to even get it across the water. So that was the other big reason. You said backups obviously are great. It's local or data center. But just the user experience is significantly better. Yeah. So you're doing virtual desktop.

Are you doing some on-prem now? Are you doing that in Azure? We are heavily, heavily testing it on-prem. We are currently leveraging Azure public AVD, like traditional AVD. That's kind of like a fail over type of scenario. So if the 14 internet connections to our data center went down and no one could get in, yeah, okay. We spin up some VMs in the cloud and they connect to those. But yes, we have a couple hundred VMs that are being used individually by users as personal session hosts. And then we also have a number of multi-session Windows 10 and Windows 11 VMs that live on-prem. And that's kind of where this is going to be big for people. Getting access

to Windows 10, Windows Client SKU multi-session on-prem and not have to be in the cloud. And you can load up like 10, 15, 20 people onto a single VM. Yeah, it's got more cores than maybe your normal one-to-one, but you can densely pack that thing up. And again, if you got GPU partitioning enabled, man, oh man, there are some potentials for big cost savings there. Yeah. I mean, that's the trick, right? Is these, the evolution of these products tends to be, you know, Gen 1 is pretty baseline, task worker friendly kind of stuff. I don't know if GPU slicing will be in the initial GA. I don't know if you have any visibility into that, but the way, the speed at which they layer on additional features, I think is going to be pretty critical to the success for AVD on-prem. I don't see any

other way. If they can't do it quickly, it may not catch on. Well, that's the beauty of this iterative approach with the whole HCI stuff in general. So just to kind of segue back to Azure Stack HCI, the operating system to begin with, you are having a release cadence that's every year now. And in reality, it's almost every six months only because you're getting those public previews fairly quickly out to the public to even test this stuff.

So, yeah, we got GPUP, that's GPU partitioning, in a recent release of the OS itself. Well, now that allows your layers of services built on top of this OS to leverage it. So AVDHCI now, it's not publicly available yet, but GPUP is going to be available to it. Same thing with AKS hybrid. So your Kubernetes workloads may need a GPU, not for actual like graphics processing, but maybe doing some very specific floating point math or number crunching or goodness, any kind of crypto nonsense that I'm not well versed in. And if you have that, if you have those exposed to your VMs, okay, well, now you're able to let your containers touch the GPU itself. So there's a lot of benefit there. I think machine

learning was the big one with Kubernetes and GPUs on-prem. That was the kind of like, hey, we have these images that need to be processed and kind of pick out things with them. You know, like, is this car, is this human, is this dog, that type of stuff and what you can move there. Yeah. You, you mentioned at the beginning and then just, just a second ago, the Azure stack, HCI OS getting more regular updates, a quicker cadence there. Do you see an expansion of what Microsoft is doing with managed SQL into other elements of this infrastructure? Do you see a

vision where Microsoft does the whole management of the software on Azure Stack HCI, for instance, or other components within the system? So there definitely are things that are happening. I can't go into too much detail about the new features that may or may not be coming. Yeah, this is where my MVP hat comes on. I have to be careful with what I say. I can say that there's a lot of exciting things that I know are on the roadmap. One of the more recent ones was the release of,

and I think it's technically public preview still. I don't think it's GA yet. Just to link back to the support experience, the ability for you to have a remote support experience with Microsoft. You basically install a small agent that's connected to Azure that lives on your Azure Stack HDI host. Let's say you have to open up a ticket.

You open up a ticket. The support representative says, hey, can you allow me to dial in phone home, whatever the term they're going to use is, and they can get onto your machine for a certain amount of time and collect logs. They can only do kind of like read operations, not like set operations in PowerShell.

So it's a lot of gets, not sets. And they can collect data without you having to be the person to be collecting it for them. And that's great because you can significantly speed up the troubleshooting process from maybe one to two days to one to two hours. There was a lot of work going into the network desired state aspect of this. So again, you have your hardware deployed in your data center.

Day zero, you need to rack it. You need your network switches configured in a certain way. It's one of those things that you do once and you never think about again. And so you buy new hardware and you have to do it again. Or, oops, the server needs to be reinstalled. I need to do it again. That desired state is being worked on dramatically by Microsoft. The technologies that they're working on.

It's Network ATC and Network HUD. Those are the two very related products that Microsoft is going to be pushing in the next release of Azure Stack HCI. They will allow the OS to talk to the network switch, learn information

from maybe this switch port was misconfigured. Hey, and it'll send an alert to you and say, you need to go talk to your network admin and smack it around a bit to fix it. Just things like- Jeez, you guys are draconian over there. Hey, we can, that's a Dan Cuomo conversation

you can have at Microsoft, but I love the ability to be able to see all this. And then again, with it being all ARC connected, I love the ability to be able to see all this. And then again, with it being all ARC connected, a lot of this information ends up in the Azure portal, these alerts, these management tools where you can directly control and react to them in a single payment class. So, I mean, yeah, that's pretty neat.

And I think it comes back to then, I mean, you're a big advocate of Azure Stack HCI on-prem. I told you a little bit about our experience from a performance standpoint, and it's really pretty remarkable. The HCI product aside, you can go do a POC or get the license trials to go do that on your own test kit if you like. But it seems to be the Azure Arc thing is going to be broadly applicable to, as you said, a wide audience that's using Amazon or VMware or Azure or any of this stuff. You're not the sales guy, but is there a POC

or a pick up and go kind of way to start to experience ARC? The easiest way right now is to open up your browser and Google Azure ARC Jumpstart. Azure ARC Jumpstart is managed and maintained by a group of Microsoft employees that are brainiacs, super smart people. Basically, it is a single click and deploy into an Azure subscription where depending on the scenario you pick,

it will spin up your infrastructure for you in a lab environment. So we'll focus on SQL Server for a minute. You can pick the jumpstart for SQL Server managed instance through Arc. It will deploy a domain controller in the cloud for you as a small VM. It will deploy an AKS cluster in the same subscription in the cloud, and it will configure all the Azure Arc goodness extensions and what have you that you normally would have to use PowerShell or maybe the command line to enable.

It will run all these for you. It takes maybe like 30 minutes to 60 minutes to deploy the whole lab, but it will give you an environment that you can play around with like a sandbox and destroy it. And if you do, you can just delete it and recreate it with just another single click of the button. No, I love that.

I mean, NVIDIA has done a really good job with their launch pad uh set up for people that want to get touch some of the hardware like gpus and the bluefield smart nix and and other stuff because not everyone is going to especially when you start getting into the hardware going to be able to spin those things up and and can't go requisition a box of bluefield just to mess around with. So these labs, these companies have got to get smart to help their customers and prospects get hands-on and play. So that's pretty cool. I'll find a link to that and put that in the notes too so people can check that out. Ernie, this has been a great conversation. I love hearing from the practitioner standpoint, what you're doing, the things you're thinking

about. I think that's useful to the broader IT audience. You managed to get through this without being too much of a Microsoft fanboy. So that's good too. Yeah, try not to show. But no. You did a good job of playing in the and and delivering the information as you see fit and for for an organization your size to be as far into hyperv azure stack hci azure cloud all this other stuff is is uh pretty remarkable you guys are are out

there in the front so we we appreciate that and it's been a great conversation. Yep, great. Love doing this type of stuff. Anytime you want to chat, let me know. You got it, buddy. Thank you. All right. No problem.