On this episode of DevOps Dialogues: Insights & Innovations, I am joined by Tucker Callaway, CEO of Mezmo, for a discussion on Mezmo Data Management, Observability, and getting real value out of telemetry data.
Our conversation covers:
- What Mezmo Data Management is.
- The fact that 52% of organizations use 6 to 15 different tools in observability.
- Why DevOps or application developers are creating logging capabilities.
These topics reflect ongoing discussions, challenges, and innovations within the DevOps community.
Watch the video below, check out previous episodes here, and be sure to subscribe to our YouTube channel, so you never miss an episode.
Listen to the audio here:
Or grab the audio on your favorite audio platform below:
Disclosure: The Futurum Group is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this webcast. The author does not hold any equity positions with any company mentioned in this webcast.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of The Futurum Group as a whole.
Transcript:
Paul Nashawaty: Hello, and welcome to this edition of DevOps Dialogues. My name is Paul Nashawaty. I’m the Practice Lead for the App Dev Practice at The Futurum Group, and I’m joined today by Tucker Callaway. Tucker, would you like to introduce yourself?
Tucker Callaway: Yeah. Hi, my name is Tucker Callaway. I’m the CEO of Mezmo, and thanks for having me here.
Paul Nashawaty: Excellent. I’m glad you came and joined us today on this session. You know, there is a lot happening in the data management space, observability space, and a lot of traffic. What’s Mezmo’s claim to fame?
Tucker Callaway: Our claim to fame is we really focus on helping people understand and get more value out of their telemetry data. I think that is exactly where we’re focused.
Paul Nashawaty: Well, getting value out of data is key, because data is the lifeline of the business. And when we talk about it from a DevOps perspective as we’re on this DevOps dialogue session, one of the things I found in our most recent observability research is we found that 52% of the respondents indicated that they’re using 6 to 15 different tools in observability. What does that mean?
Tucker Callaway: It means there’s a lot of stuff out there. I saw the same or similar report, and I’ve seen that a number of times, and six seems to be that marker of the minimum. And the thing we always think about as it relates to that is that means that there’s most likely six different agents, six different collection mechanisms, six different data stores, six different analysis capabilities that are out there.
And the bifurcation and the segmentation and data is just incredible that happens with that. And there might not be all, it might not happen six different times, but there’s a tremendous amount of overlap. And the enterprise complexity that’s created out of that is massive. The management overhead, the lack of the ability to get business insights is tough.
Paul Nashawaty: Yeah, yeah. No, it makes sense. I used to kind of joke around when we talk about observability, I said the observability people really that their role was basically storage managers. They’d store, collect a bunch of information, collect logs. When we look at understanding this telemetry data, how do you understand these logs and break through all this noise?
Tucker Callaway: It’s real funny, real quick, that you said that though, because one of the things I say internally a lot is that a lot of times log management is just like French for storage.
Paul Nashawaty: Makes sense, right?
Tucker Callaway: Yeah, it’s really fancy, elegant in storage, at the end of the day. But yeah, so as we’ve embarked on this journey with the attempt to help people optimize and get more value out of their telemetry data, we found, this was surprising at first, early in our journey, and so obvious now, that the fundamental problem is that people don’t understand their data. They don’t understand where it’s coming from, where it’s going to.
And there’s some really great standards evolving out there today like OpenTelemetry and OTel, and super supportive of that in all things. But that doesn’t fundamentally answer the question of do you understand it, can you profile it and can you categorize it, and can you make decisions on what effectively to do, and how to manage that across an entire enterprise.
Paul Nashawaty: Is it a skill gap issue? Is it just a persona? Is it the wrong people doing the wrong job type of thing? Why-
Tucker Callaway: Yeah, good question, actually. So I looked at it from a different angle. I think that, well, I might be a little biased, but I think to some extent it’s a capability problem in the industry. I think there’s plenty of skills, especially in this particular space, and this group of people, SREs or platform engineers, are known for their ability to pick up whatever you throw at them. Give them application monitoring, give them system monitoring, give them traces, give them all of it. They take everything that gets thrown their way. So I look at it as a capability gap. And I think specifically, it’s a data engineering problem, but it’s a data engineering problem applied to a new type of data that your typical data engineering tools don’t address today.
Paul Nashawaty: Right. Okay. So that makes sense. So is it the applications that are trying to understand the data? I’m really trying to understand it from the perspective of who from our audience here should be concerned? Who should be thinking about this going, “Well, okay, I’m a DevOps person, I’m a SRE, I’m a platform engineering team. I’m a developer. I need to create this stuff. I know I have a bunch of insights coming in or some logs coming in. I don’t know what to do with it. It’s a bunch of information that’s sitting there.” Where do they go from here?
Tucker Callaway: So the question of… You listed a bunch of roles and asked who should be concerned, and my answer would be yes.
Paul Nashawaty: Yes.
Tucker Callaway: I think there’s different sides of the problem. On the one hand, you’ve got a number of DevOps engineers or application developers that are creating logging capabilities because they need the visibility at a point in time. And that point in time isn’t all the time, but when that point in time comes, it’s super important. The other side, you’ve got a platform engineer or like an SRE team who doesn’t understand the application as well, or maybe they don’t understand those logs and why they’re being created as well, but they have to manage the operational overhead.
So there’s a push and pull in between those two things. There’s a natural push and pull, and on the other side it’s like, what value am I getting from the data and how much is it costing me? But that decision is often made with the platform engineering team, but at times get made on behalf of the developer, or on behalf of the DevOps team. And so when that incident happens, then you want that information, it’s not available. And when you have that problem, the systems tend to be down longer than you would want them to be.
Paul Nashawaty: Right, right. Yeah, no, that makes sense. The thing that often comes up is, in this maturity of, call it observability and such, but in the maturity in organizations, there are organizations that are not mature at all, and there are organizations that are very mature, but the bell curve is somewhere in the middle. And so when you do that alerting and monitoring and when you have the logging, the tracing and that occurs, and then there’s actionable insights. What does actionable insights mean to Mezmo?
Tucker Callaway: Yeah, that’s a good question. I’m going to give you a partially a personal answer too. So I’ve actually been in monitoring and observability for like 25 years, which is kind of fascinating. I feel like this is my third or fourth or something.
Paul Nashawaty: So you’re an authority in the space, for sure.
Tucker Callaway: Yeah. Yeah. I don’t know if authority is right, but I definitely have been in and around it working with customers, implementing it. And I think the challenge has fundamentally always been a data problem. Most things are. But the challenge has been what do I instrument and what do I not instrument, and do I know the right things to instrument or not instrument? Making those decisions can be really challenging. There’s a lot of deep trade-offs you have to make. Am I going to instrument this system or not? Am I going to follow this metric or not follow this metric? If I’m going to look at it from an end user perspective, if I’m doing end user type monitoring, do I actually have the fidelity I need to trace back and solve the problem? Is it a valid user?
So we have all these trade-offs in terms of what do you instrument? What’s the cost of that instrumentation, how many tools do I need, and all those things. And so back to the question of what is an actionable insight and what does that mean to Mezmo? We just had a conversation earlier about the response of pipelines. I think that’s going to depend on the context. And so you have to have the ability to dynamically change the flow of data and information. Either you got to collect everything, which isn’t an option, or you have to be able to make decisions at points in time. So there’s clearly things that observability tools do well today. And user monitoring, all that stuff needs to continue to flow through and give that top level.
But once you start to dive into an incident, I believe that you need to be able to dynamically change the data that’s flowing so you get the actual insight based on the context that you understand about the system and its performance today. That’s one answer. And then the other side of that too is I actually think that there’s a tremendous amount of rich business data that sits in these telemetry data streams. And I think there’s a real opportunity in the industry to harness that more, to harvest that and actually turn that into business context, not just technical context, but turn it into business context that allows us to answer maybe some more critical business questions out of the observability-type data.
Paul Nashawaty: That makes sense. But when we think about the data sets and we think about anomaly detection you mentioned, what pieces to think about to collect versus if you collect everything versus collecting certain pieces. How do you know what’s important?
Tucker Callaway: It’s a good question. What we’ve spent a lot of time on is maybe the reverse of that question, which is how do I know what’s not important?
Paul Nashawaty: That’s fair.
Tucker Callaway: You know what I mean? Because with changing context, it’s always hard to know what’s going to be important at some future state. And so if we look at it from the standpoint of what do I know is factually noise? What is something that’s just repeating tens and thousands of millions of times that I can turn that thing into a metric? So I take something that maybe this really long log line, I can turn it into a single metric, or what can I aggregate where I take many of those and turn it into one?
Or what just repeats that I can truncate every time? What are sources that maybe just don’t matter that don’t have any interesting information? I’d have to think about that one a little bit more. But I think a lot of where our customers are focused is actually looking for things that don’t matter so that you can keep those richer things that may matter.
Paul Nashawaty: Yeah, and I think from what I heard you say is we wouldn’t be in IT if we didn’t say it depends.
Tucker Callaway: Yeah, yeah, yeah, fair enough. Yeah. Fair enough.
Paul Nashawaty: I mean it really does depend on what is your business, what do you care about, what’s interesting to your business? And when you look at maturity, we started this conversation with maturity. When looking at maturity, that also means application maturity.
Tucker Callaway: It does.
Paul Nashawaty: And where that lives and where the application lives within its own life cycle, right? The thought around the piece that comes to mind as well as the convergence of taking this data and taking these, what you do realize is actionable insights, and then applying it across other disciplines within in the organization such as security. How does that play into Mezmo’s vision?
Tucker Callaway: Yeah, I think that, well, I see, as you alluded to, I see Mezmo as a data company, not more than observability company or a DevOps company or a security company, or even ultimately people ask questions about AI, of course. So I think it’s really about applying some of the techniques that we’ve seen in general business data space to telemetry data. And I think when you do that, which is really focusing on how do I gain a better understanding of my data, how do I optimize my data and how do I respond to the changing context, that in that, we’re equally solving observability challenges as well as security challenges, and ultimately AI challenges too, I believe.
Paul Nashawaty: So where do we see Mezmo going?
Tucker Callaway: I think we’ll stay focused on the data. I think it’s really important we stay focused on the data and actionable insights out of that data. So I do believe that there are many things that we can do based on our preferred access to the data as the streams come through, within some reasonable buffers and windows, that give us the ability to provide insights into very unique things across observability and cybersecurity.
And then I also think that there’s some great things that will always happen at the destination, and we don’t need to do that. But what we want to do is we want to give you those insights sooner, cheaper, better, of course, and help people really own their telemetry data. So at the end of the day, they feel this responsibility, that they understand it, they’re in control of it, they can send it to the right destinations, and they can provide it to the right consumers in their environment.
Paul Nashawaty: That makes a lot of sense. I like where you were going with that. It’s customer choice. Figure out where they want to go. There’s this element of the tool sets, the tech stack and where it’s going. I like the convergence of where you’re going, the messaging. But one of the things I was also thinking about is in our briefing that we had, we were talking about your use cases. Can you double click down a little bit on the use cases and where somebody wants to get started right away? What would you recommend they do?
Tucker Callaway: Yeah. I think the two most tangible things to do right away is to profile your data so that you understand what it is, and then that’s a very easy means to drive cost reduction, which is basically increasing the fidelity of the data so there’s more a better single-noise ratio at the end of the day. And the second is, while you’re doing that profiling, make sure that you handle all the compliance. That’s the first step. That’s the first step in the maturity curve of I want to get control.
Once you do that, then the next step we see people take is start to think about what is the latent value? What are those actual insights I want to get out of this data? Which in many cases is a very specific question to that enterprise. But then you can start to take some of the aggregation and business insight-type capabilities that we have to present that data, whether it be in an observability system or any downstream system. So we see people doing things like grabbing order information, grabbing ticket check-ins, grabbing failure presence or absence alerts, and all those things can inform a tremendous amount of business context that all sits inside of this telemetry data.
Paul Nashawaty: No, it’s very true, and I think it’s an evolution.
Tucker Callaway: Yeah.
Paul Nashawaty: It’s going to evolve. Businesses and organizations are going to be dynamic and fluid and try to figure out how they’re going to use this. I know we’re kind of coming up on our time here. What would you recommend to the audience here if they wanted to get started with Mezmo? How do they work with you? What’s the best way to move forward and get started?
Tucker Callaway: Thanks for asking.
Paul Nashawaty: Yeah, of course.
Tucker Callaway: Yeah. So I think the best thing to do is come to our website, mezmo.com, start a trial, reach out, contact us. One of the most valuable things we can do for you is, no charge or anything like that, but just help you profile your data, which allows you to easily tap into a source, get a full inventory of what’s coming through, and it will make recommendations to you in terms of what reductions you can expect and what insights you can gain from that data.
Paul Nashawaty: Well, it sounds like this is really just the tip of the iceberg, right? There’s just a lot to consider and a lot to think about here. Tucker, I want to thank you for your time today. I want to thank you for your insights and your perspective. I also want to thank the audience for attending our session today, and if they want to learn more, go to mezmo.com, as well as go to futurumgroup.com to learn more about our research and our information. Thank you, and have a great day.
Other insights from The Futurum Group:
Mezmo: Telemetry Data Management for Observability and Security
Mezmo Presents at AppDev Field Day 1
Mezmo at AppDev Field Day Describes Controlling Your Telemetry Data with Confidence
Mezmo Telemetry Pipeline – Aggregate, Transform, Distribute – Gestalt IT
Author Information
At The Futurum Group, Paul Nashawaty, Practice Leader and Lead Principal Analyst, specializes in application modernization across build, release and operations. With a wealth of expertise in digital transformation initiatives spanning front-end and back-end systems, he also possesses comprehensive knowledge of the underlying infrastructure ecosystem crucial for supporting modernization endeavors. With over 25 years of experience, Paul has a proven track record in implementing effective go-to-market strategies, including the identification of new market channels, the growth and cultivation of partner ecosystems, and the successful execution of strategic plans resulting in positive business outcomes for his clients.
