4 things to consider before building your own monitoring solution

My family will attest to the unfortunate fact that I am a hopelessly inadequate handyman. My home renovation skill set extends to assembling flat pack furniture and putting up picture frames (just don’t expect them to stay up).

Given my obvious limitations, it makes sense that I should pay a professional when I have something to build around the house. But what if I wasn’t so incompetent with a hammer? What if I had the skill set to build my own deck, install a new kitchen or build an extension?

Or in the world of software, if I have engineering expertise, should I build my own monitoring solution or should I buy something from an established vendor?

The pertinent question here is this…? Just because you have the skillset to build something, does it mean you should?

Below are 4 things to consider, when determining whether to build your own monitoring solution.

1. Is monitoring a core competency for your business?

Unless a company’s core product is a monitoring system, that organization’s monitoring solution will not be the main focus of the engineering team’s development efforts. Consider whether you would also build your own Messaging System, Document Management System, ERP or CRM. Why not? Because the needs of most organsations, (though unique) are not dissimilar to thousands of other organizations.

As a result, vendors have been building off-the shelf software solutions that meet these needs for over 30 years.?

There are untold off-the shelf monitoring solutions, all with different strengths and weaknesses. Each vendor typically spends hundreds of millions on R&D developing and evolving their products. Few if any organisations would be willing to make this level of investment, unless monitoring was core competency.

2. What impact will the monitoring tool have on culture?

Consider what kind of culture your organisation is trying to develop.?

Users tend to want the “easy button”.

• Do we want a DevOps culture where engineers take responsibility for the software they deploy and the changes they make??
• Does this culture require democratisation of data within and between teams??
• Will users of varying skill levels (whether technologists, business users or support staff) need to interact with the monitoring solution?
• Will a home grown monitoring solution require users to learn a complex query language or swivel between screens to correlate Metrics, Traces and Logs??
• Will users be empowered to create their own dashboards and monitors or will they need to engage a dedicated team of specialist to get things done??

If the monitoring tool is not easy and intuitive to use, what impact might this have on adoption and the culture your organisation is trying to develop?

3. Have all of the costs been considered?

The most common justification for building a monitoring solution is an assumption that open source software is free and therefore money will be saved. At face value this seems logical, but only if all of the associated costs are considered.

Costs that are often overlooked include:

Hosting, networking and data storage costs

Consider whether the monitoring solution will be on-premise or hosted remotely and what processing needs and retention will be required now and in the future.

Operational costs

Engineers will be needed to build, scale and maintain the solution. Updates will be a constant consideration as the monitoring solution will need to continually evolve to meet the changing and expanding needs of the technology ecosystem it will monitor.

Costs associated with extending and enhancing the monitoring tool

New connectors will be needed as new data sources arise and new features and functionality will be needed as the technology ecosystem evolves. All of these additions and enhancements need to be evaluated, tested, implemented and maintained.

Outages Performance Issues and other unplanned maintenance

Like other IT systems, monitoring tools experience unpredictable performance issues, outages, and other problems. These issues can consume the time of not only the team responsible for the monitoring tool, but other teams within the organisation.

Opportunity Cost

How many FTEs will be diverted away from the core product to build and manage the monitoring solution? If the team is small, will the teams limited bandwidth restrict its ability to add features and functionality as frequently as desired? What might be the impact of delayed feature delivery on the wider business?

Training and onboarding costs

How much investment will be needed to train and onboard users of the monitoring tool??

Staffing expenses and overhead costs

All of the above requires FTEs and management oversight. Each FTE (if not a consultant) will also have an overhead contribution for things like insurance, office space and other benefits. This might add a further 25% to the salary cost.?

4: Am I creating a monster?

Developing software is seldom a once and done exercise. As such the final consideration is whether or not you are creating your very own software monster.

A decision to build should be made in the context of both delivering immediate requirements, as well as scaling and building out the solution as requirements expand.

Consider for example that what is table stakes today, may not be adequate in future.

If your organisation has it’s heart set on building a home grown monitoring solution but can’t sign-off on all of the considerations described above, then chances are you are facing an entirely different dilemma. The unfortunate truth may well be that those pursuing this strategy “LOVE BUILDING STUFF”.

Please share your thoughts on this article below. Your feedback is very welcome.

-------------

Chris Marshment is a subject matter expert in observability. The views and opinions expressed in this article are his own and do not necessarily reflect those of his employer.