Everything You Need to Know About Azure Infrastructure – October 2020 Edition

October, the first month in Q4 of the calendar year and Q2 of the Microsoft financial year, is also in the middle of planning for the next semester of development of Microsoft Azure (codenamed Cobalt). October is also the “hangover” for this year’s Microsoft Ignite so a lot of things that were announced actually appear in this time frame. October was also a month of new region announcements and Microsoft’s JEDI win continues to pay off for everyone.

New Local Azure Regions

Microsoft announced three new regions in October:

If you get your Azure news from the general tech media then you’ll probably have misunderstood lots of things about these announcements.
The first misunderstanding is that the announcements were for data center regions, not for an Azure data center; that sentence has many meanings:

  • Microsoft data center regions host lots of services, including Microsoft Azure. Some services, such as Microsoft Office, only run some of their components on Microsoft Azure. A Microsoft data center region can host Microsoft Azure, Microsoft 365, Dynamics 365, and other things, such as internal IT services for Microsoft that are not on Azure/M365, and Xbox services.
  • A data center region is a collection of more than one data center. Some data centers are on opposite sides of a city. And sometimes, the region is deployed or later developed with availability zones to allow services to be deployed across different physical buildings and dependencies for a higher level of availability.
  • When a country has two regions announced, it is not unusual that one region is the “failover region” which is not for production.
  • The city location shared for a region is not always … hmm … accurate. Google Maps is quite an interesting resource for this. A great example of this is the West Europe region, also known as “Amsterdam”. The West Europe region is a collection of data centers in Middenmeer, approximately 60 KM north of Amsterdam.

The second, and biggest, misunderstanding is that these new regions will be somehow the same as other regions in terms of Azure services delivery. Local regions are not smaller versions of the “hero regions” – a term that Microsoft uses to describe regions such as Southeast Asia, West Europe, or East US. The hero regions are where you will find all (or just about all) services being available or in a preview state. Local regions offer a subset of these services – an be aware that the official public documentation does not share a full breakdown. Many essential sub-services or micro-features are not listed at all.
Before a new local region is announced, the local Microsoft subsidiary must commit to selling a minimum level of capacity. Typically, there are one or a few large customers that will be signed up to partially fund the initial build. Then a “datacenter account manager” has the responsibility to sell the remaining consumption target. And that account manager will sell hard, seeing other Microsoft Azure regions as competition, almost like AWS or GCP.
We know that from some of the older local regions, such as UK South, that consumers of those regions are always looking for features that are in the hero regions.
You might see the glossy headline. Growth is good but be aware that all is not what it seems at first.

The JEDI Payoff Continues

I have no hard evidence of what I am writing here. But let us agree that 1+1 usually =2.
JEDI is the name of a project (that Microsoft won via tender and appeal) to supply a huge private cloud to the US military. As you can expect in such a delivery, security and cost were two huge components.
Microsoft has made a huge investment and pushes on virtual network security in the last 12-24 months. Azure Firewall, Azure Firewall Manager and Secure Virtual Hub (scaled-out SD-WAN connections, including pop-up locations) have been developed and/or matured. Private Link/Endpoint is rolling out to all platform and management services – which is a huge improvement over the 10-or-so services that supported Service Endpoint. This month we saw App Services go GA with support for Private Endpoints and Azure Disk import/export (useful for backup/DR/replication products such as Veeam) went GA with Private Endpoint too.
In addition, cost management and reductions have continued to roll out. Thanks to the appeal by AWS against the award of the JEDI contract to Microsoft, we know that the cost of storage was a huge factor. Microsoft has invested in and matured cost management for storage:

  • Blob storage has improved tiering over the last few years.
  • In recent months, virtual machine disk storage has improved cost efficiencies by allowing performance burst from previously limited lower SKUs to levels of higher SKUs without costly resizing.
  • The premium tier of file storage (a requirement for Citrix/Windows Virtual Desktop at scale) has reduced costs.

You might have thought that the JEDI contract had no impact on you, but as you can see, this sort of “moon shot” project can pay for investments that benefit everyone else.

Other Announcements from Microsoft

Here are other Azure IaaS headlines from the past month:

Azure Regions

Azure Storage


Azure Virtual Machines

Backup And Site Recovery

App Services




And Now for Something Different

Why would you cut through a jungle when you can drive on a well-travelled road? That’s a question that I have asked repeatedly over the years and recently came to mind. Why do so many people in IT want to invent new ways of doing things instead of doing what is the norm? Why do their customers, employers or shareholders have to get covered in cuts and thorns thanks to the IT adventuring?
I’ve seen all sorts of junk over the years. 10 years ago, I was quite involved in the Hyper-V world and was often asked for opinions, either online or via customer site visits. You name it, I saw it or was told about it:

  • A cluster where every node had just a single configured 1 GbE NIC and there was a question why the cluster and Live Migration did not function.
  • Hyper-V hosts where Hyper-V snapshots (now called checkpoints) were used as a form of backup and the customer wondered why all their virtual machines froze.
  • A site where gaggles of Hyper-V hosts each had 12 x 1 GbE NICs in a matrix of iSCSI connections to a form of HPE storage that was infamous for not scaling well – and the customer wondered why they had stability issues, blamed the software and moved to a different vendor.

Things are no different in The Cloud. Newbies might think “AWS, Microsoft, and those folks make magic happen and it’ll all work”. Nope; you still have to learn good practices and design. And in many cases, your on-premises network will play a big role:

  • Legacy systems will live on in cloud virtual machines because that’s all the software vendor supports.
  • 20-year old tech is still doing to be the heart of your enterprise. Example: Active Directory Domain Services.

Why do people try to invent a better wheel? I’ve wondered about this. I reached out on social media and the responses confirmed my suspicions:

  • Assumption is the mother of many problems in IT. People assume dumb things and don’t do the research. Bad decisions get made by bad IT people and are supported by worse IT managers. No matter what you tell these people, they will blame the software/cloud when it blows up in their employers/shareholders/customers faces.
  • Ego plays a huge role. Some people want to be a hero. They’ve tried something in a lab, and it worked. The theory sounds fine. Unfortunately, those people didn’t scale that lab out to include things that live outside of a lab. “It great in the lab” doesn’t cut it when you try to onboard production systems that expect to find 20-year-old services and designs, let alone the fact that Microsoft is expecting you to do the norm too!

There were some other comments from people, pointing to suspicions about padding out hours in consulting contracts, which would be pretty shameful.
If someone proposes a design to you and it sounds unusual, ask questions. Is that the norm? Is the design based on good practices? What happens when we try to put system X or do Y? Will it scale? What custom work will you have to do to make things happen that we normally take for granted?