What’s Cool in Azure — October 2020

Several New Regions

Microsoft keeps announcing new regions so fast that it’s hard to keep track of the current total number. By my estimates, at the end of October, we got up to sixty-five regions existing or announced globally. That is, also by estimate, twice the number offered by each of the two closest competitors. That is, of course, a result of different strategies regarding datacentre planning — while other providers are opting for a smaller number of larger regions, Azure focuses on offering smaller, more local regions. Especially here, in Europe.

Both approaches have their advantages and disadvantages, but the locality seems to be resonating exceptionally well with organisations operating in regulated industries and markets.

What is also important is that in the case of Azure, the investment by Microsoft is not limited to what we commonly refer to as concrete and iron. All cases of newly announced regions, that is:

• Austria
• Greece
• Taiwan

also include significant efforts into fueling local economies and training tens, if not hundreds of thousands of digital professionals over the coming four to five years.

Looking at the demand in the job market, I think that it’s a solid strategy. After all, we cannot drive cloud adoption without cloud specialists.

One thing that I am still missing is more investment by cloud providers in Africa. With just three regions in total, across the three hyperscalers, the world’s second-largest continent is, sadly, yet underrepresented in the portfolio of cloud regions.

See the offical annoucements here:

App Service Environment v3

In late September, during the annual Ignite conference, Microsoft announced an upcoming update to the App Service Environments, also known as ASEs.

Azure App Service, is an offering which I am incredibly fond of. It is both much simpler and much cheaper compared to using Virtual Machines, but it is still very potent. Like many PaaS services, it is, however, by default hosted in a multi-tenant environment, and that introduces certain limitations. ASE is a service which allows us to run Azure App Services in a dedicated, single-tenant configuration, and thus enables us to mitigate several of the limitations mentioned above.

Most notably:

• It opened up the possibility of using Azure App Service to organisations which, due to security or compliance requirements, cannot run applications in multi-tenant environments
• It provided the option to integrate App Service with a Virtual Network (today this functionality is also available via the Regional VNET-integration feature)
• It is the only way of providing zone redundancy for Azure App Services

Those excellent capabilities did, however, come at a price, both in the form of monetary value, and increased complexity. From the cost perspective, we need to pay a base stamp fee for every instance of ASE, and that is not cheap — just shy of a thousand EUR monthly in my default region of Azure West Europe. If we wanted a zone-redundant deployment, we needed at least two instances, and if our acceptance environment was to be a clone of production, we had to double the spend once more. Given that the base fee does not include any compute power — we still need an expensive App Service Plan per each instance of ASE, many customers found the price way too high.

Next to that, the tight VNET integration meant that all ASE management traffic had to flow through our network. As a result, we had to implement specific routing and configure Network Security Groups accordingly to allow the resource to communicate withe the Azure management plane.

The new version of App Service Environment, v3, according to the available sources, will bring several significant improvements as well as meaningful cost reduction.

We expect:

• That the base stamp fee will be removed, and we will only have to pay for the App Service Plans (new SKU — Isolated v2)
• Improved zone redundancy and load balancers
• Simplified network configuration — the management will traffic no longer flow through our VNET

The new offering is now in public preview, but as one might expect, there are several limitations. Unfortunately, at the time of writing, some of those limitations aren’t yet described in detail. For example, the documentation states that ASEv3 is available in select regions only, but does not list those regions. During my tests, I was unable to deploy in West Europe but did succeed in creating the resource in East US. Still, I had to wait for one hour and forty five minutes for the deployment to complete.

Price-wise, we the new App Service Plans start from around 350 EUR monthly for 2 CPU cores and 8 GB of memory. There are a total of three sizes, with resources and costs doubling with each increment. Comparing plans with similar computing power, that is I2v2 and I1v3, we get more than nine hundred EUR monthly cost reduction. That is huge!

Unfortunately, I was unable to test or find complete documentation related to zone redundancy. The only mention of availability zones is in regards to dedicated hosts — when using the “Dedicated Hosts” feature, and if our target region supports availability zones, the ASE will be deployed across two zones. That configuration will, however, come at an increased price. My understanding is that we will have to pay a premium for the dedicated host and double the cost of our App Service Plan.

Overall I am extremely excited to see this improvement, and I am sure that many of our customers will be very happy to start using the new version of App Service Environments.

For more information, including links to documentation, please see the official announcement:

Cost Management Path on Microsoft Lean

