Chronosphere | Cloud-Native Monitoring at Scale

Hi, this is Jerry Chen, general partner at Greylock. Welcome to Grey Matter. Today we have Rob Skillington and Martin Mao, co founders of Chronosphere that's building truly cloud native monitoring. Rob Martin, welcome to the show.

Thanks Jerry, thanks a lot.

We were lucky enough as Greylock to have led the Series A. And congratulations today on announcing the series B in Chronosphere. But before we begin, why don't we introduce the two of you to the audience and to the folks listening. Martin, why don't you start it and tell us about yourself, your background and how you came to start Chronosphere.

No worries, Jerry. So it's Martin here, currently CEO, co founder of Chronosphere. I've been doing this for about 18 months thus far and as Jerry mentioned, we're trying to provide a truly cloud native monitoring solution for the market right now. Previous to this I managed the development and SRE teams at Uber and co part of their observability team there. I was doing that for four years and previous to that I was a technical lead on the EC2 team at AWS. So I've been in the cloud infrastructure space for a little bit of time now.

Thanks Martin and Rob, you and Martin have worked together actually for a long time before Uber and starting Chronosphere. So maybe tell us a little bit about yourself and the history of you guys working together.

Yeah, of course, Jerry, Rob here, the current CTO of Chronosphere and co founder along with Martin. So Martin and I cut our teeth on distributed systems and infrastructure in general working on Office 365 back when it was still called Microsoft Online. And you know, we spent time together there and I always was extremely interested by infrastructure in general and went to work on various infrastructure problems for a handful of small startups. Was doing payments infrastructure for a while on a company that was acquired by Groupon and eventually led all of their payment processing at Groupon. Then I joined Uber in mid-2014, was there for four years, 11 months, so almost five years and got to spend some of the most productive time my life there building M3 in open source, which we'll get to is our open source horizontally scalable distributed time series database. And there's other components to it such as a streaming metrics aggregator and things of that nature. But yeah, it was a fascinating five years.

One of the things that got me super excited was this technology rod that you alluded to that you built at uber called M3 that is the basis of Chronosphere and it is this next gen or cloud data monitoring solution. And we've been talking a lot, the three of us, and internally here at Greylock, this move from on premise data centers and what I think I've been calling this cloud evolution to cloud only or cloud native stacks. The past 15 years since Amazon launched AWS, it's been this transition where it's been incredible. But you moved VMS from a data center to Amazon's data center, which is changing locations from point A to point B. And a lot of things didn't change originally, but a funny thing happened along the way the past 15 years that this separation of compute and storage networking, the elasticity of the cloud, the ephemeral nature of compute now has led to the rise of kubernetes microservices serverless. So the way you build apps for the cloud now look very, very different than you did building apps for your data center or even the past 15 years. And I think that's what attracted me originally to Chronosphere and M3 when you guys were Uber. And I'm super excited to see that vision you guys put forward come to realization now in a company. But maybe before we get into the technology, we should define what's changed in this past five, 10 years from pre cloud cloud transition to cloud native. So we hear the word cloud native a lot but Martin, help us understand what is cloud native Cloud native monitoring, what are the requirements? What's changing?

Yeah, great question, Jerry. So as you mentioned, we've been going through this cloud transition for the past few years. But now as we talk about cloud only or cloud first or cloud native companies, we're really seeing that new companies starting off today just start off with microservices oriented architecture running on container based infrastructure like Kubernetes. And we're seeing that a lot of the existing companies are shifting their infrastructure and applications in this general direction. And this architecture of microservices running on Kubernetes really brings a lot of advantages to the business. And the way that apps are built. And in this world you really need monitoring that is also scalable, reliable and flexible. Using monitoring tools that were never built for this era and really tailored for the VM and a monolith world doesn't really make sense in today's cloud native ecosystem.

Got it. So I get that you have applications now that are super elastic and resilient. You know, Google's been talking about this for a long time and kind of the technology that these guys build in this large consumer Internet companies have have now filtered down to the rest of the enterprises and you don't even have to be web scale like Uber or Google or Facebook to benefit from these cloud native technologies. But my understanding is these old modern technologies break or they're just not built because they have the wrong assumptions, right? So they assume a world where we have what, static VMs or large monolithic pieces of storage help us understand the assumptions that old tech stacks had and why they break or in what ways that they break as well?

Yeah, for sure. It's really probably three properties here in which these solutions or at least the problem has changed, and the first of which is the scalability aspect. So if you look at just the amount of data and monitoring data that gets produced in cloud native environments, you know, a container these days produces as many metric based monitoring data as a single VM did before, but you have many more containers, hundreds of containers running on VMs these days. And same for microservices. Each single microservice produces as many metrics as potentially a monolith did before. And you have a lot more of those. The first thing that happens is there's just a lot more data that gets produced and you need a far more scalable solution to even ingest store all of this data and leverage it in real time as well. But not only that, you need to scale that out in a cost efficient manner. As we're seeing companies making this transition, their overall infrastructure footprint doesn't actually grow very much. When they move from VMs to container based infrastructure infrastructure, they're really paying roughly the same overall resource costs. However, your monitoring bill during this transition actually goes through the roof because a lot more data gets produced. So the relative proportion of how much you pay for monitoring compared to your overall infrastructure cost doesn't really make sense anymore. The second thing that changes a little bit is around reliability. So we're seeing that cloud only and cloud native companies are really spreading their workloads not only over multiple availability zones, but also geographically over multiple regions in a single cloud provider. And in fact, more and more we're seeing people spread their workloads across multiple cloud providers to improve their reliability. And Kubernetes really helps with that because it standardizes the infrastructure that all of this runs on. And really when you think about monitoring, if you're monitoring these geographically spread workloads, you really also need your monitoring tool to also be spread across these multiple regions and cloud providers. What would be the point of monitoring all of your sort of general geographically spread, multi region, multi cloud provider solution with a single region solution and a single point of failure, that sort of defeats the purpose of that reliability aspect. And the final one is flexibility. So if you look at the applications and the infrastructure that we're running on these days, everything is ephemeral, so they don't live very long. And each time there's a new deployment, there's a new version of the application that gets deployed and all the containers that it runs on are rescheduled. And in cloud native, you're deploying all of the time, multiple times a day. So from a monitoring perspective, you can't really make the assumption that all the data being produced can be treated equally and that the data will live for a very long time, because it doesn't anymore. So if you look at some of these particular use cases like CI CD for deployment, what you really need is a tool that's as flexible as use cases, that is trying to solve and storing subsets of your monitoring data for a shorter period of time. For these real time use cases like continuous deployments, yet storing different subsets of data for longer periods of time. For other use cases like capacity planning, we don't no longer have a one size fits all policy that applies through all of the data. You really need that for flexibility points. So those are really the three properties that break when people make their shift to cloud native. You definitely need a more scalable, reliable and flexible monitoring solution to go along with your scalable, reliable and flexible apps that you are now monitoring.

Yeah, it's daunting. If you were a system admin or server admin today, the fact that your microservices could be sending as many metrics and data points as a former monolith, and then you have not two or three times as many microservices and monoliths. You have 100 to 1,000 times more microservices to a monolith. The amount of data. And to your point, the cost of monitoring now is outstripping cost of your infrastructure because the footprint that you need to monitor everything, keep things running is, is even orders of magnitude higher. And if software is the DNA of a company, the lifeblood of the company, you have to check the health of your company constantly with modern monitoring. What bogs my mind is we've seen this transition happen so fast, right? Amazon launched AWS 2006 and 15 years, we've kind of turned over the entire stacks. And we often like to say that big Internet companies like Uber or Google or Facebook have seen the future, right? You guys have seen this acceleration from on premise cloud transition, cloud native, not in the past 15 years, the rest of the industry has, but you've seen it in four years, five years, right? And the funny thing like, say a lot of developers and admins go through the five stages of coping, right? It's like denial, anger, bargaining, depression and acceptance. Like, denial is like, hey, nothing changes my application stats don't change from point A to point B go. Cloud's the same. Then anger, God damn it, why is my old tools not working for the cloud? Bargaining. Just one more microservice, I promise I won't use any other Amazon tools at all. And finally, you go through this stage depression, we realize all the tools and all the ways used to run and build things don't work. And then you have this kind of acceptance and hope phase where, holy cow, if you do embrace cloud native and go through these five stages of grief, the stacks and the technologies and applications you can build on the other side are fundamentally different and more powerful than we built 10 years ago, maybe. The curious thing that I love to hear about is Rob, at Uber, you guys went through these five stages, if you will, not in 15 years, but in three or four years maybe. Tell us about the journey you guys went through at Uber that led to the building of M3, then eventually Chronosphere.

Yeah, I like your analogy, Jerry. The stages is definitely accurate, I'd say at Uber we definitely went through a transition from bare metal VMs and then to containers. And it did happen relatively quickly. And definitely the way that you operate when you're in that pre container world is extremely different. You have basically instances are reserved. You set up at Uber, we were using Hapro proxy to actually route traffic between microservices. There was just a long lead time to even landing configuration to allowing your other microservices to talk to you, to anything that you just spun up. It was a very static world. And as we lent into the container world, everything became extremely dynamic and of course ephemeral because of that as well. The same amount of servers that we used to run the dispatch service on, we went from something like 50 instances to 5,000 containers because we ran far smaller units of compute, rather than taking an entire 24 core instance up by deploying a monolithic application on it along with that transition was definitely okay. No, we can still make graphite work for us or maybe Nagios can continue to fill in some holes. But it turns out, yeah, that was definitely not possible to operate like that, especially a due to discoverability, which Prometheus solves today nicely, even in a Container world where things are moving around, you can discover your instances and start ingesting metrics. Then of course, we ran into the very next thing, which was, okay, you now have a bunch of developers that want to use infrastructure just like they use Kubernetes. It's just an API. They fulfill the API, they declare the resources they need in YAML, and they're done. Having each team need to spin up a Prometheus instance was just not going to work for us. We needed a horizontally scalable platform where you just spun up your microservices and you automatically were ingesting metrics, no configuration required. And not only that, as a central monitoring team, similarly to how Martin said that in a container world you just have fundamentally more storage required for the higher magnification of the monitoring data that happens. You also can't really just add SREs or infrastructure engineers to cater for every single monitoring use case we found at Uber, you had to find something that was central turnkey and easy to scale out. And that was essentially what M3 was. The other things that you need are essentially the ability to really define at a policy level, declaratively similar to Kubernetes, how you declare and manifest how your application works. You needed to declare how your metrics want to be stored. You can say, I want to keep this application's metrics for so long. There's other applications at a smaller retention. Some of these metrics I actually don't want the per instance view on. If you're doing extremely high cardinality things, which used to work in an older, more static world, going from that 50 instances to 5,000 containers, that order of magnification means you need streaming metrics aggregation. For some of those use cases you used to do before that amplification happened. So you're measuring latency across your entire fleet or other things like that. That's what M3 and the streaming metrics aggregate aggregator does for you. I think more generally, like I want to map back to really the acceptance phase for us was working out. We needed to centrally scale and deal with this ephemeral nature. We can't use queries to aggregate data on high cardinality data. It has to be done with streaming aggregation, which today no vendor or open source Solution except for M3 offers at all and distributed from day one is really important. It's not easy to just slap on clustering or scale out onto existing solutions that might work for like up to five or ten nodes. But with M3DB, we had hundreds of machines that backed this Monitoring data and setting down that path from day one was extremely important to allow us to reset true level of elasticity that we have now today, which again, I don't believe any other vendor or open source solution truly has solved that true horizontal scale elasticity. They have to some degree, but again only for small clusters of database nodes then with reliability that Martin's already touched on this point, that was incredibly important both for it to be turnkey, but also able to collect metrics in whatever part of the world you're running your stack in. It doesn't make sense to run your application in Azure and then send all your metrics back to the us. You'll find that when a link goes down or your Azure stack is fundamentally cut off but needs to run independently and you have zero insight into what's happening in that data center during that time. Forensically you can't even see what happened if that link is unavailable. There's fundamental things that we had to do there early on to make sure that was going to scale and be reliable in the way that we built it. End developers all those things I just talked about there kind of encompasses what we thought of after our denial phase was required. And that's what we built over a four year period. And it took an extremely huge investment. But as you said, once you get on board with this and you make the right investments, the other side of this is extremely exciting in what we can monitor and how advanced our observability is in a new world.

I think it was tongue in cheek with the five stages of grief. But just hearing the inspiration for M3, it really holds true because at first we often are in denial that things have changed. Then you have this bargaining, which this bargaining phase is, to your point, Robert, you just change one thing, try to add things to an existing solution. Let me take my old monitoring solution, let me take something that I know works like graphite or Prometheus and add something to it. That's the bargaining phase. Let me just tweak it, let me just try to add one more thing. And you realize pretty quickly you can't just keep doing that because it breaks and actually building a new monitoring stack like M3 from the ground up. We have things like streaming aggregations that is a necessity for this modern world. You have to do that from the beginning and you can't just add that on later. And after you go through this deep, deep bargaining phase where keep adding things, you realize that you hit the depression phase where you realize, holy crap, I can't just Keep adding these one off tweaks after the fact of old technology. You can't make turkey fly or something like that because adding more feathers. Anyway, it's interesting to see what happened at M3 and oftentimes it's not just Uber had this need. You guys open sourced M3 at Uber and pretty quickly the rest of the technology community, the rest of world glommed on, not just to the scale advantage or the cost advantage, but a lot of the new features you talked about, Rob, like streaming aggregations, the flexibility, and you started getting some pull outside the community. So I think that reflects kind of a broader shift in the monitoring and cloud landscape out there that people are using older technologies, be it logs, old monitoring, apm, et cetera, but then realized that they hit a wall with cloud native stacks and cloud native applications and along comes M3 open source. And it really struck a nerve because people saw that and almost immediately said, holy cow, this is what we're looking for. So Martin, maybe tell us about you guys open sourcing M3 and how that fit into what you guys saw was this broader landscape shift.

Yeah, 100%. Jerry, to your point, I think we're seeing a lot of companies going through these five phases at some point and when they look at their existing tools, either it's a cloud hosted monitoring tool that they're using today, or a traditional APM tool, they're finding that it's not enough to solve their problems anymore in cloud native. And in particular going back to those three properties, if you look at today's existing tools, none of them were really built for the scale and the sheer scale of the data being produced in a cloud native world. And most of these platforms not only not built to ingest the data, they can't really leverage the data in real time either. So a lot of these platforms are not able to notify you of changes within, let's say a minute. Whereas really in the cloud native world doing continuous deployments, you really want to know within a few seconds if something has gone wrong to do things like rollbacks and whatnot. But not only can they not handle the scale, finding that a lot of folks in the industry are running into sort of cost prohibitors well before they run into the technical scale limitation. An example I like to give here is that, you know, if you're running a 10 node Kubernetes cluster these days, probably going to cost you into the five figures a year to run that infrastructure. But the cost of monitoring that Kubernetes cluster, the same cluster with Today's existing tools also cost you five figures a year. So that just the cost component to it really doesn't make any sense. And it's really starting to get companies to look for alternatives and maybe even look for things in the open source space as well. The other two properties break as well. So a lot of today's solutions are not reliable. A lot of them are built for a single region deployment and a single cloud provider, and a lot of them don't even give three nines of reliability. So when you look at that as a company, how can you ensure high levels of reliability for your service and your product to your customers if the tooling that you depend on to measure that can't even give you the same level of sla, it's not possible. Right? There's no way you could give and ensure and promise your customers three nines of reliability if the tooling you're using to measure that reliability isn't at three nines. And the final one is the flexibility. So not only are costs skyrocketing, but the ability to not able to control that cost as it grows over time is really frustrating. A lot of the folks in the industry today, and really a lot of the end users, their only choice is to use the system less, is to send less data. And that's really not the right way to go about this problem in our opinion. And you can see this in a lot of the pricing schemes of a lot of the existing solutions today. They're still priced per host or per VM or per metric time series because they treat every piece of data in the exact same way. And that approach just fundamentally does not work in a cloud native world where you need to sort of mold the data for the most optimal use case. And that's how you really sort of control your skyrocketing costs as you move forward. So you know, we were seeing that a lot of the monitoring solutions today because they weren't purposely built for cloud native, they don't really suit the cloud native world that well. And then the second trend that we're really seeing is around data acquisition and we're seeing that data production and data acquisition is fundamentally changed in the industry as well. And, and it's really gone from a vendor controlled world where you would either rely on an APM solution to produce the underlying and monitoring data, or you would rely on your cloud posted monitoring solution to provide proprietary formatted data to monitor your stack. And what we're really seeing with the cloud native shift and movement is that the ecosystem is now standardized. And everything in the cloud native ecosystem these days emits monitoring data in one standard open source format, which is the Prometheus format. And it's not just the data ingestion, it extends into querying as well. And there's a standardization around the query language, which is prompt ql, which is the Prometheus query language, as well as dashboarding with Grafana, we're starting to see that producers of software companies like Cockroach Labs who provide cockroachdb, they will provide not only instrumentation inside cockroachdb in a Prometheus format, but they also tell everybody what the dashboard should look like and what the alert definitions should be as well. And, and we're seeing that that is all open and available to everybody. And in fact having proprietary sort of formats of that is actually a disadvantage these days. And we're seeing that a lot of the proprietary vendors these days are having to shift and to also accept these open source standards as well.

It's interesting. So there are a couple of trends out there. There's one in terms of just you said the technology shift to microservices we've talked a lot about, but also a couple different vectors. One is around the open source standards. So a lot of kind of the vendors created 5, 10, 15 years ago be a wavefront, signal effects or even datadog, they're all embracing open standards because closed standards do not work in a modern cloud world. And the second thing you said is they all treat every bit of data equally. There's no kind of intelligence or context applied to that. And I think we hear from customers all the time complaining about overages, cost overages or cost integration general. And this is even at small scales, they're surprised by overages. I don't think they're talking about their cell phone bill or their data plan. When they say overages, what are these customers talking about that I hear all the time when they talk about these current vendors.

That's a great question. So it's definitely not their cell phone bill, but if you look at how pricing is set up on the existing solutions because you're paying the same for every piece of data that gets sent to these particular solutions and there's no way to control that. Your only way to control your cost is to send less data overall, which leads to a loss in visibility and a loss in monitoring. So none of these tools give you the flexibility or the ability to customize how you store that data for the use case. And we mentioned this a couple of times already, if you're looking at monitoring data on a per container level. There's no need to store that data for a year, so why pay to store that data for a year into these existing solutions. That paradigm doesn't sort of work anymore. And what we're really seeing these days is the way to really control your costs long term and prevent these overages or these skyrocketing bills is to change the way you store subset of data to match for that particular use case. And that's a much better effective way because as you run into sort of your cost limitations, the trade off isn't to lose visibility, it's really to optimize your monitoring and optimize the visibility for the particular use case.

You definitely hear a lot of customers in the anger phase of dealing with grief at the current vendors because of the cost that they have to deal with and the surprises and the lack of control. So I get now why some of these existing vendors out there that aren't even that old are stuck in kind of this transition and stuck in the early stages of coping with cloud native. Rob, maybe help us understand what's going on in the open source community. And I hear a lot of people talk about promoting Prometheus, but it's often not enough. And why is Prometheus not enough for a cloud truly cloud native monitoring solution?

You know, there's a few things going on here. One is that most companies when they kick the tires on Prometheus, you know, kind of deploy one per Kubernetes cluster and along with everything else that they're standing up, they stand up pretty much their vanilla Prometheus stack. And similar to most kind of architectures, you don't, you know, most companies don't just use Docker compose and deploy their application with a hello World app and the Most Smallest Vanilla MySQL instance. So you know, moving past that kind of initial deployment, you really need more than just being able to learn on your metrics and that is kind of what is needed these days. Monitoring is essentially more sophisticated because your application is more sophisticated and the needs from your monitoring is much more than just I can alert off metrics. And fundamentally, especially as you expand these Kubernetes clusters, the cardinality, especially on high cardinality histogram metrics are definitely going to overwhelm the capabilities of a single instance Prometheus here. So what you really want to be able to do is much like you configure different parts of your stack, you want to be able to configure you're monitoring to kind of match your application as it grows. And so, you know, we're obviously a vendor that has a lot of tools in this area. It's not just about ingesting Prometheus metrics, which of course, others have been adding integrations to. And you can send Prometheus metrics to many destinations now, but that's again, to your point, not what's just required. You know, we talk about your monitoring bill going out the window. It is kind of like the days of old where instead of your Internet slowing down when you went over your data cap, you just have a massive bill at the end of the day. Right. And so you want to prevent running through the roof on your costs, but you also need to configure your application to reliably transmit that data into your monitoring vendor. And what we've traditionally seen is for most people, unless you want to dedicate a huge team to building that pipeline and maintaining that pipeline itself, it's a lot easier to use something like Chronosphere, where the data, no matter how much data you're actually producing, you can reliably ingest it no matter what. And then you have the knobs and control levers to kind of shrink the actual number of data points per second down to the level of visibility you need without dropping data, without sampling. You know, it's about performing streaming metrics, aggregation on this to get exactly the view of data that you need for your applications.

