(Note: AVS – Azure VMware Solution – is not covered in detail here since it’s essentially outsourcing VMware onto Azure’s hardware. That involves a different calculus: you avoid buying hardware entirely, but you pay cloud rental fees and must fit into Azure’s instance constraints. In this post, we focus on on-premises alternatives where you control the hardware.) Hardware Considerations: Build Your Cloud on Your Terms Series Recap: In Part 1 of this series, we examined the total cost of ownership (TCO) implications of different post-VMware paths, comparing capital expenditure vs.

Welcome to Part 2 of our “Beyond the Cloud: The Case for On-Premises Virtualization” series. In our introductory post, we explored why organizations are reconsidering their virtualization strategies post-VMware acquisition. In Part 1, we conducted a detailed five-year Total Cost of Ownership (TCO) analysis comparing Windows Hyper-V, Azure VMware Solution (AVS), and Azure Local, revealing how different cost structures impact long-term budgets. A key factor driving those cost differences was how each platform’s licensing model works.

Introduction In our previous blog post, we explored why organizations are reconsidering their virtualization strategy post-VMware and highlighted the often-overlooked value of Windows Server Failover Clustering with Hyper-V. Now, in this first follow-up post of the "Beyond the Cloud: The Case for On-Premises Virtualization" series, we dive into the financial side of that decision. Specifically, we will compare the five-year Total Cost of Ownership (TCO) for three possible platforms to run a 100-Virtual Machine (VM) workload:

Why Choose Windows Server Failover Clustering (WSFC) with Hyper‑V Over VMware Virtualization is a cornerstone of modern IT infrastructure, and VMware vSphere has long been a leader in this space. However, Microsoft’s Windows Server Failover Clustering (WSFC) with Hyper‑V offers a compelling alternative for organizations seeking a cost-effective, high-performance virtualization platform. In this post, targeted at IT professionals, we’ll explore why WSFC with Hyper‑V is a strong alternative to VMware – emphasizing the ability to leverage existing hardware (reducing new hardware costs), the performance benefits of Hyper‑V, available management tools, feature comparisons with VMware, and a look at licensing and cost differences.

From My Perspective as a Microsoft Azure Hybrid MVP – Two Decades in Microsoft Hybrid & HCI I write this blog as a longtime Microsoft advocate with two decades of hands-on experience—from early Hyper-V in 2008 to today’s Azure Local. This series aims to highlight the potential of Windows Server Failover Clustering (WSFC) as a viable alternative for organizations transitioning away from VMware, especially in light of Broadcom’s acquisition. While I value Azure’s Cloud and Hybrid offerings, I believe Microsoft’s current messaging overlooks WSFC’s capabilities in providing cost-effective, high-availability solutions.

Introduction Azure Local (formerly Azure Stack HCI) Key characteristics and features Azure Local Use cases Traditional WSFC with External SAN/NAS Storage Key characteristics and features Traditional WSFC Use cases Windows Server Failover Clustering with Storage Spaces Direct (S2D) Key characteristics and features WSFC with S2D Use cases Comparative Analysis of the Three Solutions Comparison Matrix Azure Local – Pros and Cons Traditional WSFC + SAN – Pros and Cons WSFC + Storage Spaces Direct – Pros and Cons Industry and Workload Considerations Industry Examples Workload Examples Optional Azure Integration for WSFC (SAN or S2D) Clusters Decision Framework – Choosing the Right Approach Conclusion Introduction In modern Windows infrastructure, there are multiple strategies for building highly available clusters.

With Azure Arc-enabled servers, many of us are already familiar with the ability to establish SSH connections to these machines. If this is news to you, here’s something exciting: you can SSH into Windows machines that have been onboarded to Azure Arc! Now, I can imagine security professionals having a moment of concern—yes, you read that right: SSH access to Windows machines onboarded with Azure Arc is possible. Here’s an even bigger revelation: this applies not only to on-premises machines but also to Azure Arc-enabled servers running on other cloud platforms like AWS and GCP.

They say peanut butter and chocolate are better together, but have you ever heard anyone say AWS and Azure are better together? How about having a centralized solution to manage both your AWS and Azure resources seamlessly? Well, I have something exciting to share. It’s not chocolate and peanut butter, but it will definitely make managing resources across a multicloud environment much easier. Let me introduce you to the Multicloud Connector enabled by Azure Arc.

There are several key differences when deploying an Azure Stack HCI Cluster using a premier solution like Dell’s APEX Cloud Platform for Microsoft Azure versus using an integrated system. For detailed information about Azure Stack HCI solution categories, please visit Azure Stack HCI Solutions. One notable difference is the use of a service principal in the cluster deployment for APEX and the necessary Azure roles that need to be assigned. In contrast, integrated systems require deployment through Microsoft Cloud, either via the portal or ARM Templates.

There are several methods to deploy an Azure Stack HCI OS Image. You can use solutions like System Center Configuration Manager (SCCM/ConfigMgr), Microsoft Deployment Toolkit (MDT), Windows Deployment Services (WDS), or other Infrastructure as Code (IaC) tools like Terraform and Ansible, with the appropriate configurations. Additionally, Canonical offers a solution called MAAS (Metal-As-A-Service). Throughout my career, I’ve generally preferred Microsoft solutions for deploying Microsoft Operating Systems, favoring tools like MDT and WDS.