Azure Local - Disconnected

Azure Local - Disconnected

Hearing that Azure Local will support disconnected operations gave me a flashback to the 2017-2019 era when we were working with Azure Stack, now known as Azure Stack Hub. Back then, the platform offered a feature called Disconnected Mode, which, as the name suggests, allowed you to operate Azure Stack entirely off the grid in a fully disconnected environment.


Fast forward to Ignite 2024, and Microsoft has announced Azure Local with disconnected operations. While the concept may sound familiar, the approach has evolved. It’s essentially the same core capability, enabling fully isolated, offline Azure operations—but delivered through a new and refined solution.

Azure Disconnected

We’ve seen firsthand how customers are increasingly adopting cloud-oriented models. Development teams across organizations are working to modernize their monolithic applications, moving toward more containerized workloads. These teams seek platforms that allow them to quickly access the resources they need, deploy the code they create, and deliver applications that power their organizations.

While multiple public cloud providers are eager to host these workloads (and charge accordingly), migrating to the public cloud isn’t always a viable solution. In many cases, significant deal breakers arise when considering public cloud providers to host all your data and applications. Some common deal breakers include, for example:

  • Costs
  • Data compliance
  • Data efficiency (as too much data or not efficient to move it all)
  • Latency
  • Performance
  • Low bandwidth environments
  • Fully or partly disconnected environments

With Azure Stack HCI, now known as Azure Local, we’ve been able to deliver cloud capabilities to distributed locations, without many of the typical deal breakers. Azure Local provides IaaS and PaaS services across distributed environments while using Azure as a single management pane. There’s no need for separate management tools for every environment. Just one management interface to manage all your Azure Local deployments globally.

You can deploy virtual machines (VMs), containerized applications, and other resources via Azure Resource Manager, bringing these workloads closer to your users, processes, and data. However, one challenge remained: the fully disconnected scenario. It’s an interesting paradox, after all, cloud is inherently connected. So how does cloud fit into a disconnected scenario?

Cloud computing on distributed locations

Cloud is more than just technology, it’s a way of working. It allows organizations to leverage resources without requiring deep expertise in complex storage, networking, and compute systems. For example, teams can deploy containerized applications and use infrastructure-as-code to simplify their operations.

However, there are scenarios where internet connectivity is limited or nonexistent. Consider ships traveling to remote parts of the world, where even satellite internet may be unreliable or unavailable. These ships rely on increasingly complex software and applications critical to their tasks, such as laying pipelines or fiber optics, mapping and exploring the deep sea, or constructing offshore infrastructure like oil platforms and wind farms.

Oil platforms face similar challenges. These remote environments depend heavily on data and software, yet connectivity is often a challenge.

From another perspective, there are systems that must remain off the grid for security reasons. All of these isolated environments can and want to benefit from the cloud operating model, leveraging its flexibility and efficiency without compromising security.

Rewind back a couple of years

The limited adoption of Azure Stack Hub wasn’t due to its niche appeal for a handful of organizations. It was a combination of factors that made the product less practical and appealing. Azure Stack Hub was too complex, too restrictive, and had a large, costly starting footprint that made it difficult to justify for many organizations.

One of the biggest hurdles was dealing with outdated resource providers and API versions. Since the Azure Resource Manager (ARM) layer was running locally in your environment, Microsoft had to port the Resource Providers and API’s to a local instance. You would expect a small delay in versions since it needed to be altered and tested to run on Azure Stack HUB, however the reality was a gab that was years behind.

Wrong expectations

These limitations made it nearly impossible to deploy software using the same code as in Azure because the resource providers were often far behind in updates. Adding to the confusion were marketing claims such as “Azure in your own datacenter”, which set unrealistic expectations and started many potential customers off on the wrong foot.

When Azure Stack Hub launched in 2017, the product was far from complete, but the marketing was running at Mach 10. At launch, the platform only supported a small subset of features:

  • Basic virtual machines (VMs)
  • Key Vault
  • Storage Accounts
  • the Azure Portal
  • RBAC

Even worse, you immediately lost a significant amount of capacity because these services required more than 20 VMs to operate.

Additional PaaS Services

Additional features like App Services, Azure SQL Database, and Managed SQL were not available out of the box. If you needed to deploy App Services in a high-availability setup, you had to provision an additional 10+ VMs. The same complexity applied to setting up SQL features, these were custom deployments, not native capabilities. Scaling beyond 16 nodes or managing multiple locations introduced further complications. You ended up with multiple separate portals and all the associated VMs for each cluster.

We experienced these challenges firsthand, requiring a near-dedicated support channel with Microsoft. Just to get Azure Stack Hub operational and to keep it running reliably. While the concept, delivering cloud services to edge or distributed locations, was visionary and ahead of its time, the execution and timing weren’t up to the mark. The state of cloud computing at the time couldn’t fully support the idea.

The good news is that Microsoft learned valuable lessons from Azure Stack Hub. They never abandoned their belief in hybrid cloud and disconnected solutions. The ongoing evolution of these capabilities shows their commitment to refining and improving the hybrid and edge cloud experience.

Azure Local

With the announcement of Azure Local disconnected operations at Ignite 2024, you might be thinking, “Aren’t we back to 2017 again?”. It’s a valid question. The need for cloud computing in remote locations hasn’t disappeared, in fact, it has grown exponentially and will continue to do so. Especially with the rise of AI and Machine Learning. The concept remains as relevant as ever, but this time, a lot has been learned.

Today, we have the benefit of time and significant advancements in cloud technologies. The world is far more cloud-aware, and the platform now leverages the innovations in containerization that have emerged over the past few years.

Where Azure Stack Hub once required 20+ virtual machines to operate, Azure Local has streamlined this into a single virtual appliance. The appliance runs all the necessary containers to power the Azure Resource Manager and its dependencies. Key components such as the Azure Portal, APIs, RBAC, Azure Policy, and Key Vault are now hosted locally on the system, providing a more efficient and scalable solution.

Need more computing power, memory, or storage? No problem. You can easily add additional nodes or clusters while still using the same unified management experience and a single control plane.


Not because you want it… because you need it

Before jumping to conclusions like, “I want this so I can stay offline” or “It just feels better this way”, it’s important to weigh your options carefully. If connectivity is available, you’re likely better off with the connected Azure Local setup. Azure Local can support up to 30 days of running offline. Because when going fully disconnected, it comes with trade-offs.

In a Disconnected Azure Local environment, certain features are unavailable. Features like Azure IoT Operations, Defender for Cloud, Azure Monitor, and the AI and Machine Learning capabilities. Additionally, being offline means that updating applications or the environment itself becomes a more manual and labor-intensive process. From an identity perspective you can only rely on Active Directory.

The disconnected option serves a specific purpose for certain scenarios, it’s essential to choose the setup that best fits your needs.

Azure Stack Hub, you were a pioneer in the field, but there is a new sheriff in town!

Splitbrain is here to help

Navigating the complexities of all the products and features can be challenging. Do we go for Azure Local with a connected a or a disconnected solution? Or do we perhaps need a Windows Server solutions? No fear Splitbrain is here to help! With extensive experience in providing expert advice and executing numerous implementation projects, we are well-equipped to guide you through the decisions. Don’t hesitate to reach out to us through our contact page for personalized assistance.

Darryl van der Peijl

Splitbrain - Microsoft MVP - Azure Local, Hyper-V & Azure Arc

2 个月

??

回复

要查看或添加评论,请登录

Splitbrain的更多文章

社区洞察

其他会员也浏览了