Sentry Application Monitoring- Allowing Builders to Build
Transcript
(dramatic music) >> Hey, how's it going? It's Keith Townsend, Principal of The CTO Advisor. We're continuing our coverage of Google Cloud Next with this sponsored piece of content from Milin Desai. Milin, I knew you way back in my infrastructure days. Welcome back to The CTO Advisor Studio. You were one of the original guests. >> It's great to see you and it's great to be here. >> So, Milin, we're going to talk about the builder's journey when it goes bad.
We're at Google Cloud Next. And the great thing that I love about Google Cloud Next, AWS re:Invent, there's just a bunch of builders who are, I'm an enterprise IT guy and I have to say, they're just a bunch of trouble makers, man. They're out building applications, adding value, but they inevitably get to a point where they're in risk of putting the business out of business. I think developers are similar to cash flow. When you run out of them, you can run out of business.
>> Yeah, it's amazing what a software team can do, a developer team can do. It's a three to five person team, every startup out there that's creating. And essentially you have to start somewhere and you have to ship software, you have to be in production. And the simplest thing I'll talk about failure is you could test every permutation and combination. But once you're in production, maybe the checkout button doesn't work. Maybe the login button is too slow. And so you need something that tells you in real time if something is broken, if something is slow.
Is it infrastructure? Is it code? And increasingly, code is changing the fastest. Why? Infrastructure has been normalized. So code is changing the fastest. Can you find issues in it? Can you catch them early? Can you scale it? Can you solve it? And that's pretty much the genesis of whether you're a three person software team that becomes a seven person team that becomes a 14 person team to then growing. >> So we're going to talk about AI on the performance side in a second, but we're at Google Cloud Next.
And you can't talk development without talking Duet and Duet AI. This ability to create actually pretty robust applications or I'm going to say, capable applications. 'Cause robust means something different when in a context of performance. So I can take Duet, use generative AI, basically a code assistant, and create really great product that gets me to the market. But we've been in IT for a long time both on the application side and the development side. You get to a point where the application breaks.
You have three to five developers, none of which are DBA. And a customer talks about, you know what? When I hit a checkout button, I get thrown this system error and I have no idea of what it is. You turn it back over to your development team, they look at it and they're like, it's just a weird error. I don't know. I don't know where to start looking. That's where folks get into trouble. How does Sentry IO help get me to kind of that next level of triage?
>> Yeah, in that example that you just said, you have an error and where is the first thing you look for? Number one, do you even know that your customers are running into that error? Is it everyone? Is it a subset? It's only happening on certain browsers, it's only happening in certain environments. Do you have that metadata? Is it somebody screaming on Twitter saying your release is broken? Which happens a lot these days. >> Right. >> Our users get frustrated.
Is it a support ticket? So you're already kind of behind the curve if you don't have Sentry, number one. And if you're not using Sentry, then you decide, oh there is an issue. You start where? You start with logs and then the question is, do you have access to those logs as a developer? Because you probably don't on a regular basis. And so you start parsing through logs and metrics and all of that stuff. And it could probably take you hours, if not days in some cases.
The alternate, which is Sentry, is as that issue is happening, that error just happened, in real time, we will let you know that that error is occurring. It's only happening on the Chrome browser, and here's the line of code, the full stack trace down to the line of code, the steps, the breadcrumbs that the user took to get to that and the potential code commit that caused it. So where all the triage and everything is all gone. You just exactly know, number one, there's a real problem and here's all the metadata around it.
If I solve that, I can either patch it or I roll back the change. And this is exactly what now 90,000 plus software organizations are doing from a early stage startup to some of the biggest companies. >> So one of the things you just mentioned really kind of piqued my interest even before we hit record. You said it once and now you've said it again. Which code commit did it come from? As I think through kind of AB deployment, AB testing, various variations.
I can have a Kubernetes pod with if I do three deploys a day, I might have three versions of the app out there in a given day. And if a subset of users are getting an error in one or two versions, it's really tough to triage where that commit is coming from, versions of the database, et cetera. So help me understand the mechanics of that. How was Sentry aware of the commits, not just the code itself? >> Yeah, so we deeply integrate into Git, and so that's kind of where our secret sauce comes in.
So there's two ways we integrate. One is Sentry is agentless. So you just embed us in your preferred language SDK, you roll it out and essentially we start capturing issues. And on the backside of this, we are connected to your Git repository and we are able to correlate which commit, which releases, and tie it to an essential issue in your software. And so that's kind of the connecting dots that we do as a product, which is not only tell you something's broken, we give you the stack trace, the line of code, the breadcrumbs, but also the commit.
And that's kind of the magic in that. >> So, again, I've interviewed you before. You know that you're going to get the tough operations type questions. Added as a line of code to my platform. It has historical knowledge of my platform that I'm developing. What if this is Brownfield? What if I've never used Sentry before? There's no historical reference to the code. I didn't grow up with Sentry in my application. >> It doesn't matter. And that's the beauty of Sentry.
It's for any software application. So as long as you're writing a piece of code, whether it's a application that's three years old or the next mobile app you're building or the next desktop app you're building, you just integrate it in your preferred language SDK. js, which is kind of really hot right now in the JavaScript world, or it's a PHP app, doesn't matter. And so you have 100 plus platforms we support, and the exact example, you said the mobile example, mobile is a perfect case where you actually have multiple releases out in the wild.
Per release, I can tell you things like crash free sessions. You know when you turn on your mobile app and it crashes? We tell the developers that your app is crashing like eight out of 10 times. >> Hmm. >> And so you can make a decision of the three releases which one is stable and you can pull back. >> Yeah. >> And so customers do that. They actually take Sentry data and say, oh we are seeing a crash rate greater than 1%.
We are going to roll the release back automatically. >> Yeah, I just stop using the app. I don't even report that it crashed, I just stop using the app. Unless it's Angry Birds. If it's Angry Birds, I'm complaining. >> You stop using it or you go to an alternate. And that's what most companies don't realize is yes, you could have monitoring and you could look at a dashboard and you can react after the fact. But in this modern world that where you're shipping three times a day, you can lose a user, you can lose a consumer very easily.
You need something that allows you to respond to the customer with greater agility without affecting your innovation velocity. So you want your developers to be productive, ship code, ship it fast, but on the other side, you want to catch it. So that's the combination of high quality meets high productivity meets high velocity. >> So I'm going to throw you another curve ball 'cause you introduced it. This is kind of like court. You introduce a topic, I'm going to go there.
100 different platforms. What happens when I'm in a mixed environment though? And this happens a lot. I have some folks programming in Go, I have some people programming in PHP, Java, et cetera, and then it is a single system or application. That is immensely difficult to troubleshoot. I need four or five different language skills. How is Sentry helping me in that mixed code environment? >> Such a great question. So most scenarios are what you talk about, which is you end up using different frameworks or different languages based on kind of your requirements.
And so in this scenario, we will tell you if the issue, so most issues could show up as a front end issue. >> Right. >> But turns out that you don't have as many nails in your database. You're selling nails and you're out of capacity and the error is actually coming from the backend. So we tell you whether it's a issue in the front end and then it links to the issue in the backend, the API call. Or if there are multiple services in between, you can actually trace it and see where the actual failure is.
And in each language binding you can see the line of code where the flow is happening. So in the case of errors, we can tell you whether it's a front end issue, a backend issue in that. If it's a performance issue, we will actually trace it to multiple calls going into the backend. It's a slow database query. And all of this, again, four lines of code built for the developer. So a lot of companies say they're developer companies. If there are 1,000 developers, we serve 900 developers or all 1,000.
We don't serve just a subset of them. Developers use this day in, day out. >> So do you see teams use this to, when they're providing a service or API to their external collaborators, do you see them using this as kind of a triage tool as well? Say, hey, we're providing a API and you're making API calls. We have our tool Sentry on the back end and we're seeing your request come in and this is where the application is breaking. Or is this, does every party need to have Sentry installed in their app?
>> It's a little bit of both. So as a service, let's say you are an API service doing billing, and so you're serving the OpenAIs of the world because there's a billing platform. It'll basically monitor itself and saying, am I keeping up with my SLA in terms of my API response? Is my API slow? Is it broken somewhere? As you change and continue to change your software. So definitely kind of that from an internal perspective as a service in that.
But then that represents a service to your end customer. >> Right. >> In that. So it is primarily used by builders to monitor their own service. So we are probably one of the first services that most developers turn on, because once you write your code, you run it, you deploy it, you want to know what's happening with it. And it's the easiest to use in terms that it tells you what's broken. >> So we're going to end it with the question, I always have to tell you it's not good enough.
Like okay, I need to solve the problem before I even know that there's a problem. And I think that's where we're headed to because I'm a business owner and I want to, I tell my team, if there's no red or yellow on the report, I'm worried. 'Cause what is it I'm not seeing? How does Sentry help me predict problems versus just knowing when there is a problem? >> So primarily we sit in production, and that's been kind of we are that friend you have who is looking over your shoulders and saying, hey, if something's a problem, I'm going to be there to support you.
So it's primarily used in production and we tell you when an issue is broken. We are starting to get into what we call as giving you these insights earlier in the cycle. So you mentioned a lot of people roll it out as part of a feature flag and then do slow rollout. So the way folks are starting to do this is I'll roll out, a gaming company rolls it out to a subset of the gamers, sees how it's working out, and then kind of expands on that.
So we are part of kind of that rollout strategy in that. We haven't completely gotten to the point of a predictive model where you're writing code and I'll tell you exactly like, oh my God, you are probably writing broken code. I think the world would love that. >> If it did that I'd never be able to code. None of my code would ever get past. >> But I think there's an interesting kind of element that's starting to take place. So we recently acquired a company Codecov which does code coverage.
And it tells you if your code is tested or not. And what we've done is not only will it tell you, hey, here's your stack trace, here's the line of code. Now we can tell you if you have a test for it. If you don't have a test, that's a problem. If you have a test, it's not working because it's broken. So we're starting to connect that dot into catching things earlier. And so that Codecov is like one element of that.
We can take Sentry production data and make some kind of interesting insights into code going forward. So there's some ideas around it. But today we typically sit in production, tell you when shit is off. >> So the the predictive nature of that, of testing, and we didn't really talk about testing. What about the barrier to, do I have to manually kind of take my Sentry output and know, oh, I've consistently not had to test X, Y, or Z, so I'm going to turn off testing and I have to manage that as my own pipeline?
Or does Sentry help me with doing inefficient testing? If I'm chewing up cloud compute cycles, doing unnecessary testing, it seems like Sentry would be a good source of data at least to know what testing to do or not do. >> So number one, I think the first place where we are integrating with CI is in the rollback story that we talked about. Which is depending on how the software is doing in production, you will do automatic rollbacks. And so that's something some of our largest customers are doing already, which is I release this piece of software.
I'm seeing it's not meeting our quality standards in terms of either crash free rates, crash free sessions, number of errors, all of those things. They have predefined sets, just automatically roll it back. We can look at it in piece. You don't need to light up the entire company and get engineers on a call. Roll it back we can look at it. So that's kind of the first integration into CI. The second piece that you're talking about is now that I have an understanding of my code coverage, coverage data, I know what's changing in code in the pre-release cycle.
We are getting into what is called as automatic test selection with the Codecov offering that we have. >> Hmm. >> Essentially saying, only these things have changed, only run these tests. So automatic test selection which directly impacts your CI run times. So makes it faster, also affects potentially your bill in the cloud because CI runs on the cloud. So you could have money savings in that. But we are just about to get into that ATS piece, automatic test selection, flaky tests, all of that with the Codecov line.
And Sentry is one of the data feeds into that decision making process. >> So Milin, I really appreciate you joining The CTO Advisor here at Google Cloud. I'm going to head back down to the show floor and kind of probe 'cause you're not the only company that does this. But now I'm armed with a good number of questions to ask. They're like, you're a really smart analyst. Yeah, I am. I have a buddy, I know a guy. If you want to learn more about The CTO Advisor, you can follow us on the web.
io. My good friend Milin would really appreciate you asking some tougher questions. I'm not a developer. com. com. com @ctoadvisor. DMs are open. Talk to you next CTO Advisor Studio.