It's interesting, we're seeing a couple trends in the companies I work with is it's often easy to get started with a Prometheus Grafana, like you said, but pretty quickly, folks outgrow. And I don't mean just outgrow scale. It's the complexity in the management of these stacks get expensive. And we're seeing kind of SRE teams or not SRE teams, Observability teams now become standard in most tech companies and most enterprise companies out there. Right. You have dedicated teams that are focused on observability. And what they have now is a decision to make compromises around what they record, what they don't record. And I think what I love about what you guys built with M3 and Chronosphere is cloud scale, low cost, and no compromises. You don't need to make these decisions of what you keep, what you don't keep in infrastructure. And you don't have to dedicate large armies of engineers to kind of maintain your observability or monitoring stack that is becoming standard out there in technology right now. Which leads me to the questions you guys. So we talked about how you guys saw the future at uber, really built M3 to kind of handle cloud native monitoring and all the requirements around cloud native monitoring. And then a year and a half ago or so, the two of you guys left Uber to start Chronosphere. Martin, maybe tell us about Chronosphere was built on M3. What is the offering that Chronosphere provides? How are you guys tackling this cloud native problem? And how are you guys offering this to customers today?

So if you look at what we're doing here at Chronosphere, it's really taking some of the properties that we built in M3 and an open source M3 and using that as a metrics engine to provide a product on top of that that is really truly built for cloud native. So we go back to the same three properties again in terms of scale, reliability and flexibility. You know, in terms of scale, we're really able to provide a solution that handles all the data that is being produced across the infrastructure, the application tier and the business tier in a single centralized platform. And we can provide that solution with economically sane costs. Right. So if you're looking at the Chronosphere solution versus a lot of the others in the market, generally our solution is about an order of magnitude or 10x cheaper than a lot of the other solutions out there. So it's definitely not something that's going to sort of economically block folks from using in the cloud native world. From a reliability perspective, we set up all of our storage to be not only replicated across all three availability zones, but also the ability to spread that data across multiple regions and multiple cloud providers, because we ourselves run on Kubernetes as well. So having a much more reliable solution than a lot of the others that are out there in the market. And then finally, in terms of flexibility, this is where we leverage a lot of the streaming metric aggregation functionality of M3. However, we turn that into more of a sort of user friendly product. So when you look at how you customize your data, it starts off with per team or per service cost accounting and rate limiting such that one team can't overwhelm the whole product or the whole deployment. For for anyone else, we provide that team sort of introspection tools so they can identify where the inefficiencies are in their particular use case for their monitoring data. And then finally we can apply those sort of streaming metric aggregation rules to down sample the metric data over time to set dynamic retention and resolution to it so you can Store it for the amount of time that sort of makes sense. At the level of detail that makes sense. And then you can also aggregate these things over time as well. Well, right. So if you have things like looking at the per container metrics on infrastructure, that may actually be important for you for the first couple of days, but beyond that, maybe you don't actually need to store and generally you don't need to store per container level metrics for a year, but you may want to aggregate them across a deployment or a whole service and store that data for a whole year instead. So really providing the flexibility through a polished end user feature there. We do all of this and still let our end users leverage the open source source ecosystem so our users don't have to change their instrumentation. They can leverage all of the open source instrumentation and integrations that exist today. So we can ingest 100% open source Prometheus format while allowing you to query it using 100% native ProMQL functionality. And you can also import your existing Grafana dashboards and Prometheus Alert Manager definition files as well. So the way end users interact with the system don't have to change. But we manage all of that as a hosted solution for all of our customers, so they don't have to manage it themselves. In fact, you don't have to run Prometheus or Grafana yourself on top of that. So that's like the foundations or the underlying properties of the monitoring solution that we provide for cloud native. We're also starting to provide a lot of features and functionality to handle organizational complexity as well, because it's not just the monitoring data that's exploiting, it's also the metadata. So now with a lot more teams that are operating independently, you also have a lot more dashboards, a lot more alerts, and the management of that has to change. So, you know, a list of a thousand dashboards for you to sort of scroll through, or a list of a thousand alerts doesn't really make sense anymore. And what we're trying to do with our product here, and what we're doing with that product is to help teams organize not just the underlying data, but also the metadata. So, you know, all the dashboards and the alerts, all of the cost accounting and rate limiting, all of the security controls, all of that is organizationally structured differently and it matches how a end user will think about their system. If you're in charge of a particular microservice or you're part of a particular team, all of your monitoring data, all of your dashboards, all of your alerts, all of your cost accounting, all of your permissioning is done in the scope of that particular service or that particular team as well.

Interesting. If I start with Prometheus Grafana and I really want to scale and run this for a cloud and a stack, Chronosphere is in many ways the best solution or best product out there, which is amazing for a lot of our companies small and big out there. They get started with some of these open source technologies, but pretty quickly realized that the best thing is to work with a vendor to scale manage all these other features above and beyond Prometheus and the open source community. But I read a lot about other technologies out there that can they talk about scale and the ability to run a bunch of data like data lakes is all the rage again. Or data warehouses to be kind of a central repository for customer data or business data. How come like a big data lake or a big data warehouse, Rob isn't enough to power observability and power monitoring for the cloud.

So this is pretty interesting. We saw especially at Uber that the real time nature of this data is the fundamental thing that sets monitoring data apart from other data. Most of that technology in this space is about improving time to detection time to mitigation, the ability to perform automatic rollbacks of your software or at least build building blocks on top of the monitoring data that allows you to do that. And data in a data warehouse fundamentally doesn't have that speed to operate on the monitoring data. So a lot of what goes into M3DB and other things in the observability space is about being able to index all this data that is being produced in real time and have end to end seconds of latency from event or time series occurring and it being indexed and accessible in some query that can be run very very quickly to monitor your data. So data warehouses in general just don't have that property. You know, they have much longer TTLs on the data making it into the system many minutes a lot of the times, sometimes hours. You have kind of Even with the most advanced streaming use cases for data warehouses, it's still far far slower than required for actually monitoring in real time. Your stack, that's the first thing you fundamentally just can't use it to actually monitor things. You could use it to ask questions about things that happened in the past, but again you need to marry that with your monitoring tools if you're using something different to ask questions about your stack than what you use to monitor an alert when a problem arises, you're living in two different worlds. It's hard to connect that data to each other reliably and say, okay, well in the future we'll be able to catch this by this thing that we're looking at. You can't do that with a data warehouse because that's fundamentally not connected to your monitoring data, which you can alert off of. So it's a lot harder to go from finding something and then actually installing a reliable alert to make sure that when it happens again, you're definitely going to get notified and things of that nature. The other thing that we do with M3 and Crown of Sphere, of course, is just make these longer historical queries much faster to run. A lot of other vendors and people that ingest Prometheus metrics store it in S3 or some other blob storage. When you actually go to run a query, you find it takes minutes for the actual response to come back. When you're asking questions about your data set, whether it's in a blob storage or it's in a data warehouse like that query taking minutes to run is not good enough. You can't ask questions about your data and quickly move between thesises and prove or disprove something that you're kind of investigating if that's how long it takes for queries to complete. So that's fundamentally why we believe that's not the solution and it's more like real time. Access to your data is fundamental to monitoring and being able to ask questions of your stack quickly and get answers quickly is fundamental to debugging and investigating and root causing issues. That's why we believe things like M3 and Chronosphere is the only way to fundamentally achieve that.

