I’ve written before about building your own monitoring systems versus buying a monitoring tool like Redgate SQL Monitor. There I talked about the time that someone tasked with managing and maintaining data gets back in their day when they purchase a monitoring solution. However, that’s not where the business focuses. The business frequently wants to know one thing and one thing only: what’s the return on this investment (ROI).
Let’s talk a little about the pluses and minuses of building a system versus purchasing one.
The Benefits of Build
There’s no denying that building your own monitoring system has a number of benefits. I would argue the biggest one is that you are building your own, custom, unique, monitoring process, specific to you, your systems, your business and all the technologies supporting them. This one benefit largely outweighs all the others and honestly can’t be deemphasized. You’re building the monitoring system, so you can be darned sure it does what you want.
Another benefit is that you only have to build as much as you need. Let’s say you’re not using Availability Groups. Well, then you don’t need to build any kind of AG metrics into your system. This is very much in keeping with best practices around DevOps, build what you need and then incrementally improve as you go.
One more benefit is the actual cost. Purchasing software is money spent. Whereas using your in-house people to do the work, well, you’ve already paid their salary, so there’s no added cost to putting them to work building out this monitoring tool.
Finally, another benefit to building your own monitoring tool is you’re actually training up your current staff. They are going to have to know more in order to build this new functionality. They can develop knowledge of SQL Server that can pay benefits longer term.
That’s not to say that building your own system doesn’t come with costs and challenges.
The Costs of Build
While there is no, completely direct, cost to building a monitoring tool within your organization, there are a number of, I don’t want to say hidden, let’s say, masked costs. These are costs that are not a straight up dollar amount, but directly impact your organization and its ability to delivery on your business. Although, depending on how you do internal billing, there could actually be a direct, monetary cost to this work. However, I can’t easily estimate what that will be, and it will obviously vary wildly between organizations, so we’ll focus on some other, more generalized, costs and challenges.
The first cost, and I think one of the biggest, is the time involved. I talked about this in the previous article linked above, so I won’t repeat everything here. However, there is significant time needed, even to build a focused, small, bespoke just for you, monitoring system. The important cost here is that this time is time not spent on the organizations core competencies. You’re building out monitoring tools, but not building out functionality for your customers and clients.
On this topic, you do need to plan for this being an ongoing cost. At Redgate we have four different development teams dedicated to SQL Monitor. These teams are working to expand its capabilities, keep up with new versions, and, fix any problems should they arise. I’m not saying you’ll need this level of commitment and support, but you will need some.
Next, you’re going to have to build out training for this new system, in order to show people, especially new staff, how it works and what it does. You’ll have to document how the tool works and how to use it so that your people can put it to work. Otherwise, they may not use it, may under-utilize, or may even start building yet another bespoke system (I’ve seen this happen a lot).
Another cost to building your own system is, again, time. Not the time spent building the system though. Instead, the time you’re going to be waiting to have a functional monitoring solution that you need right now. Sure, you’re going to have that bespoke system, but it’s going to be a while before you get it. Ensuring up-time and performance over the short term is still going to be a very manual process. Over the long term, you’ll be hitting these waits regularly as you add new functionality or have to change things as SQL Server updates are released.
If your organization doesn’t have people ready, willing, and most importantly, able to build these monitoring mechanisms, then there are additional costs. You may need to hire someone who does have these skills, who could still leave with the project incomplete. Conversely, you need to spend a bunch of time, and some money, training your people so that they can do this work. Either way, this is an added cost associated with building a solution.
Yet another cost is support. You’ll need to have effectively an in-house support desk for the people using this system. When they hit issues, who do they call, how long will it take to get fixed, and what work gets put aside while this issue is dealt with? This cost can add up quickly if your monitoring solution is offline and you don’t know the status of your servers.
Buy Vs. Build
Purchasing software certainly comes with a cost, right up front. Further, just like the tools you build in house, there will be some time involved as you install, configure, and learn your new monitoring solution. You’ll probably also have to plan for some time to customize it for your environment. I’m not saying buying a monitoring tool is a perfect answer and doesn’t come with some overhead that you should consider.
However, I am saying that a lot of the cost, and pain, involved in building your own system is eliminated entirely or at least mitigated severely.
For example, as I said before, the time involved in building and maintaining your own tool is radically reduced when you purchase one. Further, the time waiting to have the tool in place is reduced. Same goes for new versions of SQL Server since SQL Monitor is updated as the new versions get released.
Training and documentation are taken care of through the support you have on the tool. There are documents, videos and articles on all aspects of SQL Monitor, making implementing it extremely simple. While you’ll need your people trained, they can take advantage of all the learning opportunities already prepared for them.
You also get support and ongoing maintenance. If there’s a problem, we’ll fix it.
However, for me, the biggest return on the investment for purchasing a monitoring solution is that your people can focus on the organization’s core competency. I assume you’re not building monitoring software. You’re running a bank, a hospital, manufacturing, charity, anything other than monitoring SQL Server. Yes, there is up-front cost to buying a monitoring tool. That cost is offset over time with the ability of your team to do the work that your organization needs.
Was this article helpful?