InfluxData adds another 2.0 platform and opens a new front for cloud storage

ur.jpg

Inflow data, a time series database platform provider that already has different cloud and open source / local versions, adds to the casserole. It announces upgrades to the 2.0 generation of the open source platform, which includes some features that borrow from its cloud offering, some incremental updates and the announcement of a new open source project that will expand the reach of InfluxData to cloud object storage.

The open source platform has now added support to Power, the GUI-based, script-oriented query language that was originally introduced with InfluxDB Cloud 2.0 platform last spring. It is very much a departure from the original InfluxQL it was a more explanatory SQL-like language. It is also a departure from rivals like Time scale and Amazon Time Stream who has strongly embraced SQL

InfluxData’s reasoning is that a script-oriented language, even if simplified with a drag-and-drop frontend, is much more powerful when building analytical queries on time series data. Nevertheless, InfluxData does not pull the plug on InfluxQL. Keep that thought in mind.

Also, part of this release releases InfluxData jumpstart templates, which consist of single-file monitoring configurations for common application cases such as network and IoT sensor monitoring. This comes from a strategy of meeting users where they live – might as well make it easier to use the core.

And then another new front is announced in the war. InfluxData reveals InfluxDB IOx. It would extend the reach of the platform to data stored in parquet format in cloud object storage. As expected, InfluxDB IOx would embrace a modern cloud-native architecture by separating storage from computing. Storage will act as the durability layer, while query, entry, and indexing servers run in stateless Kubernetes clusters, with an administration layer at the top to maintain condition and keep the entire operation healthy. It would build on top of existing open source building blocks including Apache Arrow Flight to gather data for high-speed transport.

Along the way, we also assume that the project will develop APIs that can both subscribe to PubSub feeds from Kafka or, as part of change data streaming, publish update feeds from the database. There will be various APIs so you can query on InfluxDB IOx or what InfluxData tags are like the commercially supported version of this open source project with the language you choose. Along the way, we would not be surprised if the project was renamed, as a Google search of IOx today brings up Cisco IoT application environment.

Our concern is that InfluxData for a modest-sized company is juggling multiple data platforms. For now, there’s the classic InfluxData platform, which now has a 2.0 version; two generations of cloud platforms and now a new project that adds yet another engine to expand InfluxData’s reach for cloud object storage with a cloud-native architecture. There are many goals for a single technology provider that are not the size of AWS or Microsoft to support. InfluxData claims that it has the resources to push this forward, after not even dipping into the $ 60M Series-D funding they secured back in February 2019. But it’s not just resources, but the ability to focus, which becomes challenging when there are plenty of platforms or engines to juggle.

Keep in mind that the InfluxDB platform is without a doubt the most popular open source time series database out there, with the company estimating over 400,000 daily active occurrences out there in the wild. No wonder there is third parties get into the action, be the host their own InfluxDB clouds.

We start with our own confusion – there are two InfluxData 2.0 platforms. When InfluxData 2.0 was introduced to us a year ago, it was positioned as the cloud-native successor to InfluxDB 1.0, and the Influx QL query language was phased out. We assumed that InfluxDB Cloud 2.0 would be the future design point for InfluxData’s platforms. InfluxData characterizes the two 2.0 version platforms (cloud and open source) as “complementary”, optimized for different usage cases. The open source platform is a single node, good for local and edge implementations, while the cloud is designed for scaling.

At the time, we observed asking customers from a popular platform to jump to a new version with (at the time) limited backward compatibility was a riverboat game. We were also told at the time that InfluxQL was being phased out. Since then, the existing customer base responded with “Not so fast.” InfluxData keeps InfluxQL alive with APIs.

Clearly, the expansion of common APIs and support for Flux on the current platform are positive steps towards delivering a bridge strategy. APIs are popular ways to make cloud data platforms expandable and for the developer / user it will make InfluxData’s platforms expandable to different audiences. But in case of Azure Cosmos DB; Google sky Firestore and Key; and with notice of the new Stargate open source project, DataStax and Cassandra, they have different APIs that expose the same underlying storage engine. In contrast, InfluxData pulls this out with multiple storage engines in a manner reminiscent of MariaDB – it is clearly the more challenging road.

We would have preferred InfluxData to adopt a more active platform convergence strategy that would have centered on a more unambiguous goal, InfluxDB Cloud 2.0, assuming that the encounter with the paths would not happen overnight. And we wish the cloud platform had been envisioned in an expandable future to support different time series data types in addition to logs and metrics and with unified query for cloud storage in mind. We would have preferred it rather than devising new query and inventory engines.