I understand the appeal for everything in a data warehouse or a single database. We came from a world, as you guys know, where we threw everything in a big giant relational database. But now the amount of data, the nature of data has changed so much that these purpose built solutions in a time series database or graph database often make more sense to solve a purpose built problem. That you can tweak a current database to try to solve these problems, but you're not going to get the speed, performance or latency that you just described. Rob, what I think engineers are now discovering is you need a purpose built stack to solve a problem properly. But the cool thing about M3 and Chronosphere, what I've seen in customers, is you can still have that central place to query all your data that you get from a data warehouse or relational database or a blob store. You can query M3 or Chronosphere and you can see the deep linking to traces you guys have done. If everything runs through Chronosphere through M3, you can tie your business metrics, your app metrics and your infrastructure metrics together and you kind of have the value of a central view of your data like a data warehouse gives you. But yet you have a purpose built technology stack underneath the hood to run this at cost, at speed and low latency, which I think is fascinating. But maybe on that theme, Marty, can you talk about a couple customer examples that have moved from an old vendor to Chronosphere or have started with Grafana, Prometheus and and have really upgraded the Prometheus game with Chronosphere, if you will. I'd love to hear about some real world examples of customers out there that face this hurdle and went through all five stages of grief and landed on the side with you guys.

Yeah, for sure. So I guess we can start off with the folks that start off in the cloud. Cloud first, cloud, native companies from the beginning. So one example here is a new machine learning startup called Tecton who started off by using open source Prometheus and Grafana to get started. But pretty quickly they realized that they ran to a lot of those issues with those open source solutions, including, you know, the reliability, the scale and the lack of flexibility there. And what they ended up doing is spending a lot of their time firefighting their monitoring solution. And when your monitoring solution goes down, it almost instantly rises to the top of the stack in terms of importance. So they were really looking for a solution that could solve all of these, these issues and what was attractive to them about our Chronosphere or about the solution we provide here at Chronosphere is that not only did it tackle all of those, those issues that were having with Prometheus, but they could easily transition over instantaneously because they didn't have to reinstrument anything at all. So within a couple of hours that had all of their data from their existing Prometheus instance into the Chronosphere product and they didn't have to worry about any of the management overhead of that at all. And thus far they've been using a far more reliable solution. These days they just don't think about monitoring problems at all and they can go back to focusing on the business. A different example on the opposite end of the scale is a company we've been working with. They are a very large delivery app company in the United States. They sort of grew up during this cloud transition phase where they used another solution, another cloud hosted monitoring solution. And they tried to use that solution for the cloud native applications as they did their migration to cloud native. And what they found was that as they did that transition that they found a lot of the pitfalls or the down sides that we mentioned earlier in terms of the cost of the particular solution, not having that solution be sort of of multi region, multi cloud provider flexible and then not having the controls to control their costs over time as well, and having sort of skyrocketing cost there. So with that particular example, what we did was we helped them again transition over to the Chronosphere platform so that they could not only solve these three properties that they were looking for, but also they could transition into and leverage the open source ecosystem, the open source community now. So they were stuck on some very proprietary vendor specific clients and protocols. And all of a sudden with this shift, they're sort of depending on a much more open cloud native ecosystem. Now that shift also was easier because of that because instantly they could get visibility into the infrastructure, just because all of the cloud native infrastructure now produces all of this data in the Prometheus format from day one. So we've been helping them sort of transition over to the Chronosphere platform quite successfully as well.

So Martin, you guys have been up and running selling Chronosphere to customers for about a year plus now. Tell us about beyond the two examples, what other types of customers are using Chronosphere? It's not just tech companies, right? Or large companies. It's a wide spectrum.

Yeah, for sure. It's definitely a wide spectrum. I think if you look at this transition to cloud native, it's happening across the board. It's not just new technology, technology companies, we're seeing many SMBs just start off in the cloud native world and they sort of need a cloud native monitoring solution from day one. So there are a lot of companies on the SMB side that are just starting off with open source tools like Prometheus and Refiner and then looking for something more as they scale up and grow. We're definitely looking at a lot of the digital businesses and sort of disruptors in the industry sort of make their or almost complete their shift to cloud native. And you know, that was one example I gave earlier. And as they're sort of completing that transition, they're looking for something more as well. But we're actually also seeing sort of more traditional large enterprises also come around and they're probably a little bit later in the adoption Curve, but they're also coming around and now adopting cloud native as well. So you know, one of our customers is a very large financial institution as well, and probably one of the more traditional Fortune 5000, but they're also running into these private problems as well. So I think this shift is almost happening across the board at companies of all sizes and all stages. I think that's what's really interesting about the opportunity we have in front of us. So we have a range of companies, both the ones that were born cloud first or cloud native, and ones that were transitioning that have really benefited from Chronosphere. So an example of a company that was born into cloud and native in the in the past few years and started off by using an open source solution like Prometheus and has outgrown it over time is Tecton. They are a machine learning startup that started in the last couple of years and again they were born from day one to be cloud native and they started off by using the Prometheus solution, but really quickly ran into the limitations of that solution. These included the fact that all of their modern monitoring data was siloed for each of their environments, so they could never get a view across multiple environments at all. All of these individual Prometheus instances were a single point of failure as well. So anytime any of these instances experienced issue, it would almost take top priority because when the monitoring is down it generally takes top priority. So a lot of the engineering time was spent firefighting the monitoring issues and not really focusing on their business at all. And finally, they had limited data retention as well. They could really only store a few days worth of data in these Prometheus instances, which really limited how they could use the data that was being produced. So they onboarded onto the Chronosphere platform and were able to maintain their existing tool set so they didn't have to change any of their instrumentation and they could now or they could continue to use PROM QL as a query language and leverage their existing grafine and dashboards as well. So they kept all of their existing interfaces and toolset but didn't have to manage any of it at all. And it actually solved all of their the other monitoring pain points as well. In the sense that all of their data was now centralized across all of their environments in a single solution. So they had access to view all the data across all the environments, yet they didn't have to deal with any single points of failure anymore as the data was now replicated and spread geographically. They also had access to long term data Retention. So now they could store their data for many months instead of a week. And also the ability to control the data policies to match the use case. So they didn't have to store all of their data for months. They could pick and choose a subset of the data to store for various periods of time. And that helped them optimize their costs even further. And you know, the, the summary is for them, they just don't have to worry about monitoring anymore at all. So they just don't spend any time firefighting the monitoring system at all. On the other end of the scale, we have companies that were not born cloud native or cloud first, but really made the transition over the few years. So one example here is one of the largest app delivery companies in the US they started off with a cloud hosted monitoring solution, so something like a Datadog or a Wavefront. And they started off on that solution years ago ago and they really sort of adopted cloud native more recently. And as they made the transition to cloud native, they found particular issues with their existing cloud hosted monitoring solution. And these issues included primarily reliability issues at scale because their existing solution was all hosted in a single region and this existing vendor had all their customers multi tenanted. So any issue that impacts any one customer, sort of any impacted multiple customers and it led to a lot of reliability pain points. On top of this, with the amount of additional data that cloud native systems produce, this company also experienced skyrocketing costs on their monitoring bill as they made this migration. And it wasn't just the cost, but it was the inability to gain any visibility or understanding into where the costs were coming from or how to control it over time. And then finally they also had to deal with the pains of a proprietary ingestion format and proprietary tooling in a very open ecosystem these days. So you know, not only were they not able to leverage the open source community, but they were really dependent on this vendor for all the integrations and updates. And when they onboarded onto Chronosphere, they actually replaced all of this proprietary formatting tooling with open source based ones. So they made a shift to, to instrument everything using Prometheus instead. And now they're leveraging the rest of the open source community in terms of not only the integrations with infrastructure and third party software systems, but also leveraging the community for a source of their dashboards and alert definitions as well. They also no longer have scale reliability issues as with Chronosphere. They now get their own dedicated resources and isolated resources and they don't share that with any other chronic customers so they don't have to deal with noisy neighbor issues. And the system overall is just a lot more reliable because the data is now replicated across multiple geographies. And finally, they cut their build down significantly as well. And they did that initially as they made the transition over from their existing solution. But not only did they cut the build down significantly initially, but now they have full visibility into where all of the cost goes towards and also control over it by having the ability to customize their data policies moving forward. So there's a lot more control on that cost as they move forward and continue to use the Chronosphere platform.

