Is it better to BUILD an internal monitoring environment, or BUY a prepackaged solution?

Valerio Barbera

“Build vs Buy” Bake-off: Which should you choose?

Every case is different, and all of these factors should be considered carefully before making a decision. There are situations where building a solution makes sense, either because you have the time, your requirements aren’t very complex, or if your applications simply don’t have enough load to justify investing in an off-the-shelf solution.

Summary

Introduction

Historically, implementing monitoring systems has meant building bespoke, custom architecture putting together several technologies (data processing, databases, storage systems, analytics dashboard, etc.); costing time, resources, and money. 

Thankfully, that’s all changing. Now there are more choices, but that means more consideration must be given before planning the way forward. When determining how (and if) to implement custom monitoring system, engineering and product teams must ask:

Is it better to BUILD a monitoring environment from scratch, or BUY a prepackaged solution?

Which provides the most future-forward flexibility, with the fewest roadblocks? Factors like cost, internal resource capacity, control and compatibility, maintenance and support, and core business competitive advantage should all weigh in when it comes to making this decision.

There is no blanket answer to the question of whether to build or buy. But the details that we explore in this eBook can guide you to the right decision––specific to the needs of your company.

Why Monitoring Matters

The time many developers feel the need to monitor their applications often coincides with when they first start working on a medium / large project.

The reason is simple: when your software becomes complex, or start to serves highly valuable customers, software bugs become expensive; doubly so when your customers find them! Customers may rate you as unreliable and search for alternatives. 

Solving critical customer problems can certainly generate great business opportunities, but the more critical the problem is, the more you need to be ready for really high customer expectations.

Monitoring is the way for developers to avoid unexpected incidents and retain customers or contracts as long as possible – which means stable income for your business over time.

Let’s look at some common reasons why developers are often not in the right conditions to monitor their applications properly.

1) Work overload

The most common monitoring platforms require to be installed and configured at the server level or on the IT infrastructure in general, but many developers hate to deal with it, and instead love to stay focused on coding.

Dealing with infrastructure is a concern for many developers for two reasons: 

Managing the IT infrastructure is a profession in itself. It requires a lot of vertical skills about server environments, and involves complicated technologies (like Kubernetes).

For basic needs developers tend to rely on external tools to automate server provisioning like Cloud Hosting panels, PaaS platforms, or similar, in order to reduce this concern.

But in large organizations or when the company scales up it may be necessary to have a dedicated team to take care of the infrastructure, and allow software developers to spend their time working on the application code and implementing new features.

2) Everything configured at the server level tend to be out of the developers control

Whether you’re using infrastructure automation tools, or even have external teams to take care of it, everything configured at the server level is out of the software development lifecycle, and developers tend to lose their autonomy.

Each team in your company has its own monitoring needs (Kubernetes, Cyber Security, Networking & Infrastructure, Privacy & Compliance, Software developers, etc.). Something that works for one environment may be useless in another.

Forcing the collaboration of different teams on the same tool can create confusion, constant email exchanges across teams to adjust configurations, customizations, and in the end software developers almost always have the worst because they have no control over everything that resides in the infrastructures.

Build vs Buy Considerations

  • Cost
  • Time To Market
  • Internal Resources
  • Customer Experience
  • Control & Compatibility
  • Maintenance & Support

Let’s take a look at each one.

Cost

Buying off-the-shelf software comes with a fixed price, but building and maintaining your own monitoring environment can be much more expensive.

The up-front costs are obvious: time to choose the right stack, engineering effort to install and configure all components based on your needs, update and support, and operational costs.

However there are many hidden costs to rolling your own monitoring solution that are not easily quantified: missed opportunity costs, on-going support costs (performance issues, patches), and productivity costs (pulling teams away from projects) can all create a hidden cost in terms of time and productivity.

Before you start throwing money out of the window, consider the long-term costs and labor commitments you could be signing up for if you opt to build.

Time To Market

As every engineering and product team knows, there is an inverse relationship between team size and time to market. 

It takes two people longer to design, build, and paint a house than it takes twenty people to do it. If you’ve got plenty of leeway in terms of your deployment schedule, an unlimited number of team members, or a tiny house to build, then developing your monitoring solution from scratch could be the way to go. 

But if you need to take advantage of streamlined processes in order to build more in less time, then buying an off-the-shelf, code-driven software monitoring solution would be the fastest way to solve application issues before your users stumble onto the problem.

Internal Resources

Aside from the time and money part of the staffing equation, there are the logistics of building a new internal team (or tasking an existing one) to build the monitoring environment. Will you hire full-time staff, or contract it out? It all comes down to your deployment needs and your access to a qualified talent pool.

If your in-house team already has the specialized knowledge and time available to use it, then building might be the way to go. But even if your team has time, do they know how to install and configure a complete monitoring environment? And is that what you want them focusing on instead of other tasks?

In many cases, buying an off-the-shelf solution and letting your team focus on your core business is a much better use of time and resources.

Business Continuity & Knowledge Transfer

One of the most important considerations in the build vs buy debate is the longevity of the chosen solution. Beyond thinking about the ongoing engineering hours that will be needed for development, security patches, underlying technologies releases etc, there is the question of succession planning.

The question isn’t, “How much time will this take someone to maintain after they build it?”

It’s really about, “Who will maintain this after them, and who after them?”

Followed by, “How will each new person learn the intricacies of the system?”

If the answers to these questions aren’t clear, then you may be in a situation where buying is the best option.

Think about it this way: most homegrown solutions are created by one or two engineers who become the experts in the systems they’re creating. 

