 Hi, this is your Saptan Bhatia and welcome to our newsroom and today we have with us once again Kit Merker, chief growth officer at Noble 9. Kit, it's good to have you on the show. Great to be back. Nice to see you. Yeah, and today we're going to talk about the new feature that you folks announced this week, Service Level Analyzer. Talk a bit about the announcement. Yeah, we announced a new capability in Noble 9, which is Service Level Analyzer, as you said. And what it's really doing is taking the service level data that you already have and helping you set good SLOs on that service level objectives on that data. Can you go a bit deeper into it and also talk about what exactly is Service Level Analyzer? Yeah, so if you kind of start from the problem that we're trying to solve here, it's when you are trying to define service level objectives, which are basically reliability or performance targets for your service, one of the challenges people have is, well, what's a good SLO? Should it be 99% or 99.9% or 99.95% these kinds of questions? And that's kind of a simplistic way of looking at it, like how many nines do I need? And what we found is that people need a little bit of help and we can figure out, not necessarily like magic wand, but we can point you at the historical data and do some statistical analysis on it and present to you what if scenarios about setting different SLOs. So you say, okay, what if I had said I wanted a three nines SLO on maybe 50 milliseconds and what Novel 9 Service Level Analyzer will do is present, here's where your error budgets would have been, here's where you would have violated the SLO, here's where you've been alerted and give you that kind of historical view. And based on that, you can use that as a really smart starting point so that you can just set the SLO based on these different what if scenarios. And that helps you tune the SLO without having to do a lot of analysis yourself. It gets you started much, much faster. And we had a number of customers in the beta that I think really benefited from this tool. It helps them move a lot faster. It helps them get up and running very quickly. So it's really about setting reasonable objectives for reliability and performance across your service using historical data. That's what it's all about. Can you talk about the evolution of this project, this feature? Because when we look at, we have had so many discussions around SLOs so that we can also understand, hey, this is where the market is going and that's where Novel 9 is kind of evolving its solutions to help customers wherever they are in their journey. So when we first started Novel 9 back in 2019, a big part of our vision was to build a general purpose service level objective platform. We saw a gap in the market because we all had experienced the joy and wonder of being inside of the Google machine and the amazing reliability and the engineering reliability that is built there. And what has happened over the last few years as we've talked to customers and gotten adoption and built community and other things like that is we figured out that you got to make it really accessible for people. Everybody wants, in theory, to say, oh, we want five nines on everything. And it's actually not even desirable. In fact, for many services, it's incredibly expensive to try to hit that number. And three nines or two and a half nines is more reasonable in a lot of cases. And also, if you measure in different places, you can tune your SLOs and get a more fine-grained view of the world. So while companies are struggling to maintain and earn trust with their customers and we've seen a number of reliability outages and things like that in the news and I think everybody wants to avoid being that person, reliability engineering is an important part of delivering service. It's funny, I was thinking about this actually the other day because people are asking about the Henry Ford faster horses. And it's interesting because people needed cars but they actually really needed reliable cars. And I think you can credit Henry Ford in some ways with building reliability into the auto manufacturing process and in some ways a more significant contribution to Automotion or Automotion Award to automobiles than the actual car itself. It's kind of easy to imagine a car. It's hard to imagine a process by which you could build millions of reliable cars. And we've seen that evolution with Toyota and other methods of engineering. And I think of our reliability engineering in a similar way. Anybody can put up a website. What's really hard is putting up a website that can stream videos to millions and millions of people all over the world. And I feel like there's also Murphy's Law involved too, right? Like that one customer comes and uses your service at exactly the wrong time and gets hit with an outage. So this is really what we're trying to do is to sort of tame that. We're trying to help people do that. Now what's happened in the market, I would say over the last few years, is observability and infrastructure has really evolved and we've seen a lot more players show up. We've seen a lot more open source investment. SLOs have gone from something that we've talked about and people scratch their head and say, oh, we mean SLAs. So now being something, we generally run into people who have heard about it and who understand the methodology. Now the challenge is implementation. And what we've seen, I think especially here we are in early 2023, we know the challenges facing many enterprises. They got to keep up with the competition in terms of innovation. Their complexity is going crazy. They have less staff and resources to get done what they need to get done and they can't suffer an embarrassing outage. They really do need to engineer reliability into their process and that I think is what's leading to this incredible demand for SLOs and observability tools and cloud solutions, et cetera. We're benefiting from that tail end right now, which is really, I think really great. Where does this fit into when we look at the larger picture or the cultural discussion we have platform engineering, DevOps, how does it enable those teams also to kind of improve their own work? Well, haven't you heard that DevOps is dead? I think that's the obligatory joke, right? Well, of course I'm joking. The interesting thing about these different roles is I really think that they come from a similar goal but they come with different ideas about what is the right approach to achieve it. What we really want, how do we check the box? We want to deliver innovation as quickly as possible to customers and not slow our teams down. We want to ensure that our services are up and running so customers are not frustrated and annoyed. We want to make sure that the team has everything they need to empower themselves to deliver quality that they're not interrupted in their sleep, that they're working on meaningful projects and we want to do that efficiently. We don't want to waste time and money working on things that are relevant. Everybody agrees on sort of what the outcome is that they want where I think there's some disagreement is what do we call that first of all and how do we organize it? And even within these sort of sub-domains, right, there's different philosophies for how DevOps should work. There's different philosophies for SRE. Do you have embedded reliability engineers or do you have centralized reliability engineers? And I have seen the platform engineering kind of came out of nowhere in some ways because it's been around forever but it's recently become more of a thing and I think part of that is a recognition that especially large organizations have a set of shared services, shared capabilities that everybody relies on. They all need cloud, they all need databases, they all need identity, they all need metrics and observability. They need all these things to do whatever it is they're doing and previously you might have thought of this as kind of your data center team or your knock or your sort of like operations team and increasingly what people are trying to do is to productize that into a platform and every enterprise and every company has slightly different needs for a platform. They might be able to get everything out of the box from an Amazon or a Google or a Microsoft. More likely though, they're going to have some constraints where they're going to have to stitch together multiple solutions, certain configurations, certain policy and that becomes the platform within an organization. And what I think is personally what I like about the platform engineering concept is really this concept of ownership, that you have this thing that you own. And if you're in reliability engineering or DevOps, what you own is a little bit fuzzier. Like I own reliability, okay, what does that actually mean? What do you do to prove that? What's the value you can point to? And I'm not saying it can't be done. I think it's much easier to point to that value when you're building stuff and what's hard today is that it's a little bit difficult to justify building custom infrastructure when there's so much readily available on the market. How folks can get started? Is it part of your offerings or you have to buy something separate? Talk about that. So we have three tiers to our product and one of them is a perpetual free tier. We just announced that actually in November. So now you can sign up at Novel9.com. You can get a free edition, 20 SLOs for free forever. It works with all the data sources, SLO analyzer, service level analyzers included in that. So you can use it for free on your 20 SLOs. Sign up and try it out. You've got some data in Datadog or Prometheus or whatever. You can start getting your SLOs analyzed. We also have a teams edition. You can buy it on Amazon Marketplace. You can buy it direct and we have an enterprise edition for companies that really need the full meal deal. But the right size for any team, it can fit your budget, give you the capabilities you need to get started. And of course, we'd love to get feedback about the product. So if you just try it out for free, kick the tires and tell us what you like or what you hate, we obviously would love to have that feedback. Thank you so much for taking time out today and talk about service level analyzer. I really appreciate your insights. And of course, as you said, there will be more announcements. So I'm already looking forward to talk to you soon again. Thank you. Thanks a lot. Great to see you.