That's great, Rob. You guys started this company July of 2019 and then about eight, nine months later, we found ourselves as a company, as a planet, in the middle of this global pandemic of COVID 19. What has been like hiring or running and building a culture of your company during a pandemic? And what have you guys changed or done the past few months to really adjust this new world in general?

It's been something that I think a lot of people have just kind of put their heads down and just solved on a, like a tactical and logistical side of things. And kind of that was the approach for the first few months after Covid began to change kind of the way that everyone worked and how we were going to operate. In terms of us, those logistical and tactical changes weren't huge. I mean, we're a software company going from working in the office to working remotely. Oh sure, we had to use Zoom more and our project management planning changed a little bit, but it wasn't, you know, it wasn't like night and day. And so that wasn't, you know, too much of a crazy change. But I think the more strategic things that you need to do during a time like this were more interesting and took a lot more thought and nuance to pull off things like getting teams to reliably talk to each other about things that were going on inside of work outside of the context of like an individual Zoom meeting that was purpose built for a project. Check in was difficult. So some of the more strategic things that we began to do was hold digital morale events which had team building aspects to it. That was pioneered by our head of operations and head of recruiting, Kirsten and Natalie. Then there were other things that we did to try and boost engagement just with, you know, talking about things that was not just a check in on a project, but a meta level discussion about what we were doing, how we were working, how we were rolling out changes to production. All that kind of stuff is this natural ebb and flow of conversations that usually happen like at the office that needed to happen and continue to happen and required some facilitation to actually make possible and, and made sure that people were actually talking to each other about things that weren't just purely tactical things going on day to day. And we have a few programs to help with that, which is randomly pairing up our employees with each other to have a catch up every so often, which helps with connecting across the company. There's other things, of course, like trivia and virtual games that people can play on a regular scheduled basis depending on what they like to do in their spare time and things like that. But yeah, overall it has been a focus on that. I think we're never going to shift away from that strategic investment because this is fundamentally, I think we need to get this right, especially now that our workforce is such a high percentage of them are remote and we could be remote forever. So I think it's actually great for us. If anything, once people are back in the office, it'll just be much more well supported with how people can both work in the office when they need to and how they need to. Maybe not everyone will go back full time. There's much more of a hybrid model and as a company we've invested much more in making any sort of hybrid model or remote part of the work much more richer and engaging. So I think actually overall at the end of all this, we'll probably have benefited a lot from the changes and, and areas of investment we've had to make to support and kind of let everything grow and flourish under how we've been working. But Martin would love to hear your two cents on this.

Of course, quickly for me, you know, I think Covid definitely threw a wrench into the way we're growing this company and our expectations, you know, just at a very high level. We knew we wanted to be distributed from day one, so we started off with three offices, but we've since gone completely remote. Now I think we have employees in nine states in the US and three countries in the eu. We've completely changed our go to market and selling approach. Trade shows are not the same as they were when they were when we were able to attend them in person. So we've sort of had to change the approach there as well. And then we've also had to change the way we're building our culture. So we used to rely heavily on meeting up physically in person and traveling to events and whatnot. We can't rely on that anymore. So we sort of had to change our approach to how we build the company culture. And a lot of the specifics were things that Rob had touched upon earlier.

So. Rob Martin Building a company during COVID is challenging, but maybe go back to the start of starting Chronosphere. What was the plan and thoughts around the first team to build around? Did you guys know who you wanted to hire out of Uber was your original network? How did you guys think about the first few hours and especially talk more about Seattle vs New York Geographies as well?

Yeah, I think when we first started we knew we wanted to hire some of our original team that worked on M3 at Uber for sure. So folks that have worked on the project in our network from the beginning, we knew we wanted to build a distributed team or at least a team with multiple offices. We knew we wanted to build a SaaS offering and needed engineers sort of on call around the clock. So we it wasn't just Seattle and New York, but also fairly early on a European office as well. So we had multiple time zones covered. And I think outside of that initial team, what quickly became a high need for us was picking the right leaders in place as well. So about a year ago, the team was actually fairly small. I don't know if you remember Jerry, but about 10 of us or so we really took a lot of time to find those original leaders. So the head of our engineering team, the head of our product team took us a very long time to find. But once we we made those key hires, I think that allowed us to set the right foundations and build the rest of the team this year at a much faster pace.

Yeah, and I just add to that that the type of person that joins the team matters a lot. A lot of the difficulty was finding very capable people, but that kind of thought about things the same way. So would deliberate long on infrastructure problems than normal, would care about how a DevOps tool was written, not just that it implemented and unlocks like a use case for like a DevOps workflow and monitoring. And so as Martin said, it took a long while to find the leaders in that space and then also just bake the initial culture and mindset of like how we did both infrastructure and products. Because you know, at Uber it was more just about the infrastructure, not necessarily about the user experience. While that was important, that obviously came second to just the scale requirements. So I think like just baking that initial culture also took some time, but has paid huge dividends. Because it's made it very easy. We really know who should join the team now based on like permeating and molding that kind of team over a bit of time. Time.

