 Yeah, fixing your hair, that's good. Now, I'm looking forward to the funny outtakes that TB cuts together. Okay, perfect. So welcome back to our Azure Stack Hub Partner Solution video series, and I'm here again with Tiberio Radu from the Intelligent Edge Solutions team at Microsoft. Hi, TB, how are you doing today? Hey, hi, Thomas. Very well, thank you. How are you? Perfect, I'm doing great. So I want to ask you, we have a partner in this call to show his solution and what he is doing with Azure Stack Hub. Can you tell me a little bit more who I'm going to talk to later on? Definitely. It's not a surprise, and he's a friendly person. We have, as we discussed last time, we have a number of partners out there that are offering both managed services as well as building their own platform. Eversource is an example of a customer that's actually building their own platform and they're having their hybrid cloud developed by themselves in Health, if you want. So their journey is quite interesting and they started in Azure and they were looking to standardize on Azure as a product. That also means that they did a solution for their own premises and that solution was Azure Stack Hub. Obviously, being a regulated energy company, they have certain workloads which cannot live on premise. They need to be held in a specific region and all the security requirements that they need to answer and Azure Stack Hub met those requirements without actually changing their operational behavior, so to say. The other thing they benefited from was the extended support for the Windows Server 2008. So as you probably know, the Windows Server 2008 entered its end-of-support period in early 2020 and this is when we started this program that offered pre-extended security updates if you would move these workloads to either Azure or Azure Stack Hub. So Azure Stack Hub is looking to take advantage of these and to move these older workloads on Azure Stack Hub as a temporary solution until they are able to modernize the workloads. I don't want to take too much of their thunder, so I'll let you guys talk about it. Thank you very much, TB. So yeah, let's switch over to Michael from Azure Source. I'm looking forward to talking about how they are using Azure Stack Hub. Hi, Michael. So how are you doing? I'm great, Thomas. How are you doing? Thank you so much for having me today. I appreciate it. No, I'm doing great. So I want to quickly ask you, who is Eversource and what are you doing with Azure Stack Hub? Sure, perfect. So Eversource Energy is a regulated energy company up in the Northeast. We have a bunch of subsidiaries that offer retail, electric, natural gas, and water service to around 4 million customers across three states, Connecticut, Massachusetts, and New Hampshire. So who I am, I'm one of the cloud domain architects that work at Eversource Energy. My focus on is Azure Public Data Center and now hybrid infrastructure with Azure Stack starting to come into the on-premise part of our Azure environment. Also trying to define our hybrid infrastructure as well as some of the focus in Azure networking. So some of the things of why we chose Azure Stack Hub, one of the initial benefits, obviously, is the 2008 extended patch support that Microsoft's offering with both Azure and Azure Stack Hub. But that's not the only reason why we saw a benefit with Azure Stack Hub. So let me rewind a little bit. About two years ago, Eversource started their adventure into Azure Cloud. And we started that really with like a lift and shift methodology of moving some of our dev and test workloads up into Azure Public to help gain the benefit of being able to shut those workloads down, manage them, and also not have to manage the back-end infrastructure. So really taking that part of it out and using the benefits of the Azure IaaS platform for compute and being able to manage our workloads, shut them down, save costs, and really only use the workloads when we need to. So now that we've become a little bit mature in that space and our Azure public environment has grown significantly and we're starting to look into PaaS base and we've had some other larger initiatives in the Azure public space, fast forward to Azure Stack Hub. And really one of the main reasons why we chose it was we want to try to standardize on a single product base. For the on-premise data center, now what Azure Stack Hub brings is it allows us to bring Azure into the data center, albeit on a little bit of a limited feature, not every feature that's in Azure public, but definitely features that we can leverage now and start standardizing our Azure platform in the cloud and on-prem. So really, like I said before, the Windows 2008 extended patch support was really one of the driving factors. Since we're a regulated environment, we will never achieve 100% cloud-only footprint. We like to say our director, Sue, is that we're cloud-right. So we're really careful on where we deploy our cloud solutions, whether they're in the cloud or if they have a stay on-prem, but we're also regulated. So there's just some SIP and SCADA and some regulated type services that just can't live in the cloud right now. Or due to latency bandwidth requirements, it's just it's not a right fit. But Azure Stack Hub helps solve some of those problems because we can keep that infrastructure in the data center, leverage PAS and IaaS type footprints to now standardize on Azure in the data center. And really the driving force right now is IaaS, more in the middle of our migration to move some of our workloads off of our existing hypervisor platform onto Azure Stack Hub. So that sounds actually great. And I think you're really taking advantage of our hybrid story here where you actually get, where using Azure, but also take advantage of things like Azure Stack Hub to really get into that hybrid play. And as you said, really, really interesting, the Windows Server 2008 extended security support for Azure, but also for Azure Stack Hub. And then obviously having that consistent experience between like Azure and Azure Stack Hub and actually, as you said, bringing Azure into your data centers. So you mentioned that you're actually are migrating workloads from your virtualization platform to Azure Stack and Azure Stack Hub. Can you explain kind of like what workloads are we talking about? Sure. So mostly right now, like I said, we're focused on 2008 workloads, but they can be anywhere from IaaS servers to just standard application based servers. The one thing that, you know, we're also being very careful with what we migrate. We wanted to take kind of the crawl, walk, run report approach as Azure Stack Hub still a little bit new for us. So we are still getting our feet wet. We really started off with some dev and test just to prove that, you know, we can get the workloads over that, you know, the running access is what we need and everything's working properly. And I want to say we've kind of moved past that we started moving some of the prod our prod environments over there. And it's gone well so far. You know, we have it took us a little bit to get our migration process down because as you as you know, as ours not supported to move on to stack yet. But we were able to leverage a product called Veeam. So it took us a little bit of working to get that migration process down. But once we got it down, you know, we're able to migrate, you know, a couple servers a night into Azure Stack Hub, you know, then clean stuff up in the in the old virtualization environment. But for the most part, it's going really, really well and we're starting, you know, for a lift and shift that's usually the easiest way for anybody to get used to a new platform. We did an Azure public. We kind of follow the same mentality to Azure Stack Hub, but mainly like application and web and web based servers. What we're really trying to be careful about is really more chatty and bandwidth intensive applications. We're taking a little bit of a slower approach with those and just making sure that we have a good experience with the first initial workloads that we put on stack. Okay, yeah, that actually makes a lot of sense, but I'm happy that your journey or migration journey is going that well. And so that sounds really like you can really take advantage and to benefit and get some benefits out of that platform. So you were speaking about, okay, your lift and shift migration and how you're migrating in on these on these platforms. Can you also share a little bit about about that process and also like how you probably modernize your application once there are on on Azure Stack Hub or there are an Azure or before you move them. And just like your lessons learned from all all the things you're doing. Sure, so one of the biggest things we've learned is is trying to understand and not so much our team because we support the infrastructure, but making sure we really work with the application owners to understand how the application works. What are all the connection points of the application? What does it touch do? Is it a self sustaining standalone app on one server? If you move it in there into the Azure Public or Azure Stack, what does it need to talk to outside of that environment? It's really doing like an application based mapping of the app before you move it. Those were some of the lessons that we really learned. I don't want to say the hard way, but they were some of the challenges when we started with our Azure public journey was really understanding those applications and what they had to talk back to on-prem or within other servers within Azure or in this case, Azure Stack Hub. So it was really working with the application owners. Dev and test were easy, easy or because they're not as critical. When you start getting to prod, you really have to understand what that application is doing, what it's talking to, what ports it communicates to. Because as part of this endeavor up in the Azure public cloud into Azure Stack Hub, we introduced a firewall application layer. So we put firewalls in both our Azure public data center and our Azure Stack Hub data center. So it was really understanding now so what ports and what they talked to because now you have to make sure that communication isn't blocked when it's being front-ended by a firewall. So it took a little bit longer, but the longer you take, the more you understand the easier it is to move the application and for it to be successful once it's on the new platform. You know, I would say that that was some of our biggest challenges and lessons learned, you know, in understanding like an Azure public or express route, what the networking limitations were there as, you know, as well as Azure Stack Hub. Since it's a software-defined data center in a box and uses software-defined SDN, software-defined networking, you really have to understand how the networking works with this new hybrid infrastructure platform to really, you know, maximize what you can get out of it, but also understand when you're moving applications into the solution how that affects stuff outside of it. No, I'm like, this is great to hear. I think I completely understand what you're saying, especially when you're saying, well, depth and test, we actually could migrate that. It actually worked fine, right? But as soon as we hit production, there is a different story because I guess you also, like in production, you have much more load on these systems and so you're much faster seeing, for example, bottlenecks or dependencies between different systems which they need to communicate together, right? Yeah, what I will tell people that was very key for us and I personally took a little bit extra time to figure this out is monitoring around the Azure Stack Hub platform, the infrastructure itself, really dialing in and we're leveraging SCOM, and we're leveraging the Azure Stack Hub management pack with SCOM to really forward a lot of that alerting into and out of Stack Hub so you don't have to be consistently looking at a webpage or a portal to see when things are going on, but leveraging SCOM as a monitoring platform to pull all of those alerts outside of the Azure Stack Hub platform into SCOM so you can be alerted more proactively. And also around the network connectivity, we're using a combination of solar winds to help us be more proactive around bandwidth utilization as well as latency and really have a good look and snapshot of alerting around the infrastructure, but also around the networking and the bandwidth that Azure Stack Hub is leveraging and connectivity back into the data center. I would say that that is one thing that I did spend a little bit extra time on to make sure that was all dialed in properly. Yeah. No, I think that makes a lot of sense and working with Azure Stack. I know that like integration into the data center is key, right? So Azure Stack Hub really became part of your environment. It's not just something you put in and it's completely isolated. It really operates in your data center. Yeah. And I would also tell people that if I was to say anything that was the, you know, the most challenging and I would say in a very fun way because I got to learn a lot, you really take your time on the networking piece, really understand how Azure Stack Hub works, how the SDN works and how that integrates back into your on-premise data center or up into your Azure public environment, anything outside of the Azure Stack Hub unit. That was one thing that I will say it was challenging but a fun challenging because I got to learn a lot about SDN and how Azure Stack Hub works. But take your time there, really understand, really come up with the best approach that fits your company. Because that was one of the things that I think I didn't know as much about when we first started, but as we started solutioning, you know, we hit a couple of roadblocks but we were able to get around them. That's some of the best advice is dial in your monitoring and really understand the SDN of when you're implementing the Stack Hub solution in your data center. No, that's fantastic to hear. Again, I'm like, this is super good advice for everyone who not, I would not say even necessarily just Azure Stack Hub but in cloud in general, right? Yeah, absolutely. Where networking is a key piece of it where it's like sometimes we always have done it that way and we're still going to do it that way. That's just not how the cloud and software defined networking works anymore, right? Okay, so we talked about the networking part and how important it is to tie all these things together. At the beginning, Michael, you also mentioned that hybrid and consistency was a big key decision for choosing Azure Stack Hub and Azure as a platform. Can you explain a little bit what are you doing with this hybrid platform and where do you take advantage of Azure Hybrid Services as well as the consistency between Azure Stack Hub and Azure? That's a great question, Thomas, and honestly, I think that is the biggest selling feature and what Azure Stack Hub brings in, right? And as I spoke to earlier on is we're trying to standardize on Azure as a product of choice, whether it's for the cloud or whether it's for our on-premise data center and basically trying to modernize the data center. And what Azure Stack Hub allows us to do, for example, is leverage Azure Automation. So Azure Stack Hub supports hybrid worker servers. So for example, one of the use cases we have for this is in Azure Public, they have the auto shutdown feature exposed in the Azure portal. So you can shut down your workloads as I talked about prior to help mitigate cost. Well, with Azure Stack Hub, that at this point isn't exposed in the portal. But since it supports hybrid worker servers, we're able to leverage Azure Automation and Azure Automation accounts and runbooks to basically do that same type of process that you can do natively in Azure Public in Azure Stack Hub as well as other automation features. Anything that the API supports in Azure Stack Hub using Azure RM, you can code in an Azure Runbook and we have one Azure Automation account that we leverage for both the cloud and Azure Stack. So basically tying in all those automation efforts, not having to manage different types of automation processes, different types of code base or different processes and procedures to do automation. It's really that key of standardizing on one platform and one type of process to do automation or manage these workloads across both our cloud and public and on-prem environments. The other thing I'm sure people are asking, well, how do you deploy IaaS workloads into Stack Hub as opposed to Azure Public? And that's another example of how you can streamline and standardize on one automation process to deploy. Now, as everybody knows, you can use Azure, the AZ modules for public that is coming for Stack Hub, but right now we're using the Azure RM modules to deploy. But we're able to still standardize on that. Leveraging Azure Automation and ARM template deployments in the API for Stack Hub, we basically can have our build process connect either Azure Public or Azure Stack Hub. And depending on where you want to deploy and what you put in for your build options, we'll just deploy the VM to Azure Public or Azure Stack Hub. And it's really taking the concern out of, well, what platform do I have to use? They really shouldn't care about the platform. They should just care that based off of what they need and what the requirements are, that we'll just deploy the solution to the right environment. And that's where the ARM template deployment and leveraging Azure Automation allows us to do that seamlessly across either platform. And that's really one of the strengths that Azure Stack Hub brings in to help standardize on that single product base and really try to modernize that hybrid infrastructure model that we're going to. Yeah, I love that. I really love that hybrid story. So basically what you're saying is, first of all, you can take advantage of the consistency when it comes to infrastructure as code. So you basically leverage the same ARM templates for Azure as well as for Azure Stack Hub. And then secondly, you're also taking the same approach kind of like when you're using Azure Automation. You can basically run the same runbooks against platforms and leverage the same features in that case. Now, this is great to hear. One more question I have is, so obviously we talked about you had a virtualization environment or you still have. And now we have Azure Stack Hub in your environment. How does the operational part change or what is like different? What are your key learnings from the operations part of an Azure Stack Hub? That's a great question because it is a different platform than your traditional hypervisor platform would say like traditional Hyper-V with VMM or VMware. Azure Stack Hub really helps simplify that a bit. And really the way that we broke it out is you have your operations and your management role of the back end hardware depending on the hardware vendor you pick for Stack Hub. And then you have the traditional Azure operator type role. The one big difference with Stack Hub then from Azure public is you really are the Azure operator now. Where Microsoft, because you're in the cloud, they manage all of the back end infrastructure and the back end admin environment, you are now really the Azure administrator because the hardware exists in your data center. So really what we defined is the Azure Stack operator role. And what I did to help our operation support team is I basically created my own Azure Stack operator runbook. And these are all the different things from patching the environment, how you monitor alerts and the different type of resources that you need to monitor from a capacity standpoint on Azure Stack Hub. And that's another important thing to note. Now that you own the hardware and it sits in your data center, you now are responsible for monitoring and managing your storage, your compute, your memory. Because that is all now in your data center where Microsoft and Azure public would do all that for you. Now you have to have eyes on that to make sure that you're not going to over provision your Stack Hub unit. So that Azure Stack operator role does become very important and really it's just defining what the steps and what the areas that an Azure Stack operator needs to look at on a daily basis. As I talked to prior, leveraging Azure Stack, the Azure Stack management pack for SCOM also helps you pull all that alerting out. And depending on your hardware vendor that you choose, they'll have their own type of monitoring tools to manage the physical hardware, hard drive failures, that kind of stuff. But one of the things that I love about Azure Stack Hub is how you actually update the unit, right? In your traditional hypervisor platform, you know, if you were in, you know, like a blade enclosure, you'd have to, you know, do the blade firmware. The enclosure firmware, all the switching in there. Then you'd have to, you know, upgrade your, you know, your hypervisors, your nodes within like your VMware, Hyper-V. All you have to do with Azure Stack Hub is you press a button. You press a button. It says update now and it does it all by itself. And I can tell you when we went to 1908, which basically was to go from Server 2016 to Server 2019, and we have a full 16 node unit, I pressed a button and about, I don't know, 58, 58 hours later, it rebuilt my whole Azure Stack Hub into Server 2019. With no issues, it just took a while, but no interruption in service. And I literally just pressed a button. And that really simplifies all of that stuff you had to do, all the different components you had to manage and upgrade and do on the back end. It really puts it into a single button click push to update and manage it. And that I thought was really cool to actually see that happen and the amount of work that had to go on on the back end to get that to work was truly amazing. And I think that's also a benefit. You don't have to spend as much time maintaining and monitoring and trying to update separate components. You literally press a button, you monitor it, you walk away and you come back and it's updated. Again, I agree with you here. This is one of my favorite examples when it comes to Azure Stack Hub is when you do that update process. And so I know from doing many, many virtualization projects in the past, where we upgraded from different hyper-reversions to the next one, you basically needed to do all that planning on one side. And then you need to go through it and like upgrade all the different components. And for you, it was basically just one press of a button, right? Like you would update your phone basically, like just say. Pretty much. Yeah. No, this is awesome. So I want to thank you very much, Michael. It was a pleasure to have you here. I wish you a lot of success on your hybrid cloud journey. And for everyone watching, I hope I see you in the next one.