Monitoring products need lots of integrations - if your observability tool of choice can’t monitor a key component in your stack, you’re running partially blind. “Single pane of glass” is a cliche, but logging into multiple tools is just where the pain starts if you also have to duplicate all your user groups, alert configs, dashboards, saved searches, etc.
When I was building Server Density, a cloud monitoring tool, we spent a lot of time on integrations - both developing new ones and updating the existing set - but this went further than just writing plugin code. Integrations were also a key part of our marketing strategy because we partnered with many of the companies behind the products. We ran joint webinars, developed landing pages for promotions, ran events, and cross-promoted our products to our user base through email newsletters.
The most fruitful partnerships for Server Density were when we were able to ride alongside two rapidly growing organizations - MongoDB and Google Cloud.
Server Density was a major user of MongoDB. We were their largest deployment for some time, and their first customer, having used the product since early 2009. We quickly developed deep integrations into the MongoDB database APIs that allowed our customers to monitor their MongoDB instances (which we also used internally!). We benefited from being the only way to monitor MongoDB and were invited to speak about our product at events all over the world. We were able to leverage MongoDB’s popularity to accelerate our own growth.
The returns from this partnership diminished over time as they became larger, other vendors developed monitoring products, and we became one amongst many. As our efforts were winding down to being just a normal integration partner, we ramped up our engagement with Google Cloud. Although Google was massive, GCP was significantly smaller. We were early users of Google Compute Engine and became one of the bigger (external) users of Cloud Bigtable, working directly with their product engineering teams to provide feedback. I spoke at the first Google Next conference in San Francisco, and we ran events at Google’s Mountain View HQ and London office.
The same applies to devtools. Developers use a lot of tools. Languages and frameworks are one thing, but there’s all the infrastructure as well. Databases, queues, cloud providers, build systems, code repositories…there is always a long list.
What does this mean for devtools builders?
- Integrations are crucial to onboarding new users. If a devtool doesn’t work with the tools I already use, it is much less likely that I’m going to adopt it. Promising an integration can be a good sales tool, but it still blocks the ability to evaluate the product today.
- There are so many different stacks it’s very difficult to support them all, especially at the beginning, but there will be a common set. Finding out the most commonly used tools and creating good integrations should be a part of the v1.0 checklist.
- Integrations are liable to rapidly accumulate tech debt because you have no control over how the third party product will change. Keeping them up to date is crucial because if an integration breaks it has a double hit - both your existing users and new users who discover a broken setup process.
My main recommendation for devtools builders is to set up a dedicated team focused on integrations. This should be a multi-disciplinary team of engineers doing the building, marketing folks collaborating with the partner organizations, and devrel connecting the two together (events, webinars, tutorials, videos).
This is difficult for early-stage companies who will need to pick and choose a small number of high quality integrations for the most important tools. But creating a dedicated team, even if it’s just one full time engineer, would be a high priority use of funding.
Having an open source, well documented plugin API will help. Emitting statsd metrics or OpenTelemetry is a good way to expose metrics from your own products, for example. Some users will even create their own plugins, but don’t expect “the community” to do all the work for you. Only the minority will write their own integrations for your product, the rest will go elsewhere.
Also consider that the larger the partner, the less useful the partnership is likely to be. Although there will be some table stakes integrations you just have to provide, avoid working with anyone who has an official partner program - that’s a signal that they’re too big to care about you. In the early days you want to focus on where you can get the most value, which is direct relationships with a smaller team. We found MongoDB and GCP as they were just getting started - there will be similar examples today.
Returning to where we started, successful monitoring and observability product companies do integrations well. Take a look at Datadog, Honeycomb, New Relic, Grafana, and you’ll see a huge number of well maintained integrations, often through some kind of “marketplace”. The same applies to other products, such as how Auth0 supports many frameworks, GitHub Actions supports many workflows, and PagerDuty ingests events from various sources.
Notice how the best devtools you use also have the best integrations with the other tools you’re using. That’s what you’re aiming for.