Rob, one of the things that strikes me interesting about Chronosphere is not just the ability to hire both infrastructure and the app and the user experience teams and develop both. But in addition, you talked about the infrastructure and kind of the cloud hosted team, but also emphasize on diversity inclusion. You guys from an engineering team made a big push early on to find underrepresented minorities, female engineers, et cetera. How do you guys think about making sure you guys have diverse engineering culture from the get go? And how were you guys able to bring in diverse individuals onto the engineering team?

This is something that's near and dear to my heart. I have a little sister who is a front end engineer, just made her way out of university into the wider engineering workforce. It's a really hard and difficult problem, I think, to really foster just a more diverse workforce. And I believe that everything that you can do, you should do. But sometimes to really move the needle, you know, you have to have dedicated efforts and dedicated people that care about this effort carving out very significant time of their day job to make it happen. So a lot of it is hiring people that care about this problem. And so, you know, it just so happens that Natalie, our head of technical recruiting, cares a lot about this problem. Space has led multiple of these types of programs within some of our previous companies like Lyft and also, you know, has worked in startups and she knows what it's like to kind of help people feel comfortable walking into a job at a startup that doesn't feel like it has as much support perhaps as a bigger company with its various erg groups and stuff like that. For instance, like, Natalie worked at a eero, which is like a Wi fi mesh, you know, consumer application hardware actually as well, obviously. And so, you know, Natalie, I think cares very passionately about this and she dedicates a significant part of her job to that cause and that's really what moved the needle a lot. Of course, with support from myself and the rest of the team and of course course with from all the chrono gals that now are part of the team and can feed that back into helping Natalie as well as our other diverse engineers at Chronosphere. The other thing that Natalie did was join us and partner with Anita B. Which is a fantastic organization that I think has a lot of opportunities for up and coming female engineers as they kind of like explore the industry and either going into jobs straight out of university or leveling up and looking more broadly at opportunities than what they are doing today. And more senior roles in different type of sub industries like infrastructure. So we did a webinar with Anita B. On infrastructure engineering in general and one of our engineers pay helped kind of put some real tangibility to what it is to be a infrastructure engineer in the industry. And so I think, you know, a lot of these things take time, they're deliberate investments and they've got to come from a place of deep care and continued reinvestment to kind of foster.

That's great. I mean I think the takeaways are having dedicated resources both from leadership as well as recruiting to make diversity a priority is absolutely important. And number two, just like leadership from you and Martin from the top down, to let everyone know is important in getting this first engineers in early is a huge shift in terms of both mindset culture and I think it's one of those virtuous cycles once you start recruiting becomes part of the habit, part of the culture that kind of continues itself going on, which I think is just impressive what you guys have done, especially in a startup land and moving fast, we're able to build a diverse team.

Yeah, knowing early what you care about and investing there helps permeate that culture and knowing what's important to you, which makes that hiring a lot easier to happen at scale because you have such a good idea of what you're looking for in the team. And the attributes of a successful person at Chronosphere all start to become easily identifiable.

Martin, One of the other areas of recruiting that's also difficult for founders and startups is when do you build out and how do you think of building out your leadership team? So when do you know to building your VP of engineering, engineering, leaders, leadership and management? When you bring in product management, when you bring in marketing, sales. I'd be curious, Rob and Martin, how do you guys think about when did you guys know it was the right time to bring in more structured leadership? Because clearly you want to keep moving fast and keep things dynamic and you don't want a small company to feel like a big company, which is always the fear. How do you balance the ability to move fast and agile with the need to bring in leaders and non engineering functions as well?

For us, you know, both Rob and myself have an engineering background so definitely easier for us to find engineering and product leaders because that's what we're more familiar with. And I think if you look at when we started the company, we need to build the product first before we could sell anything. So I think, you know, the time on the product and engineering side was much earlier for us as a company to hire the leaders there. And you know, I do think that setting the right foundations there, not just with the leadership, but the process they bring in is pretty critical fairly early on. So we made our engineering and product leadership hires fairly early on and it has taken us much longer to hire other leaders in the company on the go to market side just because for us it was about building the product the very first year and that was really the concentration and now as we think about getting it to market, we needed the first hand experience ourselves of trying to sell the thing, trying to figure out who we're trying to sell this thing for, where the fit is. And once we've figured that out, then trying to bring in the right rest of the go to market leadership team is the right time to do that. Saying that outside of product and engineering, we also hired our sort of head of HR and people and culture fairly early on as well. Because again to everything that Rob has said earlier, it's something that you have to set right from the beginning. And I think having the right leaders there from the beginning was also critical for us as well.

What would you guys have done differently, looking back in the past year and a half in terms of hiring, what we have done either sooner or later or definitely when you thought about hiring and building your team, now you can go back in time, it's only been a year and a half and the teams move pretty quickly. But kind of curious, what would you change if anything?

I don't know if there's too much that we can change because I don't know how much of expectations, nobody really expected a pandemic, so I don't know how we really could have built a company in this time any differently. I think for me personally, you know, picking the leaders that we had, we did that at the right time thus far in product engineering and in people and culture. I think looking back now, maybe we could have recruited our go to market leadership a little bit earlier. And even today we're still looking for that right now. So probably could have done that a little bit earlier. But again, I think these things are fairly hard to predict, especially during a pandemic year.

It's one of those things where it takes a long time to understand what looks right. And you know, during that hiring process, a lot of the boot up phase is about establishing what does like an amazing employee at Chronosphere in that role look like, you know, I think especially for as man kind of lead to positions outside of product engineering, that took us a while to, to establish. So I guess, yeah, to man's point, it's. The circumstances are definitely hard to predict. We could have looked a little bit earlier for some of those roles. But, you know, having said that, it probably would have taken us about the same amount of time from start to finish to really fully feel like we're making the right hire, the right person, the right level, the right background, the right experience for some of those hires. So probably wouldn't have changed too much of the time to hire in these roles. Maybe it would have shifted it up by a few months in terms of them like appearing on the scene earlier. But having said that, in the greater scheme of like, you know, we've been at this for a year and a half, one or two or three months difference. Delta is probably not going to change too much. And we had such an immense focus on the product at the beginning and making those early customers that are, you know, were kind of desperate for a solution in the space really happy. So yeah, all in all, we're happy where we're at.

You alluded to not being able to predict a pandemic during 2020 when you guys started this company in mid-2019. I think starting companies, always both a leap of faith and passion, but also you go in with a set of expectations of what it's going to be like to found a company. The reality sometimes is very different. But take us back to the moment where you felt like, yeah, this, it's time to leave Uber because that's a great job too. Running the teams you guys did at Uber is definitely a great job. You guys could have just stayed there for many years. You know, what was the impetus to take the plunge and how has it been different than you guys expected?

I think taking back to what made us take the plunge, I think for us, you know, we definitely had very great jobs at Uber building great technology. I think for us it was the realization that this was an opportunity that only comes along probably, probably once in a decade or two in terms of where the monitoring industry was and how the shift to cloud first and cloud native was really creating a lot of opportunities. But that timing lined up really well with the solution that we had built for M3, the open source project. I think having built that in open source validated that there were a lot of other companies running into the exact same problems that we did at, at Uber. I think all of that came together to make it the perfect opportunity in terms of the technology we have, but also the timing to create a company in this space. And for us, I think if we didn't do it, probably be, at least for me, one of the biggest regrets of my life if I didn't take that plunge. So that was it for me, I think. To your second question. I'm sure we'll dive into this more afterwards. But to T's second question, I don't think I didn't have many expectations going in as a first time founder. Didn't really, really know what to expect. I think that was good because I don't think anything can prepare you both inside and outside of a pandemic for what founding a company is really like. It's definitely new to the both of us, but I think that's all part of the fun as well, is to grow and learn along this journey.

