Jeff Cobb, Chronosphere | KubeCon + CloudNativeCon NA 2022
Jeff Cobb, head of product at Chronosphere, joins Mitch Ashley at KubeCon to discuss the cloud-native observability company, which solves observability problems by focusing on the availability and reliability of digital delivery systems.
Transcript
This is Textron TV. Hey, welcome back. We're kubecon here in Detroit coupon 2022 North America Mitch Ashley CTO with Textron group in also principal with texturung research.
So we've got a great lineup of folks and speaking of great lineups. I'm joined by Jeff Cobb. Jeff is head of product and with chronosphere.
So I want to I know you got some announcements we want to get right to that but for folks that might not know coronaster tell them about well first tell them about yourself and also going to sphere so I'm Jeff Kopp. I run product from us here furnace fear is a cloud native observability company, so we focus on Solving observability problems just really in the interest of availability and reliability of digital Delivery Systems. So if you're running a big very large scale digital delivery system, like doordash you need observability tools to keep that system working to know whether it's working solve problems when problems show up.
So that's what we do. That's what cloud native observability is. So you're making sure we get warm food from doordash because they're on top of what's going on, right?
They're making sure you get one. Okay. All right.
They know you're helping them make sure okay. That's right. We just say it.
Okay, so kubecon, you know, there's always a lot of good announcements and you've got some tell us a little bit about what's happening. Yeah, so we have some new releases that we're that we're announcing here at the show. The problem that we're really focused on is is this Cloud native observability problem, right which is a result of a technology Trend toward microservices as a software architecture to build these systems and Ops as an organizational approach to deal with them, right?
As the world is figured out the best way to build these systems. They realized oh, we've we've created something that works better for meeting our business needs right? We can modify the system faster if we build it this way if we build it with microservices and we deploy it on top of kubernetes.
We can work with a distributed development team, right? So we've got a lot of little teams and a lot of little places we can update the system all the time. So we get the business outcomes we want.
Problem is we ended up making a much more complex software architecture as a result and it's hard to understand it and it's hard to keep it working. That's where devops came from is. What what everyone realizes they did this for a while is that?
The skills you need to operate one of these systems turn out to be the same as the skills. You need to build it. So you can't do what people used to do you used to have a development team and they would build it and an operations team and they would run it throw it over the wall and all day and that stopped working.
Right? So devops is a result of that. That's a good thing.
So now you're getting the outcomes you want because the developers who understand the system are the ones who are keeping it working. The problem is That squeezes them now they got twice as many responsibilities as they did before. Now they're not only responsible for building it but they're keeping it working.
They're on call their firefighting and there's a bunch of problems when you're in that situation. So your developer. You're on call one of the side effects of these really big cloud native microservices architectures.
They're a lot more complicated. There's a lot more Telemetry you need in Parts. Yeah to understand what's going on.
So if you're on call and you get lucky, And the incident is in the part of the system that you work on you're in good shape because you understand what's going on if it's somewhere else. You got a problem. There's a monstrous amount of data.
Just totally overwhelming you. Where do you start you've got the skill to solve the problem, but you don't have the context to figure out how to navigate all of the data that's available to you. So that's where that's what we focus on and that's what the the new release is really optimized for is helping Developers.
Navigate that monsterous amount of data to give them the context to answer the question. Where do I start? How do I figure this out?
Right? That's that's where our that's what our our new our new feature functionality is focused. Excellent.
Well, it seems like when we adopt a new technology new approach things like that. I mean we just because we can build a cloud-native or microservices architecture-based application doesn't mean we know how to care and feed that's right diagnosed and operate that takes a while. It's kind of like, you know getting a sports car when used to drive in a pickup truck.
It's it they're different right? They got four wheels engines, but that's right. They take different kind of care and feeding.
And it seems like having that place to start like help me jump into the right place with the right information right of context. Not only helps you with solving whatever issue might be coming up or you know, working our performance challenge, whatever it might be but also learning how the system behaves and operates better. That's right, because you're you're absorbing that too right as well as your kind of diving into a certain area.
Yeah, and that's one of the things we hear all the time from people who try to keep these systems working is I know my part of it the rest of it is kind of a mystery. There's no one person who has the whole system in their heads, right? So we do a couple things about that.
One of the problems is there's just a tremendous amount of data. So you need a lot of raw scale to be able to get all of the raw data to begin with in front of sure. Does that secondly?
You need to be able to pick and choose you need to actually really make sure you're capturing the stuff that's important and shedding the stuff that isn't important. So we have a lot of telemetry control features that are there to help teams. Make sure that they're only storing and only paying for the Telemetry that's really going to help them solve problems.
And then the new stuff that we're introducing this week starts with a feature called collections, which is the contextual Focus. It's the thing that when you're on call and an alert goes off, it's the thing that tells you where to start instead of well, there's 250 million metrics in this system and 1400 dashboards. Here's a pair of tweezers.
Where should you start there's the needle in there somewhere, right it navigates you to the right place. It says here's what the people who've worked on problems. Like this before have learned and captured and it takes you to the right place and orients you so that out of all of that information your concentrating on the small subset of the data that's actually going to happen to help you.
That's what I'm going to ask you about is how do you know how to point someone to that place? Is it based on the date itself? It's based on past experiences knowledge of kubernetes working with other customers.
They're kind of some leading indicators. It's based on both of those things and it's also based on your own experience solving previous problems and what the people that you work with have captured about the things they learned so that you can take advantage of that. So it's all of those things.
That's what that's what our collections feature helps you with. The other stuff that we're adding is we've already got a lot of features that are built to help you control the Avalanche of data right turns out A lot of that data is being generated sort of speculatively because we're not really sure what we're going to need and we're crossing our fingers we're gonna have the right stuff but you're paying for a lot of it. That isn't very helpful.
So we have a we have a control a data Telemetry control set of features that help you understand. What's useful. And only keep and pay for that stuff.
What we're adding to that is a quota management feature. The problem turns out to be the the central team the team that sits in the middle. Usually what we generally see is there's a lot of developers who do this and there's a small team that helps them and supports them that small Central team.
Their responsible for paying the bill for the tools and teaching everybody how to use them. They don't know whether this data point or that data point is important, but they do know this service is important that service is less important so they can allocate budget they can say you get a quarter of the budget you get a tenth of the budget and then delegate down to the local people who work in the teams the decisions about which data to keep in which data not to keep that's what our quote is feature makes possible the quotas cool. How about the SRE folks?
It's a Hot Topic, you know everybody oh for sure either wanting to build that function and their team or getting folks that have done that before building that out. Yeah. They also have different needs too.
Right because they may be involved in triage, but they may also be working on performance issues or reliability, you know things that we've seen happen in the past could do to help the yeah what we hear what we hear frequently from srees is very much that I have a broad domain that I care about because I'm doing something like performance optimization. I need to touch lots of areas of the system and that's hard because it's hard to be an expert in all. So they have that same contextualization problem.
I understand that I saw performance degradation and now I'm chasing it. I need to get in contact. I need to be armed for that area of the system.
So I turn to the collection that teaches me about the login service that I'm trying to tune or the checkout service that I'm trying to team. Yeah, I would imagine and there's so much we can learn by each Time We Touch the system too, right not just for ourselves but sharing with with others. Talk a little bit about I mean, it sounds like you're sort of starting Cloud native with observability.
You're not coming from a log aggregation background, right? I mean, that's right you built product and it as Cloud native. Yep.
What do you think would just what is the difference starting at that place rather than maybe someone who's been doing log aggregation for five or ten or more years? That's exactly right that chronosphere was was born out of cloud native observability challenges and what we see is that the difficulties in monitoring and understanding and caring for a system that's built this way out of sometimes thousands of microservices each of which is small and simple and isolation, but that communicate in a complicated way. The Design Center for that it's just different from the way systems used to work.
And so tools that were built for a design center of monoliths where there's a lot of internal complexity and we need to crack the thing open and x-ray it and show you its innards. They don't help as much on microservices environments where the individual things. They're very simple they do one thing it's the way that everything is woven together that makes it complicated.
That's what produces the Avalanche of telemetry and the need to navigate it and control it. Very good. Well so can folks get like a free account or cloud account or that open source, or how do people get a hold of Runners?
Here's a SAS app. So the way you interact with it is you go to our website, and there's a path there that will get you to a demo that you can take a look at how the software works. Okay, very cool.
Well, congratulations on the new release. I also want to mention you have a an event an online learning event webinar. Yeah on November 8th.
I forget who's on it. I may be doing it. I'm not sure, but, you know, we're also busy these days, but we'll get a chance to dive into this more and talk about chronosphere and some of the challenges the people have excellent.
Well, we're very much looking forward to to that event. I'll be a lot of fun Cloud native. It's a great topic to to explore and learn from so well.
Thank you Jeff. Appreciate you stopping by and as I mentioned good luck with the show and kind of keep us up today. Hope we have you back again soon.
Okay. Thanks very much, Jeff Cobb Jeff hit a product with chronosphere. So we'll be right back with another great interview Jeff.
Thanks for joining us. We'll see you soon.
