As you may have seen on LinkedIn, throughout the months of January and February, myself and fellow blogger Jakub Fras will be posting every Friday on topics related to Microsoft Azure. I’ll be posting on my blog here, and Jakub on his awesome blog here. This post will be a tale of two halves, with part of this post being Azure Local, and part being based on a discussion I had around networking considerations for Azure Local recently – and the changes this brings, and enables for us.
This week, it’s my turn to talk about all things Azure Local. Azure Local was announced at Microsoft Ignite back in November, and brings a wealth of updates and new features to Azure Stack HCI, along with a new name!
For this Azure Skill Sprint Post, I wanted to provide a host of links, information, and wider reading that would act as a reference for those learning and working with Azure Local. Along with various helpful bits of information to get started. And finally, a small piece on some work I have been doing recently considering networking when using Azure Local and Azure Hybrid Services.
Where to get started Learning About Azure Local
This section is more a collection of links and resources than anything else – but I’ve tried to include lots of reference that will be a help to anyone wanting to learn more or get started with Azure Local:
Recommended Learning Modules in Microsoft Learn:
- Azure Arc – Microsoft Learn – https://learn.microsoft.com/en-us/training/modules/intro-to-azure-arc/
- Azure Local Storage – Microsoft Learn – https://learn.microsoft.com/en-us/training/modules/manage-azure-stack-hci-storage/
Wider Technical Reading / Overviews / Install Guides etc:
- Ignite Blog – Announcing Azure Local (Note: the Slide Deck at the bottom of this article is also awesome and well worth checking out): https://techcommunity.microsoft.com/blog/azurearcblog/introducing-azure-local-cloud-infrastructure-for-distributed-locations-enabled-b/4296017
- Azure Local Overview: https://azure.microsoft.com/en-gb/products/local
- Installation Guide: https://learn.microsoft.com/en-us/azure/azure-local/deploy/deployment-install-os
- Azure Local Solutions – Details all about Azure Local and provides details on validated node solutions sold by partners – https://azurelocalsolutions.azure.microsoft.com/
- Azure Local Solutions – sizing tool – this allows you to create a sized Azure Local deployment based on a range of criteria, which will then recommend a solution based on your chosen hardware provider. https://azurelocalsolutions.azure.microsoft.com/#/sizer
- Azure Local Network Requirements – https://learn.microsoft.com/en-us/azure/azure-local/concepts/physical-network-requirements
- Jumpstart HCI Box – a great virtual option to run Azure Local on Azure in a nested scenario for learning, labs, testing etc: https://azurearcjumpstart.com/azure_jumpstart_hcibox
- Azure Virtual Desktop on Azure Local: https://learn.microsoft.com/en-gb/azure/virtual-desktop/azure-local-overview
Important – Consider the Azure Local Baseline!
The Azure Local Baseline is a reference architecture that provides a baseline with which to build on for your Azure Local deployment. You can access this baseline here: https://learn.microsoft.com/en-us/azure/architecture/hybrid/azure-local-baseline. Within this reference architecture is a huge range of information and considerations when designing an Azure Local deployment – including aspects like the Well Architected Framework:
Networking Considerations for Azure Local… and Networking in an Azure Hybrid World
I’ve recently been spending some time working with Azure Arc and Azure Local – and seeing specifically how these technologies are changing our approaches and technology decisions with regards to networking. Previously I’ve seen how there has been a focus on creating extensive secure networks, linking sites and locations together. However, with Azure Arc and Azure Local, operations that run in an isolated, connected, and a disconnected way (and more often than not, a mixture of these) are being realised in a hybrid approach. In reality this means having sites that may simply operate in a satellite fashion, with control via Azure Arc, or sites that have full connectivity back to corporate locations, networks, and services for example. Instead of seeing all sites in an organisation linked, we’re starting to see more flexibility with this hybrid approach.
In this post I wanted to explore a few considerations based on my experience. These are more food for thought, rather than an extensive technical overview – but where appropriate I’ve included links, resources, and wider reading!
Consideration 1 – Not everyone and not everywhere needs a VPN/Connectivity to a Corporate Network!
With Azure Arc and Azure Local, services and operations don’t always require a private connection back to a corporate network – remote management via Arc over the internet is an option, for example. It’s worth noting that this aspect will vary hugely between organisations, different compliance/legal/data standards, requirements, and more. But in principle – services running on Azure Local or being managed via Azure Arc, do not always require connectivity back to corporate networks. It’s also worth noting – if you need to run Azure Arc over private networking, you can, see here: https://learn.microsoft.com/en-us/azure/azure-arc/servers/private-link-security.
Consider a remote location that runs only local services – this could easily be a use case for Azure Arc and/or Azure Local. In this case, Azure Arc and Local could be utilised, and other Azure services, like Azure Backup used to protect the workloads (Back up Azure Local virtual machines with MABS – Azure Backup | Microsoft Learn). With this example, a private network wouldn’t be required – just an internet connection that allows communication back to an Azure Region, where additional Azure services can be hosted to support the Arc/Local deployment.
Consideration 2 – Remote and Edge Locations and Sites benefit hugely from the flexibility of Azure Arc and Azure Local
Remote and Edge locations can sometimes prove challenging from a network perspective too. Edge locations can present challenges like shared buildings and offices, or different connectivity options for different locations (so standardising can be a challenge). It’s worth noting that despite this, there are a huge range of connectivity providers, options, and solutions out there to help. Remote sites, e.g. those that are geographically difficult, can also present a unique challenge. How do we ensure adequate control, management, and operations, in places where connectivity options to run those servers remotely are limited?
Azure Local and Arc help massively here – giving us the ability to deploy services in these types of locations, and thus keeping application traffic or data locally, whilst using Azure management plane to control and govern these. Consider a scenario whereby we need a local application to run (for example to control a manufacturing device or piece of equipment), on a site where we can only get a limited connection. Adopting Cloud-based technologies would typically be a challenge here – and we’d then potentially have the split of some services running in Azure, managed using Cloud native technologies, and others utilising different systems for operation and management. This split of systems and technologies leads to operational and organisational challenges, with more complexity and staffing, for example.
Utilising Azure Local to run these types of services, and Azure Arc to manage and govern, leads to a more harmonised approach – allowing Azure skills, technologies, and existing configurations, to be extended to these locations with ease.
For more information on the network requirements for Azure Arc management – see here: https://learn.microsoft.com/en-us/azure/azure-arc/network-requirements-consolidated?tabs=azure-cloud.
Azure Local SDN Multisite may also be of interest here: https://learn.microsoft.com/en-us/azure/azure-local/manage/manage-sdn-multisite
Consideration 3 – Disconnected Operations with Azure Local
Building on the challenges that remote sites face, Azure Local also helps with disconnected operations (currently in Preview – Disconnected operations for Azure Local overview (preview) – Azure Local | Microsoft Learn). Disconnected operations helps to solve challenges around connectivity, but also provides opportunities for organisations that have data sovereignty and compliance requirements, as well as those with strict security needs too. It is worth noting that Azure Local has a list of supported services for disconnected operations – you can view that here: Disconnected operations for Azure Local overview (preview) – Azure Local | Microsoft Learn
Consideration 4 – Using Azure Local to solve the latency challenge
Azure Local can also be a huge help when solving latency challenges. Consider the two scenarios below – based on a site that has a networking challenge, whereby there is high latency or unreliable connectivity. In this case, a traditional approach of Azure Cloud based workloads might prove problematic – however with Azure Local we can site the services close to the end users, and utilise Arc for management and control. Whilst it’s worth considering if the connectivity is awful this may have an impact on the ability of Arc to manage these services – management traffic is far less latency sensitive than application traffic, particularly when that application traffic needs to be close to end users, and accessed on high bandwidth, low latency networking.
In the above scenario, Azure Local can really help – providing local services, and utilising Azure Management to control these. Management traffic is far less affected by latency than access required by end users working with complex, or latency sensitive applications. Consider a revised approach, using Azure Local:
Whilst this is a simplistic example, it helps to highlight the benefits Azure Local can bring in terms of latency sensitive applications, and locations that are challenging to get Azure Cloud based services hosted in Azure Regions into.
A note – as always, with any challenging locations, do check your connectivity at lease meets the baseline requirements for Arc and any other management services etc.
Consideration 5 – With changing networks and operating methods, comes a need for security change.
When we change how we operate from a networking aspect, perhaps moving services from an existing Data Centre, to running on Azure Local in a different site as an example, we need to consider how security will change. Thankfully Azure, via it’s various Management Tools and Options, has a wealth of aspects to consider here. I will run through and share a few considerations here as food for thought – including links to help where appropriate.
- Azure Local Baseline – Security. The Azure Local baseline provides an overview of security considerations that should be taken into account when deploying Azure Local. Thankfully the baseline has a great resource to help here: https://learn.microsoft.com/en-us/azure/architecture/hybrid/azure-local-baseline?#security
- Design Review Checklist for Security – this is from the Well Architected Framework, and should be considered for any deployment: https://learn.microsoft.com/en-us/azure/well-architected/security/checklist.
- Security Defaults for Azure Local – this provides an overview of how to enable the security defaults for Azure Local: https://learn.microsoft.com/en-us/azure/azure-local/manage/manage-secure-baseline.
- Azure Local Application Control – Management Application Control across your Azure Local Deployment, to control the applications that can run on your deployment – https://learn.microsoft.com/en-us/azure/azure-local/manage/manage-wdac.
- Azure Local – Syslog Forwarding – allowing important logs to be forwarded to a SIEM System, so monitoring, detection, and response can take place – https://learn.microsoft.com/en-us/azure/azure-local/manage/manage-syslog-forwarding.
- Azure Policy built-in definitions for Azure Arc-enabled servers. These can be a huge help (note: a number of these are still in preview), to ensure security and compliance across Arc-enabled VMs, for example, enabling monitoring agents or security agents using the DeployIfNotExists Policy Effect. You can read more about this here: https://learn.microsoft.com/en-us/azure/azure-arc/servers/policy-reference.
Whilst this is just a small part of the various security offerings available, it does help to highlight the range of options and changed approaches available with Azure Local and Azure Arc.
Closing Thought…
I hope this post has been helpful – in the coming weeks and months I will be doing more with Azure Local, and Azure Arc, so please do look out for more posts! Oh and please do look out for more Azure Skill Sprint posts from both Jakub and I!