OSS Podcast: Chronosphere CEO discusses open source history

Last month Chronosphere CEO and co-founder, Martin Mao, joined Amanda Robson from Cowboy Ventures and Tim Chen from Essence VC for the 16th episode of their podcast, “The OSS Startup Podcast.” The three talked about a range of topics uncovering everything from Chronosphere’s open source roots to Chronosphere’s decision to be a SaaS company.

The hosts started off with a hat-tip to Chronosphere’s recent $200 million Series C funding round and ran through some of our investors, such as Greylock Partners, Lux Capital, Addition, and  Founders Fund. (Chronosphere has also recently achieved unicorn status and has raised a total of $255 million in funding.) Then they dove right in.

Here are a few key highlights from their discussion:

Let’s go back to the origin story behind the open source project M3 and how it came about

Martin: M3 started at Uber around 2014-2015. What really triggered it was Uber’s decision at a top level across the engineering organization to go microservices and a container-based environment. This was pre-Kubernetes. (Apache) Mesos was the platform of choice for the company – Uber saw a lot of the advantages of that, and other companies like Netflix, Google, and Facebook made that architecture fairly popular and they wanted to follow suit.

Once they made that decision, and we were starting to adopt this architecture, we realized that all of these solutions we had for monitoring – back then there wasn’t even observability, it was just monitoring – weren’t well suited for this new type of architecture. You’re trying to get the same things out of monitoring, but because the architecture changed so much, the requirements also changed a lot. We realized existing tools, whether they were open source (and we were using a bunch already) or vendored APM tools, weren’t applicable for this new environment. That’s what really spawned everything else.

The first thing we did was reach out to the few companies that had solved this problem before for this new architecture – like Google, Facebook, and Netflix. And they told us that they built their own solutions – that’s how they got around the problem. That set us down this path of, okay, we probably need to solve this ourselves. A lot of that stuff was not open-sourced back then.

One of the very early decisions we made was to build the solution that eventually became M3 in open source from day one. This turned out to be a great decision for us.

You can hear more about this part of their discussion starting around 00:30

Why open source for you and your team? What was really the driving force behind that? 

Martin: The initial driving force for us was looking at the size of the engineering teams that had built this before at these other companies. They were massive – high tens or hundreds of engineers. Our team was five to ten people and we ran open source off-the-shelf tech at that point. We knew we needed a huge team to go build our own, and we knew that the level of talent we needed probably came from a similar-sized tech company.

One of the main reasons for open sourcing in the first place was a way of attracting talent. It was a way for these engineers to come in and build in open source and share their work with the world. That happened to line up very nicely with Uber as a company and how they thought about engineering and showing off their engineering talent – just a very open-source friendly company.

One of the very first side effects we saw as a result of open sourcing M3 was that as soon as other companies started to use our tech, the requirements changed. We were building something from multiple environments, multiple sets of end users, multiple use cases – things that we didn’t even have inside Uber. That led into making the open source solution more robust – more generally applicable – and not just tailor-made for Uber.

You can hear more about this part of their discussion starting around 02:30.

Let’s talk about the relationship between open source tech and Chronosphere’s observability platform

Martin: My co-founder (CTO Rob Skillington) and I, and the core team here, worked on the M3 project for over four years at Uber. We left in 2019 (2 ½ years ago) to found Chronosphere. What we realized coming out of 2018-2019 is that it wasn’t just a select few large companies that are going to have this problem. The whole industry was going to move to Kubernetes. Everybody in the world is probably going to have our same problem sooner or later.

This was just sheer blind luck that we just happened to design this for Uber, because we needed it back then, and it just grew from there. It was a combination of that and knowing that there was a problem to be solved in the world, and M3 was a critical piece of that. But M3 itself isn’t a product – it’s a piece of technology – a storage tech, it’s a time series database. It’s not a product that you can consume.

From day one, Chronosphere has been working on building a product on top of the open source tech, as opposed to just having a hosted version – because the open source tech is a key piece of the solution, but it doesn’t solve the problem for a user.

You can hear more about this part of their discussion starting around 09:00.

When Chronosphere started, what was the first thing you had to figure out?

Martin: My co-founder and I looked at where we wanted the company and the product to end up one day and worked backwards from there. A couple of considerations based on our industry and the type of data we deal with included:

1. The time series database isn’t the solution that people want, either to run it themselves or to host it. Nobody was running M3 by itself. It was generally the backend for a monitoring solution inside companies. That moved us away from offering a time series database as a service, and more towards a monitoring product.
2. We looked at classic open core companies, like Elastic and MongoDB, and they were all gravitating towards SaaS… SaaS-first and SaaS-only. When we looked at how someone consumes monitoring data, or a monitoring service, that made sense to us because in our domain, the monitoring data is really metadata about your infrastructure. For this type of use case, SaaS seemed perfect.

You can hear more about this part of their discussion starting around 13:00.

Much more was discussed in their conversation so we recommend giving the entire podcast a listen. To hear:

• Martin’s thoughts on multi-cloud, cloud costs, reliability, and scalability, zip to around 18:00.
• How Chronosphere balances its open source and SaaS vendor roles, zip to around 22:00 and 28:00.
• How an open source startup like Chronosphere gains trust from large companies so quickly, zip to 24:30.
• To hear Martin talk about outcome-based observability and the role of the three data types (metrics, logs, and traces), zip to around 31:00.
• To hear from Martin what it’s like for an “engineer at heart” to start a company that has grown as rapidly as Chronosphere in two short years, zip to 37:00.