This makes a lot of sense for core business logic and apps that are going to constantly evolve with a steady stream of new members onboarded. 

However, for ancillary systems that support the core business, these applications end up becoming a silo of knowledge. That’s because a monitoring solution vendor will be focusing on this problem exclusively, as monitoring is their core product. 

In other words, part of the off-the-shelf product you’re getting is the succession plan that comes with it. Since no specific person in your organization is building the system, no single person will be responsible for it. 

Instead, there will be several key points of contact engaging with the platform in several ways, starting with Support Engineers, QA, and even Sales Engineers. Each of these functions gains some amount of user-level knowledge on how the system works, with a clear understanding that the vendor will own the ongoing improvements and extensions of the underlying systems.

Customer Experience

Enterprises are businesses, but businesses are people. Your software solution needs to solve technical challenges while also being people-friendly. 

At a minimum, you’ll need to ensure fast reactions in front of an issue. That means more than just searching for an exception in a log file.

Customers do not spend their time reporting problems and application errors. No one cares about helping us resolve bugs. They just leave our application or services, and it may be years before we see them again.

Think of your code monitoring system as a virtual assistant for your developers. Being the first to know if your application is in trouble and solve the issue before your users stumble onto the problem will not only ensure an awesome customer experience, it will also help to build customer loyalty.

The internal developer experience should be consistent, and ideally supported with updates, patches, licensing and entitlements. Managing all of this takes time and resources.

Unless you’re prepared to make a significant upfront and ongoing investment, buying a third-party code execution monitoring tool that allows for easy installation, ongoing maintenance, and a great developer experience is the safest bet.

Control & Compatibility

The idea of control is alluring. Building provides more control over the tooling and all of its moving parts. When you build, you’re not ordering from a vendor’s menu and you’re not limited by their offering––you can control what and how your solution works with all of the parts you want and none of the ones you don’t. 

But all of that control comes with additional responsibility, and most of it isn’t very glamorous.

When it comes to compatibility, you want a polished, mature-looking, end-user experience, support for installation and configuration that works across many different types of programming languages and frameworks. 

Maintenance & Support

The process and the open source technologies you put in place to monitor your application’s code is a product in itself. And every product requires ongoing maintenance and support.

Larger enterprises all have managers and engineers dedicated solely to monitor their infrastructure for this reason.

So, while building provides more control, it also requires ongoing support.

On the other hand, commercial vendor solutions can be more low-maintenance, making it easier for you to deploy patches and updates. If you decide to buy, look for features like code-driven configuration that can be easily changed through application environments and releases. Developers will be able to maintain their autonomy against external teams by increasing their productivity already in the short term.

Competitive Advantage

Let’s talk about resource allocation and smart spending. If the monitoring experience is a core part of your offering, then obviously building a custom environment makes sense. But if your core business is Finance, or Transport, then investing the time, money, and engineering resources into building a monitoring environment with support for all the technologies used by your developers (a feature that is not a part of your core business) could be a big risk.

Here’s why: if you want to achieve a growth rate that will make your business profitable and sustainable, then you’re going to need to delegate beyond your in-house team. Don’t fall into the “humpty dumpty” trap. 

According to McKinsey:

“Once growth is broken, it is impossible to put back together again.”

Their data revealed that when software companies took a pause from growth––even when it was only temporary––they created less than a quarter of the value of companies that maintained their growth without pausing.

With this in mind, buying a commercial solution to automatically monitor your application’s code execution could be a better choice. Letting your development team focus on creating core capabilities at higher velocity is a better return on engineering dollars and a smarter way to solidify long-term success.

That said, if you have the engineering overhead to spare, have at it. Build the exact solution you want and need; just make sure that there aren’t any economic consequences for doing so.

Let’s Talk

But if you’re under time-to-market pressure, have limited resources, and need to focus your team on your product, then there is a lot to gain from working with a vendor. 

If this sounds like your situation, we built Inspector for you. Learn more about our modern Code Execution Monitoring solution that gives you the tools needed to find out bugs and bottlenecks in your software code before your customers are aware of them.

Still not sure which option is best for you? 

Schedule a short meeting with our CTO to check out your scenario.

New to Inspector?

Get a monitoring environment specifically designed for software developers avoiding any server or infrastructure configuration that many developers hate to deal with.

Thanks to Inspector, you will never have the need to install things at the server level or make complex configuration in your cloud infrastructure.

Inspector works with a lightweight software library that you can install in your application like any other dependencies based on the technology or framework you use. Developers are not always comfortable installing and configuring software at the server level, because these installations are out of the software development lifecycle, or are even curated by external teams.

Visit our website for more details: https://www.inspector.dev

Related Posts

How to prevent users from registering into your app with insecure passwords

Hi, I’m Valerio, software engineer and CTO at Inspector. About one year ago one of our accounts on an external platform has been hacked. Our credit card was attached to this account so we had to warn the bank to block it. Fortunately, there were no consequences, neither for our bank account, nor for our

How to extend Laravel with driver-based services

Hi, I’m Valerio, software engineer and CTO at Inspector. In this article I talk about a Laravel internal feature not mentioned in the official documentation called “Driver Manager”. It can completely change the way you design and develop your application solving critical architectural bottlenecks, allowing you to build large systems built around decoupled, independent and

Code Execution Monitoring for Symfony applications using Inspector

Hi, I’m Valerio software engineer from Italy and CTO at Inspector. As product owner I learned on my skin how an application issue can be so hard to identify and fix, creating negative impacts on the users experience, or block new potential customers in their on-boarding path. Users don’t spend their time reporting bugs, they