 So I've done a couple of lightning talks before, and normally the clock is actually behind me on the big screen and everybody is counting down as you get near the end, and we'll usually start cheering if you're still talking with 10 seconds to go because they cut your mic when you hit five minutes. But they're not actually doing that here. It makes things a little bit easier, but I'm still going to try and get through it in five minutes. So I like to front load my deck with a little bit of cliches and things like that. How many folks have actually heard that software will eat the world? Software is eating the world? We've all got smartphones and so on and so forth. Now we've got smart watches. I like to cut my own slides down and basically say that what I'm saying is wrong. My watch doesn't have any software in it. It's mechanical. So let's get to the next one. Unicorns, DevOps, oh my, who's been basically playing buzzword bingo over the course of the past couple of days? I'm going to try and help you get through that here. So obviously we're a very inclusive community here, and we all know that body shaming is bad. But on the same front, it's always a good idea to try and better ourselves so that Rhino can try and improve their processes to try and actually become a unicorn or at least maybe a little bit more svelte Rhino. So when we start talking about transitioning to DevOps, we tend to talk a lot about automating our pipelines. But it's not all about just automating everything and pushing bad code onto our new platforms. Because if you notice at the hopper there in the beginning, if you put crap in, you're going to get crap out. So we have to actually improve our software as it moves through our pipeline. So when we start talking about, well, how do we move beyond what we've perhaps been doing in the past? We're all doing unit tests and we're all doing continuous integration so that when your code gets checked in, it's being tested. And then assuming those tests pass, you will deploy. But we start to talk about a couple of different ways to improve that process. What are some additional things that we can track? So one of the things that we like to talk about is let's start looking at performance in your CI pipeline. Because if we don't do performance in our pipeline and we deploy poorly performing code into production, we can tell based on industry experience that performance degradations are going to hurt your bottom line and performance improvements are going to improve your bottom line. Amazon noticed that a simple 100 millisecond decrease in the response time of their pages resulted in a 1% decrease in revenue. Walmart noticed that a 1,000 millisecond decrease in response time was a 2% increase in their revenues. And when you start talking about organizations at that scale, that's real money. So how do we start getting through this? What are some of the things that we can start to look at? So our whole take on this is metrics. We're going to start adding metrics into our pipeline. And my time is actually going yellow so I'm going to actually get through all of this to make sure that you can maybe perhaps take a screenshot. So the performance metrics you should be tracking in your pipeline. I'm doing something a little different here. I'm actually providing some actionable information as opposed to just a bunch of funny pictures. So there's a couple of different things that you can be tracking in your pipeline. And that's going to be start looking at a response time corridor. So your unit tests are going to be not nearly as statistically significant as perhaps a performance test because there's not going to be as many of them. But you do want to start tracking response time from build to build so you know if you've degraded. You want to look at the number of SQL calls. Obviously hopefully everybody is familiar with the N plus one problem where instead of getting a set of items, you're getting all of them in individual statements. But one of the things we found recently in talking to our customers is that the same thing is happening in microservices frameworks. So we found that the N plus one problem continues to exist even as we've moved beyond those types of frameworks. So then you look here at the number of exceptions and you want to make sure that your microservices aren't skipping tiers and calling into layers that they shouldn't be. Five seconds. And performance metrics are not just for backend developers anymore. Your front end developers can also do the same exact thing, right? So they can look at the number of domains, the number of images, how big the images are, and their page size. So hopefully everybody has an opportunity to take a couple of screenshots, have some actionable information there, about 30 seconds over here. So we tend to give this talk a lot in a 50-minute session and we're going to be kind of hitting a lot of the Cloud Foundry Meetups with some similar information. I leave here on Wednesday and go deliver a 50-minute version of this talk in Dallas. So hopefully everybody can take a look at it there. And additionally, apmblog.donatrace.com, we've also got a lot of similar content up there as well. So thanks everybody for your time and I think Dr. Nick is coming up here in a moment. Thank you.