Yeah, I mean, I think Martin hit it up the nail on the head. It's like a lot of big decisions in your life. You don't really know whether you made the right decision until a little bit later, but you know that it's a big one and you really have to pass on way up like what the other side of making that decision would look like. You know, I mean, I'm in my early 30s. There's at least once or twice where I thought, you know, maybe this is the right idea to work on. Maybe not working at a large company is the right thing to do. But none of them definitely felt anywhere near as obvious until taking something like M3 and really productizing it kind of fell in front of us when we realized so many other people were looking for an easy solution to kind of expanding scope of their monitoring problems. That was kind of creeping along as complexity and these systems grew. The other thing I'd say would be that at these companies, yeah, you get to work on some really exciting stuff and you're giving the time and space space to do it. But then having said that, on the infrastructure side, you don't really get that product side of it. A lot of the time it's like, solve the problem okay. There's some rough edges here and there and sure you have these runbooks to do weird things with the infrastructure if you actually need to achieve it. But that was always a frustration for me working on these problems inside larger companies. You know, I really liked the product side of it. Like the delivering the polish was a lot of some of the things that attracted me to engineering in the first place. And so that was another huge one for me is it's like right place, right time, big opportunity. Because this is a real problem that we can see very systemically in the industry, but also we get to solve it in a way that has that, that level of polish. And then in terms of the second question as to expectations versus reality, I, yeah, as Martin said, I think, you know, just going in with no expectations definitely works well. And I think, you know, every person's experience here is going to be unique. I think having a partner like Martin really helps. Like, you know, the, a co founder that you can just trust matters a lot. And doing this startup during the pandemic I think is working from opposite sides of the country. I don't think it would have, would have worked as like the way it did anywhere near as functional if we couldn't just, you know, have like a 30 minute Zoom meeting and then just feel confident that the other person on the other side of that phone who's halfway across the country is going to be able to go and deal with that, that issue independently and you're not going to have to. Second question. It goes a huge, huge way. So you know, a lot of the time when my friends ask me about them starting their own companies, it's not like go find the perfect person who knows that problem domain that you're looking to solve an idea. And it's about go find someone who you can trust and just operate and execute really well with because that's going to matter more than finding like a 10 or 20 year veteran in the problem space that you're trying to solve.

I think these are both great points, guys. My partner John Lee used to say starting a company is not an intellectual decision, it's an emotional one. And you know, you start the company when you guys keep becoming obsessed with the problem, the technology or the space, not any intersection of, you know, market size or opportunity. And I think the second point, Martin and Rob, as you guys talked about, the trust of your team co founders is a huge part because I think the one advantage startups do have is moving fast compared to incumbents and other companies. You can't move fast if you don't have trust. I always say optimize your co founder for trust and optimize your first few hires on the team for trust too because that's how you guys move fast, maybe taking that to the next step. So you guys took the plunge, started Chronosphere kind of summer of 2019 and obviously went out to start the company, raise money. You probably heard a lot about raising money from VCs and working venture capitalists. What was that experience like for you guys?

Yeah, again, as first time founders, I don't know if we had many expectations going into it. Definitely no firsthand experience. So working with VC is definitely new for the both of us. I think, at least for me. I was expecting somebody mostly to hold us accountable and that's definitely part of the role for sure. But I think there's so much more, at least for me. I wasn't really expecting. Some wise folks told us at the beginning of this to select our investors very carefully as you're really entering into a 10 year commitment with some person and building the company with them together. I think we ended up getting very lucky with our choice of investors and in particular yourself, Jerry, because I really feel like you actually partner of the team and help out across the company with a lot of different things. Not just, you know, us having a check in every six weeks or two months at a board meeting. And something I noticed the other day actually is that I only ever actually come to you with the bad news in the areas that we need help with. We never actually come to you with the good news. And we only tell you that stuff at the board meeting, which I think to me is a pretty good sign.

I want to echo that. A lot of it is down to all the advice we got was, yeah, don't try to make a choice with who to work with based on pretty much anything except yeah, is this someone who's going to work well with you and your unique style? And I think like every person has to go through that unique selection criteria when they evaluate who they're going to work with. But it should be about their personality foremost because that's going to determine how you can execute on day to day, week to week, month to month issues with them. And then secondarily, what outside of your domain expertise do they kind of have a mapping to and how helpful is that going to be?

Yeah, guys, thank you for those nice words. It's been amazing and wonderful partnering with the two of you and the entire Chronosphere team the past year and a half. And I think I personally at Greylock entirely looking forward to the next 10 years working with the two of you and the team and helping you guys build something special. I talk to a lot of other VCs and founders. There's such a thing as founder market, fit the right founders for the right market. But I think there's also founder, vc, founder, investor fit. And that there's not every investor VC is a perfect master, every founder. And I'm not for everybody and vice versa. I think you guys did something that I think doesn't happen as much anymore. And I think Rob just alluded to the process that we spent several months together spending time talking to each other honestly about the company, how to work together before you guys actually made a decision to raise money, which is rare. I think oftentimes you see these three days to three week processes to raise money. We were able to spend several months. I flew out to New York a couple times, Seattle a couple times, we had a couple calls and it was just wonderful to know what it'd be like to work together. I like to say we're not going to agree on everything, but we'll agree on a process to get there. So, you know, I'm going to hopefully raise a toast to you guys in person soon when we can all kind of meet for the next board meeting and toast for the next year for a year and a half of Chronosphere. But maybe on that note, the last question of the two of you now, you guys raised a series B. The company is accelerating on all aspects from sales, development, product. What do you guys see for yourselves, Chronosphere and the market in the year 2021 and beyond, what milestones you guys hope to achieve and what do you think the market the industry is going to be thinking about or talking about for the next year?

Yeah, I think 2021 for us will be hopefully even bigger than 2020. I think even from a market and industry perspective, we're seeing sort of more validation on this shift to cloud native and you see it with, you know, AWS also providing a hosted Prometheus solution in this space as well. So I think there's been a lot of validation in the broader market for our thesis, which is great. I think the focus for us and the company would really be, you know, the past year we've really been spending the time on building the right product and the next year the folks will shift a little bit to our go to market and reaching as many companies out there as possible over the next year. So hopefully a even larger and faster growth year for us next year.

Rob Martin, thank you so much for spending the time today. I really enjoyed this conversation, like I've enjoyed every conversation with the two of you. Thanks for sharing the story about Chronosphere and the founding the company with our audience. And here's to 2021.

Thank you for having us, Jerry. It's been great to chat, as always. And, yeah, looking forward to a bigger and better 2021, for sure.

Yeah. And plus one to that. Thanks again. This has been great.