What’s Cool in Azure- May 2020
May was a remarkably exciting month for Azure, primarily due to the Build 2020 conference, which Microsoft held as an all-digital event through May 19th to May 21st. The conference was free for anyone who wanted to participate and ran 24/7 throughout the three days with various sessions broadcasted at three different timeslots, each. This way, people from around the world were able to tune in at a time which was most convenient for them and still get the best possible experience.
Despite Build being a developer-focused event, around seventy per cent of all its sessions were related to Azure, so there was also plenty of content that those who don’t write code for a living found exciting.
LearnTV
If you’ve only now realised that the Build conference already took place, or couldn’t join at the time, worry not. During the event, Microsoft unveiled the Learn TV, as part of the Microsoft Learn portal.
The new site is intended to be a single aggregation point for various sources of technical content, including Channel 9 and first-party events. It is also said to host daily live programming containing developer discussions and content from the advocate teams and products groups.
The project is still bearing the “preview” tag, but more content is added regularly. For now, it is the perfect place to catch up on the sessions from Build, but I do expect it to become a site which I will frequently visit to find even more great content.
The best way to judge whether it’s worth putting a bookmark in your browser is to see for yourself though:
New Routing options for Public IPs
It is a widespread practice among cloud providers to charge customers based on network bandwidth usage. In Azure, all ingress traffic, that is data coming towards the cloud data centre is free of charge, but all egress traffic will contribute to the monthly invoice. Unfortunately, those costs tend to be hard to predict, and as some cloud economists like to point out, can not only become a significant a burden for the customer but also cause a data lock-in with a specific vendor.
Now, however, in Azure, we can take advantage of a cheaper option for our egress traffic, although the savings do come at a cost. Traditionally, Microsoft uses what they call “hot-potato routing”, which means that user requests will be injected into the global backbone network of the cloud provider as early as possible. As a result, the traffic towards the Azure data centre will flow over the low-latency, high-throughput connection as much as possible. Naturally, all responses back to the user will follow the same, performance optimised, route.
With the new option, customers can choose to configure their public IP addresses for “cold-potato routing”, meaning that user requests will travel as much as possible over the ISP infrastructure to enter the Microsoft backbone network as late as possible. As a result, the connection can experience higher latencies and less stability.
The new option will be a compelling choice for workloads which tolerate network performance issues but requite cost-optimisation due to substantial amounts of data traffic.
The new feature is now in public preview, so it comes with a list of limitations. Most notably, to try it out, we need to register the resource provider feature and create the public IP resource either via PowerShell or Azure CLI. You won’t be able to do it via the portal, even using the preview version.
To learn more about the new option, check additional limitations and find configuration instructions, please refer to the official documentation:
Static Web Apps
Single-page web applications, also known as SPAs, have grown increasingly popular over the last few years. One of the commonly mentioned reasons is that the user experience resembles that of mobile applications, which we, as customers, have grown fond of.
Such a web application consists of static assets like HTML, CSS, JavaScript and media file as well as backed APIs which are responsible for delivering any dynamically changing data. The web server does not dynamically generate the web pages. It only serves static content. All computation is done by the user’s web browser within the context of the local machine.
Customers have been long able to host SPAs in Azure and with the recent addition of using a Storage Account to serve the static content, using the Microsoft cloud became an even more compelling choice. Teams still had to, however, perform quite a bit of additional work to set everything up, if they wanted to achieve a high performing, secure and resilient application. The backend APIs had to be hosted in Azure functions, while the frontend assets needed Content Delivery Network (CDN) and load balancing capabilities provided separately.
Azure Static Web Apps is a new offering which aims to streamline and simplify that process. It will be especially interesting for smaller teams which will be happy to sacrifice a degree of flexibility and control, to gain speed and reduce operational overhead.
It allows users to publish the entire web application, including the static assets, all required APIs, custom domain support, CI/CD integration and staging with a single, straightforward process. All we need to do is point the service at the git repository which hosts our source code, provide a few parameters and we’re ready. Our content will be globally distributed for optimal performance, if we use a custom domain, we will automatically get an SSL certificate, and on top of that, we will be able to configure authentication and authorisation. It’s hard not to get excited.
The service is currently in public preview, which means that we can only use GitHub repositories and GitHub Actions as the source code and CI/CD providers. Also, the list of supported frameworks is limited. The team behind the product is, however, very open to feedback, and in their presentation during the Build conference, they reassured us that they would develop the service in a way which makes their customers most productive. They want to learn about your expectations, so I would believe that Static Web Apps will visibly evolve before reaching general availability. On a positive note, during the preview, the service is free of charge.
If you’d like to learn more, I recommend investing time into the Azure Power Lunch episode devoted to the topic:
And if you want all the details, the official documentation will be your friend:
An SLA for Azure Kubernetes Service
Azure Kubernetes Services (AKS) is a very compelling way of running Kubernetes clusters in Azure. It is a managed platform which provides the control plane free of charge and takes away a lot of the overhead related to setting up a cluster from the ground up.
Some customers, however, haven’t been able to take advantage of the benefits that AKS offers. A common reason for such a situation was the lack of an SLA guarantee, which is often required by an organisations security or procurement policy. Worker nodes are covered by the Azure Virtual Machines SLA, but AKS, as a free service did not have any financially backed uptime guarantees. Microsoft sill operated it with the same level of excellence as for any other services, but they only provided a 99,5% Service Level Objective (SLO).
Thankfully, that limitation is no longer an obstacle. Customers can now purchase an SLA add-on for their AKS clusters, which will provide a financial uptime guarantee.
Depending on whether you choose the zone-redundant, on non-zone redundant option, you will get 99,95% and 99,9% SLA respectively for the Kubernetes API server. In both cases you’re looking at the cost of 0,1 USD/h, what would amount up to around 75 USD monthly per cluster. The add-on is now generally available.
To find out more, please refer to the documentation:
Create custom RBAC roles in the Azure portal
Using custom roles for Role-based Access Control in Azure is against the best practices published by Microsoft. By doing it, you take on the burden of performing regular reviews and adjustments to make sure that your custom definition doesn’t grant excessive permissions. The Azure ecosystem is very dynamic, so with periodic additions and changes, it is easy to expose more that we’d like to.
Still, sometimes there is no other way. In some cases, the built-in permission sets do not cater to a specific requirement that one might have, and creating a custom RBAC role is the only choice.
Before the recent developments, to do this, one had to use a command-line tool such as PowerShell or Az CLI. As they say, I’ve been there, done that got the t-shirt. It wasn’t extremely challenging, but it also wasn’t the most pleasurable task. Thankfully, now we get to use a graphical interface in the Azure Portal to create custom permission set definitions.
We can start from scratch, use an existing role as a starting point, or import contents of a JSON file. Then, once we’ve finished editing the custom permission set, we can deploy it via the portal or download a JSON file. I would recommend choosing the latter option and storing the custom RBAC role in source control. You can then deploy any changes with a CI/CD pipeline. After all, transparency and traceability are crucial for security.
Being able to build a definition in the portal makes the process of generating the code comfortable and much more productive. For me, it’s a very welcome addition to the toolbox.
To learn more, please refer to the official documentation:
