Business Breakdowns
· Matt Reustle
[00:00:00] S0: That differentiation of, it's not added features, the core thing is actually higher quality, is a meaningful differentiator. And this is something, to your point, that every business has to think through. And I talked to many people who want to roll out a premium tier of something, and extra features are just not that valuable and nobody's going to pay for it. I did want to touch on Databricks, the meaning. What's the origin story to the name?
· Alan Tu
[00:00:00] S1: To draw a contrast, there are a lot of examples of companies that have been formed on the back of a successful open source technology that have basically named their companies the technology. So, whether it's Docker, was a startup that was built to commercialize Docker the technology, you can think of MongoDB is another example. In the case of Databricks, the analogous thing to do would have been to name the company Spark. The reality is that there are a lot of benefits to that because again, Spark was a very well appreciated name. The brand and awareness that Databricks, the company, would have gotten from coming out with the name Spark would have been very beneficial, actually. But the reason why they went with Databricks is because from day one, they always felt like it was going to be more than just Spark. Databricks, the way they thought about it, was that there were going to be many, many bricks that you could all be used to apply around this broader problem around data. A simple idea, but underneath the decision to name it Databricks as opposed to Spark is this reflection of this long-termism of thinking about, what is actually going to set us up to become much more over time.
· Matt Reustle
[00:00:00] S0: I often think about that when companies evolve. There's an enterprise value of a brand that has multiple different products, and you could stick with that core product or you can evolve above it. And it's a little artsy in terms of the way I describe it, but I do think there's something representative of that. And I think it alludes to one of the points that you made early on, which I think is a good thing to bring in now, which is they've evolved in terms of what they offer, and they have many different things under the hood now. And I think this coincides with you and WCM's involvement in the business. So, can you talk a little bit about the evolution of what Databricks offers to customers and how it's evolved past that original state?
· Alan Tu
[00:00:00] S1: Databricks today has truly reached that point of platform. There's sometimes an easy framework of feature, product, platform within enterprise software, and I think Databricks has made strides over the years along that journey. Immediately following the success of commercializing Spark, what the Databricks team did a really good job of after that was recognizing, "Hey, who are we serving in the enterprise? It's the data engineer and data scientists." These are folks that are, after they process the data, they're actually building machine learning models to run some of these predictions and forecasts and recommendation engines, all those use cases we talked about. And there's actually a very complex tool chain to enable that process that Databricks very naturally extended to. And one of the products that they came out with, which ended up being open source again, was called MLflow. And so, this was another product that just extended the value proposition along the same use case for these data engineers and data scientists. They then came out with another product called Delta, which was a first step towards data warehouses, which we'll get into the convergence between Databricks and Snowflake. But Delta was another step in the direction of saying, "Okay, a lot of these use cases for machine learning are for advanced scale-out use cases, but they don't necessarily need to have the same level of performance that allows for what's called transactional use cases." That was actually an important next product as well.
· Matt Reustle
[00:00:00] S0: The transactional use cases, does that have to do with speed?
· Alan Tu, Matt Reustle
[00:00:00] S1: Speed is part of it. There's a concept in the database world called ACID. It's an acronym, A-C-I-D. The actual letters stand for Atomicity, Consistency, Isolation, and Durability, which is a long way of saying that there are certain workloads that require a certain level of guarantees around the quality and integrity of the data. So, when for a lot of operational analytical workloads, for example, just taking it back to a data scientist that's running an analysis about how many shirts we should stock in inventory, it actually isn't that important that all the data underneath it is perfectly in sync such that if one of the data sources is tweaked by a little bit, that totally throws off the analysis. But there are other workloads for which you need to have that guarantee that there are no inconsistencies in the data, that there isn't one person is changing a piece of data here which has follow-on effects there. So, that is another segment of the market when you think about the types of workloads that databases can address. That was an important extension and evolution of Databricks. And so, they then came out with a product called Delta, which was a first step towards addressing these ACID requirements. And one other really interesting thing about Databricks is that I think one of their core competencies is marketing. There's a funny story where when they came out with Delta, in order to explain to folks what Delta was, they gave out free T-shirts that said, "Delta is Spark on ACID." [00:00:00] S0: That's amazing.