Catering to the Bespoke: How InfluxDB Meets Developers Where They Are

At InfluxData, we pride ourselves on building a platform – InfluxDB – for developers, by developers. It’s not enough to simply “talk the talk.” As an engineering leader, it’s really important to me that InfluxData “walks the walk,” too. This requires a holistic understanding of our users, their familiarity with time series, the environments in which they work, and the problems they’re trying to solve. Only by examining each of these elements can we provide the variety and scope of tools that enable developers to innovate and build cool things quickly.

The following is a look behind the curtain into how and why we work to serve the needs of developers.

Meeting developers where they are

Oftentimes, platform builders need to decide early on what kind of “shop” they are and develop tooling around a particular programming language. On one hand, this makes complete sense. If users rely on JavaScript, for example, and you optimized your platform to process JavaScript code, then that (hopefully!) makes applications more efficient. But what about developers that don’t know or want to use JavaScript? They’re basically shut out of using this fictitious platform.

When we talk about “meeting developers where they are,” this is the kind of situation we’re trying to avoid. And where a developer “is” varies depending on where they are in their time series data journey.

I’d like to lay out some of our ideas about meeting developers where they are by looking at what tools and resources we currently have to achieve this goal, and how we go about building new solutions to meet the needs of our user base.

Getting started with time series data

The first thing we need to understand is someone’s level of comfort with time series data and time series workloads. The characteristics of these differ in some key ways from the world of relational databases, for example. (We don’t need to get into all the details, but if you’re interested, we offer a training course on the basics of time series data.)

We recognize that today, we’re in a very rich environment where there is tooling and packaging to do all sorts of things. And most developers, when they go to solve a problem, the first thing they do is go to the web and look for solutions that already exist. But putting those pieces together isn’t always as straightforward as you may suspect.

In practice, each of those pieces comes with its own particular nuances. Because it’s rare for developers to build something completely from scratch these days, that means there is often a certain amount of retrofitting that is necessary. Developers must consider the trade-offs presented by different pieces, and sometimes they need to choose between selecting a package that would require them to change the rest of their application or to go without it.

That means part of our job is to help developers “glue” things together easily and efficiently. We are very thoughtful about the fact that we have many developers with many different applications that all need to use time series data in some way, shape, or form. With so many bespoke apps and development tools on the market, it’s vital for InfluxDB to give developers a customized experience tailored to their individual preferences.

If a developer is building an application that presents data to end-users, like climate data from a home thermostat, we may recommend a specific set of tools or best practices that differ from a developer building an application that collects data behind the scenes and analyzes that data to make decisions or trigger actions.

Speaking their language

One of the first considerations we think about is what language(s) our developers know. Just like navigating a foreign country is easier if you know the local language, being able to develop in a language you’re comfortable with can make the app development process faster and easier.

This is why we provide client libraries in over a dozen languages, such as Python, JavaScript, Go, Ruby, C#, R, and more. Developers don’t need to learn a completely new language to use InfluxDB, which lowers the barrier to entry.

Getting data into a database is often the most challenging aspect of working with databases. That’s why we offer half-a-dozen different approaches for data collection, from Telegraf, which has 300+ plugins and can collect data from virtually any source, to the aforementioned client libraries, to native collectors, scrapers, and third-party ecosystem integrations. And, if none of those suit your fancy, you can always use our REST API and build your own.

We also consider where a developer is in their app-building journey and their comfort level with time series data. The idea is for us to fit in their world as opposed to forcing them into ours. What environment are they comfortable working in? What is their skill set? These are all things we think about in our mission to meet developers where they are.

Another major consideration is where the developer wants their data. Do they want to take care of managing time series metrics and databases themselves, and if so, do they have the security requirements necessary in their own environment? If not, perhaps they’d prefer we help manage it in a cloud environment, but which cloud? AWS, Google or Azure? We offer InfluxDB across all three of these major providers, and in multiple regions. As a result, InfluxDB Cloud frees up developers from managing infrastructure and allows them to focus on what they do best: building cool stuff.

How we continue to improve

Anyone in the development space knows that the industry constantly evolves alongside the needs and preferences of developers. That means the tools they use must evolve as well, and for us, it starts with getting direct feedback from users on how they’d like to use InfluxDB.

In this vein, the developer advocates on our developer relations (DevRel) team act as the first-stage filter for reporting user needs back to the larger engineering team. Our DevRels collect user feedback and spot trends and patterns. We’re not promising to solve every problem that a developer mentions to us. But we’re always listening and learning about what we can do to reduce the friction developers may face using time series data at the core of their applications.

There can be a bit of trial-and-error involved in continually improving the product as well. We use tools such as blog posts and community forums to test the waters with various features and capabilities and see what sticks. If momentum builds around a specific idea, we’re able to go back to the drawing board and see if it’s something we can build and implement. A recent example of this is our Native MQTT collector. This is a serverless, cloud-to-cloud data collection feature that we developed after receiving feedback that some of our users weren’t able to deploy Telegraf agents in their architecture.

Ultimately, leveraging open source allows us to interact with a much broader set of developers and to help them build applications for a wider set of use cases. It could be a college student who’s playing around with and learning about time series data, a startup CTO who’s doing something really innovative, or an existing enterprise that has a ton of time series data and needs a better way to manage it.

Creating a platform that meets developers where they are enables us to put developers first and provide them with the tools and resources necessary to progress along their time series journey rapidly, achieving that Time to Awesome we always like to talk about, and driving innovation.