When first interviewed at Xello, I was asked what I thought of the System Center suite.
Working primarily with Configuration Manager, I had just started managing my day-to-day with Service Manager & Orchestrator. I saw how versatile the platform was, and I loved it. I had also seen how much extra work can be involved when it was deployed and used wrong.
System Center is without a doubt an all powerful product, provided you spend the time to implement it and do it well. Your IT team need to understand the day-to-day operations and have the right people/vendors to pop the hood as required. You need to invest the time; like a lot of Microsoft products, you only get out what you put in.
As I spend more and more time working within Azure Cloud, I find myself less and less in love with System Center. I’ve found I can do nearly anything that System Center does, without the overhead, and easier. In this technical blog series, I’ll be covering how and why you should replace System Center with Azure native services, step-by-step.
Blog One? System Center Operations Manager.
What is System Center Operations Manager (SCOM)?
First cab off the rank for this series is System Center Operations Manager, because if we can’t tell whats going on in my environment, how can we manage it?
For the uninitiated, SCOM is a holistic monitoring solution for your on premise and cloud environment. Operations Manager has deep integration with Windows Services out of the box, and you can extend it using management packs (MP’s) to monitor just about anything. Last time I worked on SCOM, I was able to extend it for monitoring a mainframe from the early 1990’s.
While you can often get away with a single server deployment, SCOM is often deployed in a fully highly available manner. SCOM can also be deployed in a hierarchy like configuration manager, you can extend it into Azure and it works with multiple AD forests.
How do we know we’ve succeeded in replacing SCOM?
Before we get into the nitty-gritty, we need to define our success criteria. Personally, I love up-time and cost as a measures of success.. After all, if I can’t consume my service at any time for low cost, have I really done a good job?
I’ll apply the generic Azure Service Level Agreement (SLA) of 99.9% up-time as my key requirement – about 45 minutes of downtime a month.
In order to satisfy this requirement, I estimate I will need a distributed deployment with a minimum of two servers in my management pool. For demonstration purposes, we’ll assume I’m managing 500 servers in my environment. Using the Microsoft SCOM sizing planner and design advice, I think I’ll need three servers: Two Management servers and one database/reporting server.
My management servers will be A4v2 ($667.53 ) sized, with my SQL Database server being a D4v3 ($835.91).
Cost for compute? $1503.44 per month.
For storage, I’ll use the default recommendations for disk size and single disks where possible. 1000GB for my data, with a full year of retention. Three 250GB disks for my operating systems and installations.
My storage cost? $250.96 per month.
Total cost to beat?
$1754.39/month -> $21,052.68/per annum.
Azure Monitor: Cloud native monitoring that’s cheaper than SCOM
My replacement of choice for SCOM is Azure Monitoring, a cloud native, server-less monitoring solution. Xello has covered SCOM vs Azure Monitor’s key differences previously.
Azure Monitor is integrated into the Microsoft Azure public cloud platform by default and you’ve probably already used it if you’re an Azure administrator. You already see it under every virtual machines overview page, and as options under each services monitoring section.
Under the hood, Azure Monitoring solutions use analytics workspaces to store logs, Kusto Query Language (KQL) to search logs, and solutions to add in pre-built dashboards/queries.
Azure Monitor pricing can be a bit frustrating to predict in advance, but we are going to give it a crack using the calculator.
Our SCOM deployment was monitoring 500 servers, providing integrated alerting, emails, dashboards, reporting and log warehousing. Assuming we deliver the same, and ingest about 0.5GB of data per VM a month, we are going to start with a $1134.99/month cost. Storage is free for the first 31 days, and remaining 334 days sets us back approximately $96 dollars a month.
We definitely want to monitor the core metrics of our virtual machines – CPU, RAM & disk. These three alert rules is another $205.96 .
Now for my favourite part: The free stuff.
- Dashboards? Free.
- 1000 ITSM alerts? Free.
- 1000 emails? Free.
- Push Notifications? 1000 for free.
- Web hooks? 100 thousand for free.
Aside from some metric costs, alerting and monitoring is largely cost free and integrates to a large number of services out of the box with Azure Monitor. Always a bonus when you’re selling a solution to management!
$1436.48/month -> $17,237.40/per annum
In summary, Azure Monitor is definitely cheaper than SCOM in the long-run.
If you’re struggling to understand the differences, Microsoft has an excellent webinar on this process with the top recommendation being to swap out your alerting mindset.
So, what’s the deployment like?
Getting started with Azure Monitor deployment vs SCOM
Getting started with an Azure monitoring deployment is an extremely simple three step process.
It’s also a lot faster than deploying SCOM out of the box, which is a much more tedious process, to say the least.
1. Deploy an OMS Workspace
There aren’t too many options here to be confused about. Simply select a name, location and resource group and you’re on your way. Pricing tiers can no longer be selected; expect an update from Microsoft to remove the option.
2. On-board your servers
If you’re in Azure, the portal can do all the work for you.
If you are migrating from SCOM, the monitoring agent is the same and can be re configured using your Workspace ID and key.
3. Setup data retention policy
This is currently hidden under “Usage and Estimated Costs” & you can retain up to 730 days within a workspace.
Longer term retention is available, but you can’t query the data on demand.
SCOM vs Azure Monitor: A more cost-effective type of monitoring
Switching to Azure Monitor comes with a change in thinking and a management shift in our approach to monitoring.
Treat your monitoring like a SIEM and tune it to the ninth degree. If you have more than the free 1000 alerts a month, you have tuning to do. Getting your alert levels down ensures that your engineers will only react when it matters, and to the right content.
Work to understand your monitoring needs better. I’ve made heavy assumptions for our costings today, but there is a whole host of strategies when deploying long term alerting and monitoring. Answer some basic questions about your business.
- Are you regulated?
- Do you have a tiered model for internal systems?
- Do you require full administrative separation for your log data?
- Can you collect less data?
All of these questions help to reduce the cost and maintenance effort further, making your life easier.
Replacing SCOM with Azure Monitor: Next steps
I hope you enjoyed my comparison of SCOM vs Azure Monitor – and why it’s time to replace System Center Operations Manager with the latest Azure services for lower costs.
Stay tuned for my next blog post, where I’ll work through visualising and analyzing my collected logs in a meaningful manner!
Originally Posted on xello.com.au