Confluent (Pt.1) - Data Streaming Platform To Triumph The Middleware Industry

Summary

• Confluent is the category-defining vendor in the data streaming space with a growing user base and huge potential for very durable growth.
• In Part 1 we aim to lay a solid foundational understanding of the message queue technology that underpins advancements in data streaming.
• Laying this foundation will enable us to fully evaluate CFLT versus the competition and to assess its future prospects as digital evolution continues.
• In Part 2 we shall transfer the technical understandings over to the business analysis, and conduct in-depth valuation analysis on CFLT.

We've briefly discussed CFLT and the open-core business model in our previous multi-part report.

Themes: Open-Core And Long-Term Alpha (Pt.2)

Themes: Open-Core and Long-Term Alpha (Pt.4)

Although we have some insights on Confluent (CFLT), it was trading at uninvestable valuations that are unsuitable for most investors. Though CFLT is a great company with great characteristics, somewhat justifying the lofty valuations we've seen. Here are some initial thoughts:

• It is the category-defining vendor in the data streaming space.
• It is just in the early stage of its GTM with a growing user base hugely undermonetized.
• It fits in the big data theme very well.
• There is virtually no competitor (to some extent) in what CFLT is doing .
• It has tons of S-curve opportunities on the horizon, including connect, governance, and stream processing.
• The TAM is huge and CFLT is in a critical position within the data analytics value chain.
• The management team has a great vision, and performs well in product development, marketing, and financially, including good investor relations - refreshingly different to the anti-street tech bias of some pioneering innovators.
• CFLT's Kora architecture is very impressive. CFLT's managed cloud service is a total revamp of Kafka for the cloud-native era. With many other moves, CFLT has dramatically improved its level of cutting edge innovation, exhibiting that the vendor is still a Day 1 company.

However, with clients we speak to, it is rare for them to be content with these amazing technology-oriented fundamentals. Invariably, discussion about CFLT's skyhigh SBC and other financial metrics come to the fore, putting a dampner on investment prospects.

That being said, we believe, from time to time, CFLT will present investors with better risk-reward opportunities and attractive entry points, as we've mentioned in previous analysis, similar to what investors interested in SNOW are facing right now.

For this first part of CFLT report, we will detail the technical history of message queueing systems, major technologies and products, architectures, and CFLT's business model. This technical dive sets the foundation for our next analysis on CFLT's prospects, recent successes, competitiveness, market potential, and obviously, valuation and investment considerations. We strongly feel that setting this technical foundational understanding is important for investors to evaluate CFLT's future as real-time data becomes increasingly critical in the latest era of applications and AI. Our next report will be more high-level and business-oriented.

Middleware, Message Queue, and Pub-Sub

Operating systems, databases, and middleware, are three foundational elements for IT systems. Message queue systems are a critical component within the middleware.

A simple rule of thumb to gauge the value-add and consider the barriers to entry for building such technologies, is to check how hard it is to engineer an alternative solution that does a similar job. Clearly, AGI, distributed systems, and real-time systems are extremely tough engineering challenges. Message queue middleware plays a pivotal role by delivering more data in a timely manner as things evolve, and this is CFLT's remit and the essence of its core capabilities.

CFLT is a provider of software based on the open-source project, Apache Kafka, which is designed for event streaming, using what is called a pub-sub model for message queuing.

It has two products;

• Confluent Platform (CP) for on-prem software licenses and support.
• Confluent Cloud (CC) for cloud-delivered as-a-Service that is consumption-based.

These two products provide connectors, data streaming, governance, and processing. Event streaming is the ingestion of events (e.g., a new user signed up or an IoT device sends an alert) from the source system into destination systems and intermediary systems along the way, and is part of the broader Message Queue category. Event streaming is CFLT's core business, though the vendor has also recently expanded into stream processing by acquiring Immerock in January 2023, an Apache Flink managed services vendor. We also noted Immerock and Flink in our SNOW report part 2.

Before we dive into CFLT and its competition, let's make it clear as to why we need message queue systems (referred to here forward as MQ).

Generations of MQ

Early Beginnings: 1980s to 2000

The Advent of Message Queues

The era of message queues began in the 1980s with the development of The Information Bus (TIB) by Teknekron Software Systems. TIB introduced the publish/subscribe model, where producers or source systems publish events and consumers or intermediary/destination systems subscribe to events, to address the challenges of inter-software communication. This was a significant innovation that allowed messages to be exchanged between systems without the sender (e.g., the ordering system) needing to know about the inner workings of the recipient (e.g., the inventory system), enhancing system modularity and scalability. It was wildly successful, thanks to its modularity that enabled asynchronous sending/receiving of messages, solving engineering issues related to bottlenecks within the financial industry, especially for data exchanges using various trading software.

In 1994, Reuters acquired Teknekron Software Systems, turning it into TIBCO Software in 1997. TIBCO (standing for The Information Bus Company) expanded the initial offerings and specialized in middleware and infrastructure for various businesses, emphasizing real-time data distribution and analytics. In 2014, TIBCO Software was officially privatized through a $4.3bn acquisition by Vista Equity Partners (Vista also acquired Jamf Holdings in 2017, among many other software companies over the years).

Commercial Growth in the 1990s

By the 1990s, major corporations such as IBM, Oracle, and Microsoft recognized the potential of MQs for various enterprise applications. IBM MQ, one of the most prominent products from this era, was designed to provide reliable, robust, and secure message handling, specifically targeting critical business operations in sectors like finance and telecommunications. IBM MQ is highly profitable with $1bn+ in revenue, and like other old solutions, it was sold with tightly coupled hardware and software whereby customers need to buy expensive IBM hardware in order to use IBM MQ.

The Rise of Open Source and Standards: 2000-2007

Standardization and Innovation in the Early 2000s

The first generation of MQ systems are quite legacy by today's standards, as they are tied to the hardware, with a closely coupled ecosystem and complex integration work is required to get them working. As the Internet rapidly developed post-2000, the first generation of open-source MQs emerged, alongside the establishment of two key standards - JMS (Java Message Service) and AMQP (Advanced Message Queuing Protocol). These standards defined the fundamental interfaces and protocols for message queues. ActiveMQ and RabbitMQ became the exemplary implementations of these standards, spearheading the early open-source message queue technology innovation wave.

JMS, developed by Sun Microsystems as part of the Java 2 Enterprise Edition (J2EE) framework, aimed to provide a common API for various message queue products, akin to how JDBC (Java Database Connectivity) enables disparate clients and servers to interact with databases. This standard was intended to facilitate interoperability across different messaging systems by abstracting the underlying interfaces. While JMS significantly eased the integration issues across diverse MQ systems, inherently it was linked to Java, limiting its use to Java applications only.

ORCL subsequently acquired Sun, and leveraged its Java assets to patent troll other companies who developed systems based on the Java API, including GOOG's Android, which is based on the Java Virtual Machine (JVM). The limitations imposed by ORCL prompted the necessity for an MQ that was open-source and not controlled by ORCL or any other tech giant, leading to the birth of ActiveMQ in 2003. ActiveMQ allowed developers to integrate their Java applications with the JMS protocol to have them send and receive messages, without being tied to the Java stack or ORCL.