 The Cube presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome to Valencia, Spain in KubeCon, CloudNativeCon, Europe 2022. I'm Keith Townsend and we are in a beautiful locale. The city itself is not that big, 100,000, I mean, sorry, about 800,000 people. And we got out, got to see a little bit of the sites. It is an amazing city. It's hard for me, if I'm from the U.S., it's hard to put into context how a city of 800,000 people can be so beautiful. I'm here with Anish Dar and Ganesh Dada, co-founder and CTO of Cortex. Anish, you're CEO of Cortex. We were having a conversation. One of the things that I ask my client is, what is good? And you're claiming to answer the question about what is quality when it comes to measuring microservices? What is quality? Yeah, I think it really depends on the company and I think that's really the point. I think it really depends on the company and I think that's really the philosophy we have when we build Cortex, is that we understood that different companies have different definitions of quality, but they need to be able to be represented in really objective ways. I think what ends up happening in most engineering organizations is that quality lives in people's heads. The engineers who write the services, they're often the ones who understand all the intricacies with the service. What are the downstream dependencies of the service, where does the documentation live? All of these things impact the quality of the service and as these engineers leave the company or they switch teams, they often take that tribal knowledge with them and so I think quality really comes down to being able to objectively codify your best practices in some way and have that distributed to all engineers in the company. To add to that, I think very concrete examples for an organization that's already modern, their idea of quality might be uptime, but for someone that's going through a modernization strategy, they're trying to get to the 21st century, they're trying to get to Kubernetes, for them quality means where are we in that journey? Are you on our latest platforms? Are you running CI? Are you doing continuous delivery? Quality can mean a lot of things and so our perspective is how do we give you the tools to say as an organization, here's what quality means to us. At first my mind was going through, when you said quality, about having this kind of non-codified set of measurements, historical knowledge, et cetera, I was thinking observability, measuring how much time does it take to have a transaction, but initially you're introducing this new thing, I'm working with this project where we're migrating a monolithic application to a set of microservices. And you're telling me, Cortex helps me measure the quality of what I'm doing in my project? Absolutely. How is that? Yeah, it's a great question. So I think when you think about observability, you think about uptime and latency and transactions and throughput and all this stuff, and I think that's very high level and I think that's one perspective of what quality is, but as you're going through this journey, you might say like, the fact that we're tracking that stuff, the fact that you're using APM, you're using distributed tracing, that is one element of service quality. Maybe service quality means you're doing CICD, you're running vulnerability scans, you're using Docker, like what that means to us can be very different. So observability is just one aspect of are you doing things the right way? Good to us means you're using SLOs, you are tracking those metrics, you're reporting that somewhere, and so that's like one component for our organization of what quality can mean. So what's, I'm kind of taking back by this because I've not seen someone kind of give the idea and I think later on, this is the perfect segment to introduce the cube clock in which I'm going to give you a minute to kind of like give me the elevator pitch, but we're going to have the deep conversation right now. When you go in and you, what's the first process you do when you engage in a customer? Does a customer go and get this off of repository, install it, the open source version, and then what, I mean, what's the experience? Yeah, absolutely. So we have both ACS and on-prem version of Cortex. It's really straightforward. Basically, we have a service discovery onboarding flow where customers can connect to different set of source for their services. It could be Kubernetes, ECS, Git Repos, APM tools, and then we'll actually automatically map all of that service data with all of the integration data in the company. So we'll take that service and map it to its on-call rotation, to the JIRA tickets that have the service tag associated with it, to the Datadoc SLOs, and what that ends up producing is this service catalog that has all the information you need to understand your service, almost like a single pane of glass to work with the service. And then once you have all of that data inside Cortex, then you can start writing scorecards which grade the quality of those services across those different verticals that Ganesh was talking about, like whether it's a monolith to microservice transition, whether it's production readiness, or security standards, you can really start tracking that and then engineers start understanding where the areas of risk with my service across reliability or security or operation security, I think it gives this insane visibility into what's actually being built and the quality of that compared to your standards. So, okay, I have a standards for SLO. That is usually something that is, it might not even be measured. So how do you help me understand that I'm lacking a measurable system for tracking SLO? And what's the next step for helping me get that system? Yeah, I think our perspective is very much, how do we help you create a culture where developers understand what's expected of them? So if SLOs are part of, you know, what we consider observability or reliability, then Cortex's perspective is, hey, we want to help your organization adopt SLOs. And so that service cataloging concept, the service catalog says, hey, here's my APM integration. Then a scorecard, the organization goes in and says, we want every service owner to define their SLOs. We want you to define your threshold. We want you to be tracking them. Are you passing your SLOs? And so we're not being prescriptive about here's what we think your SLOs should be. Or just more around, hey, we're going to help you, like if you care about SLOs, we're going to tell the service owner saying, hey, you need to have at least two SLOs for your service and you've got to be tracking them. And the service catalog, that data flows from the service catalog into the scorecards. And so we're helping them adopt that mindset of hey, SLOs are important. It is a component of like a holistic service reliability excellence metric that we care about. So what happens when I already have systems for like SLO? How do I integrate that system with Cortex? That's one of the coolest things. So the service catalog can be pretty smart about it. So let's say you've sucked in your services from GitHub. And so now your services are in Cortex. What we can do is we can actually discover from your APM tools. You can say like, hey, for this service, we have guessed that this is the corresponding APM in Datadog. And so from Datadog, here are your SLOs, here are your monitors. And so we can start mapping all the different parts of your world into the Cortex. And that's the power of the service catalog. The service catalog says, given a service, here's everything about that service. Here's the vulnerability scans. Here's the APM, the monitors, the SLOs. The gerotik is like all that stuff comes into a single place. And then our scorecards product can go back out and say, hey, Datadog, tell me about this SLOs for the service. And so we're going to get that information live and then score your services against that. And so we're like integrating with all of your third-party tools and integrations to create that single pane of glass. Yeah, and to add to that, I think one of the most interesting use cases with scorecards is, okay, which teams have actually adopted SLOs in the first place, right? I think a lot of companies struggle with how do we make sure engineers defined SLOs are passing them, actually care about them. And scorecards can be used to, one, which teams are actually meeting these guidelines. And then two, let's get those teams adopted on SLOs. Let's track that. We can do all of that in Cortex, which is, I think, a really interesting use case that we've seen. So let's talk about kind of my use case in the end-to-end process for integrating Cortex into migrations. So I have this monolithic application. I want to break it into microservices, and then I want to ensure that I'm delivering, if not, you know what, let's leave it a little bit more open-ended. How do I know that I'm better at the end of, I was in a monolith before? How do I measure that now that I'm in microservices and I'm cloud-native, that I'm better? That's a good question. I think it comes down to, and we talk about this all the time for customers that are going through that process, you can define better if you don't define a baseline. Like, what does good mean to us? And so you need to start by saying, why are we moving to microservices? Is it because we want teams to move faster? Is it because we care about reliability, uptime? Like, what is the core metric that we're tracking? And so you start by defining that as an organization. And that is kind of like a hand-wavy thing. Like, why are we doing microservices once you have that, then you define the scorecard. And that's like our golden path. You know, once we're done doing this microservice migration, can we say like, yes, we have been successful and like those metrics that we care about are being tracked. And so where Cortex fits in is like from the very first step of like creating a service, you can use Cortex to define templates like one click, you go in, it spins up a microservice for you that follows all your best practices. And so from there, like ideally you're meeting 80% of your standards already. And then you can use scorecards to track historical progress. So you can say, are we meeting our golden path standards? Like if it's uptime, you can track uptime metrics and scorecards. If it's around velocity, you can track velocity metrics. Is it just around modernization? Like are you doing CI CD and like vulnerability scans? Like moving faster as a team, you can track that. And so you can start seeing like trends at a per team level, at a per department level, at a per product level saying, hey, we're seeing consistent progress in the metrics that we care about. And like this microservice journey is helping us with that. So I think that's the kind of phase progress that we see with Cortex. So I'm going to give you kind of a hand wavy thing. We're told that Cloud Native helps me to do things faster with less defects so that I can do new opportunities. Let's stretch into kind of this non-tech, this new opportunities perspective. I want to be able to move my microservices. I want to be able to move my architecture to microservices so I reduce call wait time on my customer service calls. So I can easily see how I can measure are we doing, are we iterating faster? Are we putting out more updates quicker? That's pretty easy to measure. The number of defects, easy to measure. I can imagine a scorecard, but what about this wait time? I don't necessarily manage the call center system, but I get the data. How do I measure that the microservice migration was successful from a business process perspective? Yeah, that's a good question. I think it comes out of two things. One, the flexibility of scorecards means you can pipe in that data to Cortex. And what we recommend customers is track the outcome metrics and track the input metrics as well. And so what is the input metric to call wait time? Like maybe it's the fact that if something goes wrong, we have the run books to quickly roll back to an older version that we know is running. That way, MTTR is faster. Or when something happens, we know the owner for that service and we can go back to them and say like, hey, we're going to ping you as an incident commander. Those are kind of the input metrics too. If we do these things, then we know our call wait time is going to drop because we're able to respond faster to incidents. And so you want to track those input metrics and then you want to track the output metrics as well. And so if you have those metrics coming in from your Prometheus or your Datadogs or whatever, you can pipe that into Cortex and say, hey, we're going to look at both of these things holistically. See, you know, is there a correlation between those input metrics? Like are we doing things the right way versus are we seeing the value that we want to come out of that? And so I think that's the value of Cortex. It's not so much around, hey, we're going to be prescriptive about it. It's here's this framework that will let you track all of that and say, are we doing things the right way? And is it giving us the value that we want and being able to report that up to engineering leadership and say, hey, maybe these services are not doing, like we're not improving call wait time. Okay, why is that? Are these services behind on like the actual input metrics that we care about? And so being able to see that I think is super valuable. Yeah, absolutely. I think just a touch on the reporting, I think that's one of the most value I think Cortex can provide. If you think about it, the service is an atomic unit of your software. It represents, you know, everything that's being built and that bubbles up into teams, products, business units, and Cortex lets you represent that. So now I can, you know, as a CTO, come in and say, hey, these product lines, are they actually meeting our standards? Where are the areas of risk? Or are they going to be investing more resources? I think Cortex is almost like the best way to get the actual health of your engineering organization. All right, Anishin, Ganesh. We're going to go into the speed round here. It's time for the cube clock. Time for the cube clock. Start the cube clock. Let's do it. It's going. Let's do it. Let's do it. It's going. You're 10 seconds in. Oh, we can start talking. All right. Okay. Well, I would say, you know, CTO, their question is, how do I know if engineering quality is good? And they don't care about the microservice level. You know, they care about, as a business, is my engineering team actually producing value? Follow the green, not the dream. And so the question is, well, how do we codify service quality? We don't want this to be a hand wavy thing. It's like, oh, my team is good. My team is bad. We want to come in and define, here's what service quality means. And you want that to be a number. You want that to be something that can track. The goal without a timeline is just a dream. And CTO comes in and they say, here's what we care about. Here's how we're tracking it. Here are the teams that are doing well. We're going to reward the winners. We're going to say, we're going to move towards a world where every single team is doing service quality. And that's where Cortex can provide. We can give you that visibility that you've never had before. Yeah. And if you're not... Five seconds. And, hey, your SRE can be the one handling all of this. So, let Cortex... Be the bad guy. Be the bad guy. We're done. From Valencia, Spain, I'm Keith Townsend and you're watching The Cube, the leader in high-tech coverage. The Cube presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome to Valencia, Spain and KubeCon, CloudNativeCon Europe 2022. I'm Keith Townsend and we are in a beautiful locale. The city itself is not that big, 100,000... I mean, sorry, about 800,000 people. And we got out, got to see a little bit of the sites. It is an amazing city. It's hard for me, if I'm from the U.S., it's hard to put into context how a city of 800,000 people can be so beautiful. I'm here with Inish Dar and Ganesh Dada, co-founder and CTO of Cortex. Inish, you're CEO of Cortex. We were having a conversation. One of the things that I asked my client is what is good? Yep. And you're claiming to answer the question about what is quality when it comes to measuring micro-services? What is quality? Yeah, I think it really depends on the company and I think that's really the philosophy we have when we build Cortex is that we understood that different companies have different definitions of quality but they need to be able to be represented in really objective ways. I think what ends up happening in most engineering organizations is that quality lives in people's heads. The engineers who write the services, they're often the ones who understand all the intricacies with the service. What are the downstream dependencies who is on call for the service? Where does the documentation live? All of these things, I think, impact the quality of the service and as these engineers leave the company or they switch teams, they often take that tribal knowledge with them and so I think quality really comes down to being able to objectively codify your best practices in some way and then have that distributed to all engineers in the company. And to add to that, I think very concrete examples for an organization that's already modern, their idea of quality might be uptime, incidents, for somebody that's going through a modernization strategy, they're trying to get to the 21st century, they're trying to get to Kubernetes. For them, quality means like, where are we in that journey? Are you on our latest platforms? Are you running CI? Are you doing continuous delivery? Quality can mean a lot of things and so our perspective is, how do we give you the tools to say, as an organization, here's what quality means to us. So at first my mind was going through when you said quality, and as you started out the conversation about having this kind of non-codified measure, set of measurements, historical knowledge, et cetera, I was thinking observability, measuring how much time does it take to have a transaction. But initially, you're introducing this new thing, I'm working with this project where we're migrating a monolithic application to a set of microservices. And you're telling me, Cortex helps me measure the quality of what I'm doing in my project? Absolutely. How is that? Yeah, it's a great question. So I think when you think about observability, you think about uptime and latency and transactions and throughput and all this stuff. And I think that's very high level and I think that's one perspective of what quality is. But as you're going through this journey, you might say like, the fact that we're tracking that stuff, the fact that you're using APM, you're using distributed tracing, that is one element of service quality. Maybe service quality means you're doing CICD, you're running vulnerability scans, you're using Docker. Like what that means to us can be very different. So observability is just one aspect of are you doing things the right way? Good to us means you're using SLOs, you are tracking those metrics, you're reporting that somewhere. And so that's like one component for our organization of what quality can mean. Wow, so what's... I'm kind of taking back by this because I've not seen someone kind of give the idea. And I think later on, this is the perfect segment to introduce the cube clock in which I'm going to give you a minute to kind of like give me the elevator pitch but we're going to have the deep conversation right now. When you go in and you... What's the first process you do when you engage in a customer? Does a customer go and get this off of repository, install it, the open source version and then what? I mean, what's the experience? Yeah, absolutely. So we have both an on-prem version of Cortex. It's really straightforward. Basically we have a service discovery onboarding flow where customers can connect to different set of source for their services. It could be Kubernetes, ECS, Git repos, APM tools, and then we'll actually automatically map all of that service data with all of the integration data in the company. So we'll take that service and map it to its on-call rotation, to the JIRA tickets that have the service tag associated with it, to the Datadoc SLOs. And what that ends up producing is this service catalog that has all the information you need to understand your service, almost like a single pane of glass to work with the service. And then once you have all of that data inside Cortex, then you can start writing scorecards which grade the quality of those services across those different verticals that Ganesh was talking about, like whether it's a monolith to microservice transition, whether it's production readiness or security standards, you can really start tracking that and then engineers start understanding where the areas of risk that my service across reliability or security or operation maturity, I think it gives us insane visibility into what's actually being built and the quality of that compared to your standards. So, okay, I have a standards for SLO. That is usually something that is, it might not even be measured. So how do you help me understand that I'm lacking a measurable system for tracking SLO and the next step for helping me get that system? Yeah, I think our perspective is very much how do we help you create a culture where developers understand what's expected of them. So if SLOs are part of what we consider observability and reliability, then Cortex's perspective is, hey, we want to help your organization adopt SLOs. And so that service cataloging concept, the service catalog says, hey, here's my APM integration. Then a scorecard, the organization goes in and says, we want every service owner to define their SLOs. We want you to define your threshold. We want you to be tracking them. Are you passing your SLOs? And so we're not being prescriptive about here's what we think your SLOs should be. Or just more around, hey, we're going to help you, like if you care about SLOs, we're going to tell the service owner saying, hey, you need to have at least two SLOs for your service and you've got to be tracking them. And the service catalog, that data flows from a service catalog into the scorecards. And so we're helping them adopt that mindset of, hey, SLOs are important. It is a component of like a holistic service reliability excellence metric that we care about. So what happens when I already have systems for like SLO, how do I integrate that system with Cortex? That's one of the coolest things. So the service catalog can be pretty smart about it. So let's say you've sucked in your services from GitHub. And so now your services are in Cortex. What we can do is we can actually discover from your APM tools. You can say like, hey, for this service, we have guessed that this is the corresponding APM in Datadog. And so from Datadog, here are your SLOs, here are your monitors. And so we can start mapping all the different parts of your world into the Cortex. And that's the power of the service catalog. The service catalog says, given a service, here's everything about that service. Here's the vulnerability scans. Here's the APM, the monitors, the SLOs. The gerotik is like all that stuff comes into a single place. And then our scorecards product can go back out and say, hey Datadog, tell me about this SLOs for the service. And so we're going to get that information live and then score your services against that. And so we're like integrating with all of your third party tools and integrations to create that single pane of glass. Yeah, and to add to that, I think one of the most interesting use cases with scorecards is, okay, which teams have actually adopted SLOs in the first place, right? I think a lot of companies struggle with how do we make sure engineers defined SLOs are passing them, actually care about them. And scorecards can be used to, one, which teams are actually meeting these guidelines? And then two, let's get those teams adopted on SLOs. Let's track that. You can do all of that in Cortex, which is I think a really interesting use case that we've seen. So let's talk about kind of my use case in the end-to-end process for integrating Cortex into migrations. So I have this monolithic application. I want to break it into microservices and then I want to ensure that I'm delivering, if not, you know what, let's leave it a little bit more open-ended. How do I know that I'm better at the end of, I was in a monolith before? How do I measure that now that I'm in microservices and on cloud native? That I'm better. That's a good question. I think it comes down to, and we talk about this all the time for customers that are going through that process. You can define better if you don't define a baseline. Like what does good mean to us? And so you need to start by saying, why are we moving to microservices? Is it because we want teams to move faster? Is it because we care about reliability, uptime? Like what is the core metric that we're tracking? And so you start by defining that as an organization. And that is kind of like a hand-wavy thing. Like why are we doing microservices? Once you have that, then you define the scorecard. And that's like our golden path. Once we're done doing this microservice migration, can we say like, yes, we have been successful and those metrics that we care about are being tracked? And so where Cortex fits in is, from the very first step of creating a service, you can use Cortex to define templates. Like one click, you go in, it spins up a microservice for you that follows all your best practices. And so from there, ideally you're meeting 80% of your standards already. And then you can use scorecards to track historical progress. So you can say, are we meeting our golden path standards? Like if it's uptime, you can track uptime metrics and scorecards. If it's around velocity, you can track velocity metrics. Is it just around modernization? Like are you doing CI CD and like vulnerability scans, like moving faster as a team? You can track that. And so you can start seeing like trends at a per team level, at a per department level, at a per product level saying, hey, we're seeing consistent progress in the metrics that we care about. And like this microservice journey is helping us with that. So I think that's the kind of phase progress that we see with Cortex. So I'm going to give you kind of a hand wavy thing. Yeah. You know, we were told that Cloud Native helps me to do things faster with less defects so that I can do new opportunities. Let's stretch into kind of this non-tech, this new opportunities perspective. I want to be able to move my microservices. I want to be able to move my architecture to microservices so I reduce call wait time on my customer service calls. So I can easily see how I can measure are we iterating faster? Are we putting out more updates quicker? That's pretty easy to measure. The number of defects, easy to measure. I can imagine a scorecard, but what about this wait time? I don't necessarily manage the call center system, but I get the data. How do I measure that the microservice migration was successful from a business process perspective? Yeah. That's a good question. I think it comes out of two things. One, the flexibility of scorecards means you can pipe in that data to Cortex. And what we recommend customers is track the outcome metrics and track the input metrics as well. And so what is the input metric to call wait time? Like maybe it's the fact that if something goes wrong, we have the run books to quickly roll back to an older version that we know is running. That way our MTTR is faster. When something happens, we know the owner for that service and we can go back to them and say like, hey, we're going to ping you as an incident commander. Those are kind of the input metrics too. If we do these things, then we know our call wait time is going to drop because we're able to respond faster to incidents. And so you want to track those input metrics and then you want to track the output metrics as well. And so if you have those metrics coming in from your Prometheus or your Datadogs or whatever, you can pipe that into Cortex and say, hey, we're going to look at both of these things holistically. Is there a correlation between those input metrics? Are we doing things the right way versus are we seeing the value that we want to come out of that? And so I think that's the value of Cortex is not so much around, hey, we're going to be prescriptive about it. Here's this framework that will let you track all of that and say, are we doing things the right way and is it giving us the value that we want and being able to report that up to engineering leadership and say, hey, maybe these services are not doing, we're not improving call wait time. Okay, why is that? Why are these services behind on the actual input metrics that we care about? And so being able to see that I think is super valuable. Yeah, absolutely. I think just a touch on the reporting, I think that's one of the most value I think Cortex can provide. If you think about it, the service is an atomic unit of your software. It represents everything that's being built and that bubbles up into teams, products, business units and Cortex lets you represent that. So now I can, as a CTO, come in and say, hey, these product lines, are they actually meeting our standards? Where are the areas of risk? How are we investing more resources? I think Cortex is almost like the best way to get the actual health of your engineering organization. All right, Anish, Ganesh. We're going to go into the speed round here. It's time for the cube clock. Time for the cube clock. Start the cube clock. Let's do it. Let's go on. Let's do it. Let's do it. Let's go on. You're 10 seconds in. Oh, we can start talking. All right. Okay. Well, I would say, Anish was just touching on this. So their question is, how do I know if engineering quality is good? And they don't care about the microservice level. You know, they care about, as a business, is my engineering team actually producing value? I want to follow the green, not the dream. And so the question is, how do we codify service quality? We don't want this to be a hand-wavy thing. It says like, oh, my team is good. My team is bad. We want to come in and define, here's what service quality means. And you want that to be a number. You want that to be something that can track. A goal without a timeline is just a dream. And CTO comes in and they say, here's what we care about. Here's how we're tracking it. Here are the teams that are doing well. We're going to reward the winners. We're going to say, we're going to move towards a world where every single team is doing service quality. And that's what Cortex can provide. We can give you that visibility that you've never had before. Yeah. And if you're not... Five seconds. And, hey, your SRE can be the one handling all of this. So, like Cortex... Shoot the bad guy. Shot five. We're done. From Valencia, Spain, I'm Keith Townsend. And you're watching The Cube, the leader in high-tech coverage.