I received some information the other day about a company that has just raised a truckload of cash (some $20 million) from well-respected VC firm Accel. I’ve had a bit to do with some of Accel’s investments in the past and they are well-respected in the infrastructure space, so I was interested to hear what they’ve picked up here. Instana is, according to the breathless press release:

the first monitoring solution to apply both automation and artificial intelligence (AI) to fully automate all aspects of application performance management (APM)

The company has raised $27 million to date, from Target Partners as well as Accel and so I figured there would have been a heap of engineering work done which had really built something unique. Instana is selling itself as a new way of doing monitoring, one that is focused on container and cloud technologies. Apparently, Instana is meeting enterprises worldwide that have become frustrated with the limitations of current solutions’ abilities to keep up with the high rate of application change, visualize containerized environments, understand performance and analyze impacts.

Which is interesting, since pretty much every monitoring vendor created post the advent of the cloud (companies such as NewRelic and Datadog, for instance) would suggest that they, too, fulfill this new and different need. Oh well, maybe those other guys missed something.

I figured the answer was in the positioning. You see, whereas other vendors talk about their solutions being all about application monitoring, Instana calls itself a management vendor. There is a significant difference there. At least in my over-simplified view of things, monitoring is about delivering dashboards, alerts and (like I wrote about Datadog the other day) some predictive insights about what might happen.

Management, on the other hand, is all about taking actions from an event. It’s about actually connecting some blip in application performance with some automated action to right the wrong. Closing the loop, as it were. Indeed, alongside a post I wrote earlier this week I commented that:

Firstly, I really want my monitoring vendor to learn and tell me when a problem is likely to arise rather than reactive tell me when one exists. Secondly, I don’t actually want to be notified that it’s found a problem, I want it to do whatever it takes to put that problem right. Automatically.

So, judging by the tone of the release, Instana had heard my request and were moving on from monitoring to management. Was it a Eureka! moment? Alas not, it seems the hype doesn’t quite meet the reality. I quizzed an Instana staffer about the actual meaning of the word “management” as Instana uses it and was told that””:

Instana isn’t spinning up or down servers, but it is able to automate the discovery of infrastructure – servers (added or removed), containers, microservices, etc. – as part of the application monitoring and management. The discovery happens within seconds, helping operations teams know right away if there’s an issue in a production application. Instana creates a dynamic graph or internal data model of the entire application: all the physical and logical components, their technology components, dependencies and configuration. The graph updates in real-time as changes are made, enabling teams to use artificial intelligence for precise troubleshooting, prediction and problem resolution. When Instana uses the term “automation,” it is focusing on automating application insight and understanding. In this way, the user of Instana never needs to manually configure the monitoring solution. Instana automates the discovery of the application under management, and automatically understands the application’s health.

Sorry for being grumpy, but this is ridiculous. Of course, monitoring should be automatic. it’s not like I should have to ping every individual server every five seconds to see if it is alive, any monitoring solution, by the very definition of the word “monitor” should be constantly listening for application performance and outages. Saying that simply meeting the definition of a word is somehow revolutionary goes far beyond gilding the lily.

As for Instana’s statement about being the first APM vendor to leverage artificial intelligence. Well, firstly I’d argue about what people call artificial intelligence. That slight quibble aside, my second and more substantive criticism lies in the fact that Instana’s competitors – Datadog and NewRelic, also claim to predict, in advance, performance issues through the use of AI or machine learning.

Maybe I shouldn’t be so grumpy and should just accept that marketers, by definition, spray the world with copious quantities of spin and BS. But it does annoy me. Instana may be a really great product, but by suggesting that it’s something that it most certainly isn’t, it runs the risk of turning people off before they even take a look.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

  • Mirko Novakovic |

    Hi Ben,

    thanks for covering us.

    I think “automatic” is a really important thing if it comes to modern environments. It is not about automatic monitoring, it is about the automatic and continuous discovery of all physical and logical components that you want to monitor and understanding their dependencies and behavior. With almost every monitoring solution you have to manually configure all kind of monitoring components and rules:

    – The agent – especially for APM tools. You have to integrate and configure the agent for each runtime environment in a different way – e.g. a JVM or CLR

    – The metrics and traces – normally you will also have to select the metrics and traces you want to capture manually, e.g. business transaction definition or critical transaction configuration. Sometimes you even need to do the tracing manually, e.g. with Open Tracing.

    – The alerts, thresholds, baselines etc – you have to configure when to alarm, e.g. 100% CPU load – as you said most of the solutions will offer some kind of prediction or anomaly detection, but you still have to select the algorithms etc per metric

    – The dashboards – you will have to build all/most of the dashboards by hand.

    We automate all of these parts – you start our agent on your server or as a container and we will see all running components (e.g. database, web server) and applications (e.g. Java, Python) and will attach to them and start monitoring the metrics and traces in realtime. We see all the changes, like new containers or services starting and stopping and use a directed graph to keep the dependencies over time. We automatically monitor key KPIs for each service and use a machine learning approach to see anomalies of performance, throughput, error rates and utilization. We then use our graph model to identify the root cause of the problem.

    I 100% agree with your statement: “Of course, monitoring should be automatic.” It is ridiculous how much manual work you have to do with our competitors solutions. And in a more dynamic and complex world it can be a hard task to keep up with the speed of deployments and updating the manual configuration of your monitoring tool.

    Happy to give you a demo and go beyond marketing statements.

    CEO, Instana

  • Hi Ben,
    Metricly previously known as Netuitive claimed to be doing AI for monitoring around automating threshold settings based on past, Site24x7
    has this now in beta as Anomaly detection. Monitoring reports (ie capacity usage vs availability) are for proactive mediation and Alerts should
    be 99% only be to indicate loss of redundancy not reliability. Report days,times, and thresholds need to be correctly defined to support
    proactive remediation. I am defining all of this in an open sourceish vendor agnostic Enterprise Monitoring Architecture
    Your thoughts appreciated.I submitted a Monitorama proposal for a talk on this

    Rick Parker

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.