It does suggest to me that Confluent will have to come up with something new/additional to survive beyond 5 years or so.
I disagree…
You pulled my comment out of context. The context is that Confluent has competition, including free competition and competition (both free and paid) using a newer architecture that has some advantages. And hence the need for Confluent to evolve within the next several years.
Data in motion companies: Confluent
And StreamNative. And the free/open-source Kafka and Pulsar Apache projects.
But I take issue with the whole “Data in Motion” label, which to me is marketing hyperbole. Moving data around costs compute cycles, which costs money, so it’s something to be avoided. What Kafka really offers is a “Publish and Subscribe” mechanism for events, and efficient handling of “data ingestion,” such as collecting data from millions of IoT devices. I’m puzzled at the ksqlDB thing, though, trying to make Kafka act like a database, which seems to me to be completely the opposite of what you’d want to do. It’s like Confluent has this message handling hammer (Kafka) and is looking for nails.
On the positive side,2/3 of their business today is on-premise, so there’s potential for growth for the hosted/cloud side, which is the future. Similar to MongoDB with their Atlas product that has continued to grow. But, I’ll leave it to those better at it than me to comment on the business results.
CFLT is hard for me, so I am staying out as well. I have worked at companies where we felt that it was too expensive to go with Confluent over managing our own Kafka installations. Kafka is not as complex to manage as say Spark which Databricks provides.
Confluents value proposition to organizations is hazy to me. I would guess that they are worth it if an organization deem the IOT events that Kafka collects and hosts as business critical and don’t want to risk relying on their internal Devops teams. It might also be a luxury which some wealthy companies can afford.
I see that Confluent is trying to branch out into more downstream applications of the event data gathered, by processing the queued events for specific purposes or providing tooling to process that data on the Confluent cloud. I am not sure how well that will stick given how pricey they are over using existing cloud capabilities within an organization.
I would say that I personally would not chose them over managing the Kafka queues in a organization that I work at. That calculus would change if I worked for a company in say Des Moines Iowa where we can’t find good Devops engineers and the company does not have a remote off shore team either.
So as that old Peter Lynch saying about buy the stock of companies whose products you want to use comes to mind. In this case Confluent feels like buying a Ferrari to transport me to Walmart for my shopping needs.