Cost Management is a topic which engineers often find not all that exciting, to put things mildly. Yet, it is something of great importance for any cloud adoption journey. The pay-per-use billing model makes it extremely important to stay in control of ones spend. Despite that, I see that many users find themselves a bit lost when it comes to controlling their Azure consumption.

Thankfully, Microsoft just released a new Learning Path which covers just that topic. It won’t teach you the entirety of the art of cost management, but it will give you an excellent overview of the available options and services. That foundation will then allow you to create a custom set of solutions which best fit the needs of your organsiation.

As in most cases, the path is split into several modules, so you can pick and choose the content which you’re interested in.

You can find the learning path here:

Updates to Azure Key Vault

October has also brought us two fascinating updates to one of our favourite Azure services — the Key Vault.

In case you haven’t had the chance to use it yet, the Key Vault is a secure store for your passwords, keys, certificates, and any other secrets. Once your secrets are in there, you can grant different resources and users specific levels of access and perform different kinds of management tasks.

Traditionally, access to the data-plane, that is the secrets, was entirely separate from Azure RBAC, which we use to grant individual identities management-plane access. As a result, to allow someone, or something, to read a secret, we needed to go through a process which many users found unintuitive. I’ve even seen experienced colleagues forget the distinction between RBAC and Access Policies in the heat of the moment.

Those Access Policies also have a rather significant downside — we can only grant specific identities access to the entire Key Vault, there are no item-level permissions.

Recently, however, Microsoft released a great new feature for public preview. We can now configure a Key Vault to use RBAC for data plane authorisation. Not only can we then use the same interface as for management plane authorisation, but we can also set item-level permissions. This improvement will significantly help improve security and allow many teams to simplify their architectures. Anyone who had to deploy several Key Vaults to create separate permission boundaries will be happy to be able to replace them with a single vault.

You can learn more by checking out the official documentation:

Another significant improvement, which is now generally available, is Event Grid integration. Event grid is a PaaS service which routes event information from sources to handlers, allowing the handlers to act upon those events.

My colleague Nemanja recently wrote an article in which he describes how he, and his team, use this feature to monitor Key Vaults for expiring secrets. The post describes all components and mechanisms in detail, so I will refrain myself from repeating what Nemanja already wrote, and will only leave a link below:

Democratisation of Zone Redundancy in Azure SQL

Azure SQL is another service which I am a massive fan of. The memories of planning, licensing and executing MS SQL Server installations are still very much alive, and only make me appreciate the PaaS offering even more. Deploying, configuring and managing a relational database has never been easier, and even though Azure SQL doesn’t offer the identical feature set as Microsoft SQL Server, they are highly compatible. The chances that you’ll be able to move to the cloud-native offering with zero to small code changes are pretty big.

The service has been available for a while, and over the years it has accumulated quite a bit of complexity when it comes to choosing the right SKU. With the single database vs elastic pool discussion on the one hand and the virtual core vs Database Transaction Unit (DTU) discussion on the other, we still have to choose a reliability model.

Even though Azure SQL Databases are always highly available, the underlying architecture is significantly different between the Standard availability model and the Premium availability model. If you’d like to dive deeper into the topic, the documentation which I link below does a pretty good job of explaining those intricacies:

One of the differences which make customers opt-in for the more expensive Premium model was zone redundancy. The Standard availability model did not allow us to deploy a database across multiple availability zones.

The situation, however, seems to be changing and heading in the right direction. As of October, we can enable zone redundancy for the General Purpose tier of Azure SQL. General Purpose is the younger sibling of the Standard tier, with the difference that the former is used when purchasing virtual core capacity, and the latter is used when purchasing DTU capacity.

The capability is still in public preview and is limited to the General Purpose tier, but it is a sign of the democratisation of zone redundancy. And that is something that I am delighted to see.

To learn more, please see the official announcement:

Azure DevOps Default Branch Name Changes

The year 2020 has been challenging for everyone around the globe. But alongside all the turmoil, certain things have started changing for the better. One such example is an increased language awareness within the IT industry and the move to shift the naming of the default branch in git repositories from “master” to “main”.

GitHub, the place where world’s developers come to collaborate on source code, has been leading the charge, and now Azure Repos is joining the movement.

Recently there have been two significant changes:

• We can now control the name of the default branch used in our repositories.
• And if we don’t specify a custom value, the default branch in a new repo will be called “main”.

It is crucial to keep in mind that if you do not override the new default name, every new repository will start with a “main” branch, even if working with an existing project.

As much as I understand that it might be disruptive for some teams, I’m happy to see this change. The language we use has tremendous power when it comes to shaping the world around us, so let’s be mindful of the words we use!