theCUBE with Martin Mao: helping engineers, community, and customers  

What would KubeCon be without our annual banter session in theCUBE studio? Last year our co-founder and CEO, Martin Mao, and investor Jerry Chen from Greylock Partners (and apparently one of theCUBE’s most well attended guests!) stopped by. This year, at KubeCon ’22, it was Jeff who joined Martin in sitting down with theCUBE’s Savannah Peterson and John Furrier to catch up on new platform features, eliminating engineering burnout, giving back to open source community, and an introduction to some of our latest customers (hint: Robinhood), and more.

Savannah Peterson: I noticed right away that you have raised a mammoth $200 million Series C round of funding. Where’s the company at?

Martin Mao: That is correct. In fact, we were just talking about raising that $200M Series C and how we became a unicorn a year ago at KubeCon 2021. At the time we were about 80 employees. Since then, we’ve tripled our headcount and attained a hundred percent customer retention, which is always a great thing to have as a SaaS platform. And ninety percent of our customers are using more of the service, and therefore paying more for the service. Those are great signs for us and I think it shows that we’re doing something right.

John:  Last time you were on theCUBE, we talked about how observability is about having the right data. And now you just launched a new release of your cloud native observability platform. What’s new in the platform?

Martin: You bring up a great point. It’s not just observability, but overall, data is exploding. Which brings up a few issues: one is, can your platform even handle the explosion of data? Then, can it control it over time and make sure that as your business grows, the data doesn’t continue to explode at the same time? And then for the end users, can they make sense of all this data? Because what’s the point of having data if end users can’t make sense of it? Our product announcement here at KubeCon is about addressing all three of these components. I’ll hand the platform questions over to our Global Head of Product, Jeff.

John: Jeff, you run product, you have the keys to the kingdom. What makes your platform a great observability product?

Jeff: The keystone of what we do that’s different is helping you control the data. So not only is there an infinite amount of data, but these systems are getting more and more complicated. A lot of what we do is help you understand the utility of the telemetry so you can optimize for keeping and storing and paying for the data that’s actually helpful as opposed to keeping the data that isn’t.

John: What’s the benefit now with observability? With all the noise out in the marketplace, there’s been a shift over the past couple of years to cloud native at scale, and you’re seeing a lot more automation — almost a setup to support growth of more cloud application development. We just had Docker’s CEO on earlier today and he stated there have been more applications deployed in the past year than in the history of open source. So with more and more apps deployed and the data that’s generated along with that, what’s the key to observability right now that’s going to separate the winners from the losers?

Martin: Not only are there more applications being deployed, but there are smaller and smaller applications being deployed, mostly on containers. So, the key is asking if your system can handle this data explosion. Also, APM solutions have been around for a very long time and those were really introspecting into an application. These days what’s more important is asking: how is your application interfacing with every other application in your distributed architecture? The use case is different.

And then, to what Jeff was saying, once the data is there, the end user needs the ability to make sense of it. We always think about technology changes. We forget that the end users are different now. We used to have the IT operations teams operating everything and the developers would write the application — just throw it over the wall.

These days developers have to actually operate this app in production. You can imagine the average developer may not have operated in production before, so they need to pick up a new skill set and use new tooling in order to do that.

John Furrier: So they’re not really infrastructure builders, they’re app developers.

Jeff Cobb: Exactly. And that’s what a lot of the new functionality we introduced here at the show is all about — helping developers who build software by day and are on-call by night get the context they need.

One of our features, called Collections, gives you the right context by connecting you with the piece of the system where the problem is. So instead of wading through a sea of data, you’re already in the immediate vicinity of where the problem is located.

Savannah: You seem to approach cloud native observability with the goal of eliminating engineering burnout. You’re not just designing for when everything goes right. You need to be prepared for when everything goes wrong — that poor lonely individual in the middle of the night has a tough job.

Martin: There are so many more things that have been piled on top of the developer, in addition to actually creating the application. Observably is one of those key things you need to in your job and we are making that easier. They aren’t observability experts.

John: Some have said automation can play a role here. So where do you guys weigh in on the automation wave? What’s the reality, what’s actually happening?

Martin: You hear a lot about AIOps and MLOps  … I don’t know if I really believe a machine can self-heal itself. But I think automation is key because there are a lot of repeatable tasks in a lot of what you’re doing. So if you detect something has gone wrong, and you’ve seen it before, you know what the fix is. In that sense automation is key to helping a lot with burnout.

Jeff: One of our new features, Query Accelerator, is actually a form of automation. The problem is you have a mountain of data and you need to query it. That’s a high burden on any developer. You need to get the data to actually inform the specific problem you’re trying to solve. The burden on the developer in that situation is really high. With Query Accelerator — you tell us what you want, we will figure out how to get it for you efficiently. That’s the kind of automation that we’re focused on.

Savannah: You sounds so community forward. You clearly lead with a lot of empathy, both of you, in putting yourself in the mind of the developer. What’s that like for you from a product development standpoint?

Jeff: Case in point: I run product at Chronosphere, which means I have a lot of product managers who work for me and I can figure out what a day in their life is really like — what the job is really like, what’s easy, what’s hard.

That’s what Chronosphere tries to optimize for.

Martin: Speaking to Savannah’s point about community, we are actively giving back to the open source community. Here at the show we announced that we partnered with Julius Volz, co-founder of Prometheus and creator of PromLens, to donate PromLens to the Prometheus organization. PromLens is a tool for building, understanding, and visualizing PromQL queries and helps developers understand how to create queries in a much more efficient way. We’ve been using PromLens in our product for a long time, but we decided, hey, let’s help the broader community of developers out there have a much easier time creating these queries as well.

Savannah: It’s not surprising that you’ve added some new exciting customers to the roster. Do you want to tell the audience who they might be?

Martin: There are a few big names over the past year we’re pretty excited about. I think everybody knows about Snapchat, but another one is our Prometheus Day keynote co-presenter, RobinHood. These are very large, tech-forward companies that have completed their migrations to cloud native or are well on their way to cloud native.

We like helping those customers. We also like helping startups because they start off in the cloud native world — if you’re going to build a business today, you’re going to use Kubernetes from day one.

Interestingly, we are also seeing more and more traditional enterprises starting to adopt cloud native at scale, and now they’re running into the same problems with observability.

Savannah: I would imagine it’s a bit of a different pace when you’re working with some of those transforming companies versus those startups that are just getting rolling.

Martin: If you’re a startup, there’s no baggage, no legacy. You’re just starting brand new. If you’re a large enterprise, you have to really think about, okay, well how do I get my active business moved over?

John: How do you guys see the whole cloud native scale moving with the hyperscalers? You’ve got a lot of multi-cloud conversations. We call it supercloud in our narrative.

Martin: A lot of companies are trying to de-risk and hedge their bets on a single cloud provider. Observability is a great way to do that. The cloud providers have their observability or monitoring tooling, but it’s just optimized for their own cloud services. If you’re trying to run your custom applications or taking a multi-cloud approach, you really can’t use one cloud provider’s solution to solve that problem.

John: Does Chronosphere see itself as that unifying layer?

Martin: Yes, in the sense of being agnostic to each of the cloud providers. It’s why we like to understand where our customers run, and then try to run their observability stack on a different cloud provider. We use the cloud ourselves. We’re not running our own data centers, but everybody has a common dependency on their cloud provider. If AWS (US-EAST-1) region goes down — and I hate to call them out — that means half the internet goes down with it. And that’s the time that you actually need observability. We try to find out where our customers run and then we try to actually run them elsewhere.

There is much more to glean from the conversation between these four experts. Catch the whole discussion here: