In my monthly wrap-up, I will share what happened in the world of Azure IaaS over the last month. We’re closing in on the end of “Titanium” – the current October – March sprint in Microsoft’s DevOps calendar. And Microsoft Build is not too far away. Things have been relatively quiet since early November, but now things are starting to warm up again. I have suspected that product groups were holding back, but the trickle before the dam-burst has started. Here we go!
I’ve written a few posts here on Petri about using Azure Monitor to create alerts when virtual machines break some threshold. If you read the posts, at first you’ll have thought “that looks easy”. Then after creating a couple of CPU & RAM alerts for a few virtual machines, you will think “wow this is tedious” and “is there a better way to do this?”.
That’s because Azure Monitor’s alerts did not scale well beyond a fairly simple point solution. Each alert required:
So how would that scale out to say, 50, 100, or 1000+ machines? This sounds very like the enterprise monitoring solutions that 1990’s corporations used to buy and then leave gathering dust in a corner.
Two things have appeared in Azure Monitor over the last couple of weeks to indicate that Microsoft is listening to us and is thinking bigger. The first announcement, Monitor at scale in Azure Monitor with multi-resource metric alerts, told us that we could now create an alert and associate it with lots of resources at once – Woohoo! I think I actually made that noise when I read the article.
The second article, Announcing Azure Monitor AIOps Alerts with Dynamic Thresholds, tells us that a rule in Azure Monitor can, at an extra small cost, be configured to use Machine Learning (go ahead, take a shot) to figure out the correct threshold for the current point in time. For example, if things are normally quiet and CPU spikes to an unusual level, then you are alerted. But if things are normally busy, and CPU spikes, it will take an unusual burst to create an alert.
What we are getting is faster deployment of monitoring with less effort and, very important to avoid monitoring fatigue, fewer noisy alerts.
Another Azure service that I wrote a good bit about on Petri was App Service Environment (ASE, pronounced as “ace”). What was significant about ASE was that this took a platform service, an app service plan, and brought it into the world of infrastructure. By connecting an app service plan to a virtual network, one could increase privacy and compliance with industry and national regulations.
This integration into the virtual network is continuing. A preview is currently in operation to add ordinary App Services to a VNet. Other services are being added too. A preview for Azure Container Registry was announced in Azure Container Registry firewall rules and Virtual Network (in preview) and Logic Apps (business integration) are also entering the VNet, as was announced in Announcing Azure Integration Service Environment for Logic Apps.
Your ability to design, secure, manage and govern virtual network deployments is only becoming more important. Your ability to understand the fundamentals of network components, how they connect and work together is increasing in value. Networks will become more important, and scale out in new ways that we probably cannot imagine today.
Here are other Azure IaaS headlines from the past month:
Here are my Azure posts from the month of February:
I started a new job in January working with a Scandinavian IT services company. One of the big shocks to my system was being dropped into the “DevOps” methodology that is deep in the DNA of this company. Terms like “agile” and “scrum” are common. For someone who has made fun of DevOps as being “releasing bad software more frequently” I can see that I didn’t understand DevOps. One can blame bad releases on the bad implementation of the methodology.
I’m involved in two projects today where we are using Azure DevOps. In one, I am a product owner, responsible for building a backlog, much like what I guess a Microsoft program manager does. That backlog is a list of things I would like to see in a product. I describe those features and then the architect & development team create tasks and pull them into the current sprint.
In another project, I am working with a colleague to create a common solution for our different customers. A lot of writing (markdown) is being done and ARM templates are being written and improved. All that work is being done in Visual Studio Code, with Git integrations into Azure DevOps.
Pushes, pulls, sprints, features, backlogs, tasks have all become regular phrases for me to use. It’s very different but it works.
In a traditional waterfall project, you need to know the endpoint to plan the journey. But the reality in IT, and in most business, is that we don’t know the endpoint until we get either nearly there or actually arrive there. The agile methodology is based on sprints. We create a backlog of known things we want to do, break them down into tasks, and then schedule those tasks to be done in a short time frame called a sprint. Open communications in a flat organization increase cooperation. An “I’ll do that task” approach increases personal opportunities. A sprint gives you a short time to plan for, plus a short amount of risk/rollback in case you went the wrong direction.
As I said, landing in DevOps was a shock to me. But it works. I am working with people hundreds of miles away from me and doing so in a structured manner. Agile development isn’t just a programming thing. I can see how I could use it for writing. And only last week I read an article on a business news site about how agile was growing beyond the boundary of IT into getting things done in business. It makes sense: agile is all about tasks, not just programming. If you have the time, do some reading, and if you have the licenses, try out Azure DevOps and see what it might do for you beyond the realm of scripting or programming.