4 Attributes that Differentiate Performance Monitoring Platforms from Tools

4 Attributes that Differentiate Performance Monitoring Platforms from Tools - blog

The topic of tools vs. platforms and the role of each in performance management is one that is near and dear to our hearts here at SevOne. Simply put, while tools are great to address specific purposes, it takes a platform to give you all the data and insights you need to not only ensure good performance of your IT infrastructure, but to make smarter business decisions.

Tools serve a specific purpose. If you’re building a house, you use a hammer to drive the nails. (OK, these days you probably use a nail gun, but work with me here.) You don’t use the hammer to measure or cut wood – you’ve got other tools in the box for those jobs.

Extending the analogy to IT, something like LAMP (Linux/Apache/MySQL/PHP) is a platform, whereas HTML is a tool used to write web pages that may then be hosted on an Apache server. Similarly, a browser is another tool used to display those pages.

So how do we differentiate between a tool and a platform? With respect to performance monitoring, I’d say to be considered a platform a product must at once be four things:

  • Data agnostic, supporting ease of data ingestion and export
  • Open, with a great API with development community support
  • Scalable, without sacrificing speed
  • Extensible, to support new and exciting use cases

Let’s look at each in turn.

  1. Being agnostic means the platform can ingest any sort of data from any vendor’s tool, system or device. Data could be log data, metrics, SNMP alert data, information from sensors or just about anything else. A sound performance monitoring platform should be able to treat all data the same, with the ability to ingest it and perform analytics on it that yields useful information. And it should allow you to use insights gained from the data collection in an easy and repeatable fashion.
  2. Being open makes the platform more useful. Having open APIs makes it easier for other vendors or even customers to write applications to get data in and out of the platform. By publishing, advertising and documenting its APIs, the platform vendor enables others to come up with their own ideas for what they can do with the platform. Eventually, a community forms, coming up with software and tools that make the platform increasingly useful and valuable. Many of these tools may go well outside the realm of performance monitoring to address issues such as billing or resource consumption, identifying how people consume resources in an organization. With an open API, the possibilities really are endless.
  3. Being scalable is obviously a requirement because customers always want to monitor more and more devices. This has never been more true than in the current age of the Internet of Things, where some organizations may have hundreds of thousands of devices to keep track of, such as sensors of all varieties. But scalability is only half of the equation; a platform also has to be able to ingest and make sense of all this data with great speed in order to produce results that allow companies to make smart decisions in or close to real-time, or to feed automation engines that make decisions for them. (For a history lesson on performance monitoring architectures and why most can’t scale, check out this interesting video.)
  4. Being extensible means that you can continuously enable the platform to collect and process new things, find new relationships in the data and integrate with third party systems with ease. As customer needs move from networks to infrastructure, this capability has never been more important.

The point here is that yes, you can install any number of tools that will give you some performance data that will be useful. But if you want to get a complete picture, in real time, and monitor any device that may exist within your organization – or that of your customers in the case of service providers – you’re going to need an open, extensible, scalable performance monitoring platform.