Menu
How cloud services get built today

How cloud services get built today

Taking a great open source project and building it into a product people will pay for requires skills in development and operations.

Eliot Horowitz (MongoDB co-founder)

Eliot Horowitz (MongoDB co-founder)

Credit: MongoDB

The “open source business model” has been obvious for some time: It’s called cloud. But obvious in theory doesn’t mean it’s easy to pull off in practice. As software luminary Tim Bray once said, “The qualities that make people great at carving high-value [open source] software out of nothingness aren’t necessarily the ones that make them good at operations.” He’s correct, but it’s also true that during the past few years open source companies have become exceptionally good at cloud operations.

Just ask Confluent CEO Jay Kreps.

“Unlocking” customers with cloud

Confluent went public earlier this year on the promise of harnessing data in motion, or streaming data. Confluent is the primary sponsor of the open source project Apache Kafka, and to help it cover the costs of that development, Confluent rolled out a cloud service in 2017. Today, Confluent Cloud accounts for 22 per cent of the company’s revenues. More tellingly, growth in that cloud business was up 200 per cent, according to Kreps in Confluent’s first earnings call, outpacing the company’s overall revenue growth in the quarter (64 per cent), and even accelerating beyond Confluent Cloud’s trailing 12-month growth rate of 134 per cent.

Getting there, however, hasn’t been easy, to Bray’s point. As Kreps noted on the earnings call: “People underestimate how large a lift it is to build a really world-class cloud infrastructure product. Just doing that at scale across every cloud, across every region, having the full suite of networking technologies, the underlying security—it’s a lot. And until you ... have that, you’re really not ready to work with the best customers. … We’ve crossed that threshold. ... That may be surprising given the amount of time we’ve invested in our cloud offering. This is something we’ve worked on for years. But it is actually a big deal to do something that’s properly cloud native and do that right.”

In other words, it’s easy to say “cloud is the answer” to customer satisfaction and open source monetisation, but it’s quite difficult to pull off. As Bray noted, writing great software and operating great software require two very different corporate muscles. Increasingly, though, customers don’t want to run the software themselves. So companies like Confluent are investing deeply in both software and operations.

If you’re a company developing an open source project, how do you get from here (great project that developers love) to there (thriving company that customers happily give money to)? MongoDB co-founder Eliot Horowitz has some answers.

So you want to be a cloud company

Today, MongoDB Atlas, the company’s database service, accounts for more than half the company’s revenue. But it wasn’t always thus. MongoDB spent years building and operating the predecessor to its database service, initially a monitoring tool called MongoDB Monitoring Service (MMS), well before Atlas launched in 2016.

In an interview, Horowitz indicated that “Our goal was always to have a full database service,” consistent with the company’s original vision of launching a platform-as-a-service offering. But they opted to start with MMS to “get practice at [managing cloud operations] so that when we were ready to launch Atlas for real, it wasn’t starting from scratch.”

For open source companies looking for a model to follow, this is as good as any. Start small with a useful cloud service, even if it’s initially somewhat limited in functional scope.

That’s the operations part, but why should a customer buy from a particular vendor? If the underlying project is open source, anyone can build a cloud service around it. Hence, Confluent (as well as peers like Redis) also tries to differentiate its cloud service by adding proprietary extensions to the open source core, which is the same open-core licensing model that the industry has used for years. Kreps stresses that the goal of its cloud service, including these proprietary extensions, is to “make it easy ... to get the value [from Kafka],” even as the company makes it clearer why a customer should pay them.

Indeed, this model has become somewhat standard, even for the cloud providers, which often add their own proprietary extensions to otherwise open source software. In this way, Confluent and other vendors differentiate their respective services.

That’s the goal. But as important as that eventual cloud utopia may be, we never get there if the open source software isn’t built in the first place. As such, Confluent continues to build out its cloud operations, although the company also keeps focusing on making Kafka as solid as possible, treating it as a “low-level primitive for reimagining these kinds of [streaming data] applications.”

Kreps continues, “we’ve really focused on making it easier and easier” to get started with Kafka (on-premises or however you want), then making it even easier to scale in production through cloud. With cloud, Kreps says, “We can just do it for you. So 30 seconds later, you’re world-class at this new capability.”


Show Comments