Azure Monitor
Microsoft killed SCOM internally
Microsoft no longer uses SCOM to monitor their own workloads. They have replaced their entire SCOM based monitoring stack with Azure Monitor. Allegedly reduced alert noise and administration overhead.
Even if I have moved from SCOM as my main responsibility, I am still very much involved in the whole monitoring and management scope. Over the last years we have heard alot of talk about Azure Monitor replacing SCOM, but that cooled off after a while, maybe until now?
Technology change or cultural change
Microsoft’s story on how they killed SCOM internally was released one day before the official announcement on Operations Manager 2019. But we first heard the story at Ignite in 2018. One may ask, why the re-initiate this topic now?
For SCOM 2019, the focus is to better support hybrid cloud environments, which is good. If Microsoft doesen’t want to use it, should you?
I have written and spoken about the use of SCOM as your hub for Azure Monitor, and my opinion hasn’t changed that much. I belive that transition to you a new monitoring stack will happen with changes to the infrastructure.
When you read the article you’ll see that this was the case for Microsoft as well. There are two quotes i find partculary interesting in the announcement.
“This is not just a technology change, but a culture change,” Baxter says. “It wasn’t only that we would remove SCOM central monitoring, but we had to tell our application teams, now you’re going to manage alerts..”
It was January of 2017 when Baxter got the call. “Our goal was not just to get rid of SCOM, but to move to a Software as a Service (SaaS) solution and retire Virtual Machine (VM) based infrastructure,” she says.
The key here is change in culture. Microsoft went full on DevOps for their internal IT, and by doing that technology will change, and your monitoring will follow.
Further, the showcase mention monitoring was desentralized, which is true. But ther’s another key part of this story. The monitoring team built an integration service between their monitoring stack (Azure Monitor, app insights) and their ITSM system. This system allows for more meta data on each alert etc before ending up as a ticket.
Final notes
If you’re organization runs most of your IaaS on premises, you don’t have to make change yet. Allow the culture to drive the change. A long the way, your SCOM environment can be that integration service between Azure PaaS, FaaS, XaaS and ITSM.
5 COMMENTS
Your article helped me a lot, is there any more related content? Thanks!
[…] Another thing to keep in mind is that platform knowledge is very important for everyone managing the workloads running in Azure and other cloud platforms.Let’s take a look at monitoring. In order to have a good monitoring platform, you require a few basics like alerting. Alerting is built into every monitoring platform out there, and is the foundation of monitoring. But alerts need to be handled. Hopefully, you have killed email alerts already, and you have other routines in place, like an ITSM platform or maybe your alert remediation is a PowerShell script.To have an alert automatically remediated in Azure Monitor, you will need to learn a new product like Azure Functions to run your PowerShell script.PS: Microsoft replaced SCOM for Azure monitor, driven by cultural changes and DevOps […]
[…] infrastructure. Now, more and more companies are shifting to the “DevOps” world. Even Microsoft have killed SCOM and are only using Azure Monitor. Meaning that the one deployed the code (and the infrastructure) should be responsible for […]
Hey Martin,
Nice article. I agree that if you are running a lot of IAAS either on-premise or in the cloud, that it is mostly business as usual with SCOM. Once you are introducing a lot of PAAS / SAAS services the story does change.
But even then I wonder if its smart to use Azure monitor for your Azure workloads. I introduces a chicken and egg problem. I always recommend customers that to completely isolate their monitoring infrastructure from their datacenters, if the budget allows it. Otherwise during a major platform or datacenter issue, you are mostly blind due to the fact that your monitoring platform is running on that very same platform.
Also, and maybe its on the road map, I would like Azure monitor to introduce ‘management packs’ for each service they offer. Now you have to reinvent the wheel for each PAAS service. What do I need to monitor? Which metrics are important? Very little information is available for each metric and not all of them are self explanatory.
Br,
Jasper
Hey Jasper, thanks for your comment, and sorry for my late response. To be honest, SCOM isnt the tool if youre going to invest in something now. I was just trying to make a point where the story isnt about SCOM and more a cultural and technology change. I also do not believe that SCOM is dead within MSFT. This one team kille SCOM and where successful, but I assume other teams are still using it.
As you point out there are limitations in Azure Monitor. One being a discovery type or a set of rules you should/can enable for the particular workload type. Like a MP. I would also like to se a way for me to define as set of rules for my workloads. IE; All VMs should alert on 95% CPU and similar. To do that now, you will have to create alerts based on queries in Log Analytics – which works well, but you lose some context.
Running AM in another region sounds a bit drastic, but I get your point. You put SCOM and other monitoring tools on a separate host on premises, and would do the same in Azure.