Matt and Jason discuss the free developer tool Prefix. Launched 18 months ago, it has now been downloaded by 20,000 developers in 140 countries. Prefix helps developers find and fix bugs in their code while they are writing it.
Prefix is based on the same technology that Retrace uses to monitor servers in production or QA. It tracks key methods in your code including things like SQL queries, web service calls, exceptions, logging, and calls to many other application dependencies. Prefix and Retrace both provide excellent views for developers to see what their code just did for a specific web request or transaction.
Prefix is designed to run on the developer’s workstation, whereas, Retrace is designed for servers and provides a bunch of analytics and reporting capabilities.
Prefix can help developers find slow SQL queries, anti-patterns like N+1 SQL queries, and much more. It also provides some more advanced features like remote tracing, the ability to profile any method in your code, and much more.
Matt Watson: | Hello, everybody. This is Matt Watson, and I’m your host today again on the Stackify Developer Things podcast. Today, we’re going to talk about Stackify’s free product called “Prefix.” I’ve got Jason Taylor here with me today. How are you doing, Jason? |
Jason Taylor: | Good, Matt. How are you? |
Matt Watson: | Jason, you’ve been here for a long time, and you were here when we originally decided to build Prefix. Do you remember why we decided to build Prefix? |
Jason Taylor: | Yeah. I think there were a couple things at play. Most importantly, it’s like we wanted to take all this great work we’ve done in Retrace and just put it on the developers’ desktop and have it be their sidekick all day long providing all that great value without even really thinking about it. |
Matt Watson: | At the heart of Retrace, which is our application performance management or application performance monitoring product, it uses profiling, code-level profiling that instruments codes and a developer’s code in real-time on their servers, right? It collects a lot of great information, and I think the genesis of Prefix was just, “How do we take that same information that typically is only collected on servers in production, right, and get that into the hands of the developers while they’re writing and testing their code?” |
Jason Taylor: | Yeah. The whole point is that they can validate some of the performance of their code, and what’s happening at run time, and hopefully, in an ideal situation, they’re going to find problems that would normally only be surfaced once it gets to their server and it gets to pre-production or production environment. Hopefully, they catch some of these performance issues and code problems before then and they’re able to fix before it goes to the next step. Prefix it if you will. |
Matt Watson: | They can prefix it. |
Jason Taylor: | They can prefix it. You see what I did there? |
Matt Watson: | Yeah. |
Jason Taylor: | Yeah. |
Matt Watson: | That’s why we call it Prefix, right? We talked about it can help solve problems, but I think we should explain to everybody. What kind of data does it collect? |
Jason Taylor: | Prefix is going to collect lightweight stack trace for every web request it’s made, and inside there, you’re going to see all the same sort of things that you’d see in Retrace when you’re talking to SQL and the queries are being executed and when you’re talking to other endpoints. It can work for your console, apps, and services, and all that sort of thing too where you can define transactions and track how those perform. |
Matt Watson: | Yeah, so Prefix is installed on developer’s workstation, runs in the background, right, and it profiles your code for you like other profilers do, except instead of … Most profilers tell you, “Oh, you ran this method a thousand times, and here’s how long it took.” Prefix is more designed to capture an entire trace of a request like an entire transaction, and so it will show you all, like you said, all the SQL queries, web service calls. We automatically instrument for .NET and Java both all the key frameworks and dependencies that people use so things like Redis, and MongoDB, and Elasticsearch, and SQL Server, and Postgres, and MySQL. All of these different frameworks, so it gives you instant visibility into how your code interacts with those things. |
Jason Taylor: | Yeah. A great way to think about it is a lot of developers are used to using developer tools in a browser or a tool like Fiddler, which is going to show from the client side, “Here’s everything that happened in the request,” in like a timeline fashion, “Here’s the resources that were loaded, how long each one took,” and this is just giving the same view on the server side from IS or if you’re a self-hosted .NET Core application, whatever your server is from the beginning of that request to when the response was flushed out to the client, “Here’s everything that happened in the order in which it happened and the breakdown of the timing on everything.” |
Matt Watson: | Yeah. I think that’s a great way to explain it is it’s very similar to Fiddler or even Google’s dev tools that you run in the browser side like client side, right? Except, we’re able to show all the great information on the server side for each individual request, all the things that it did. We talked about how it shows the SQL queries and stuff like that, but we also collect all the application logging. |
Jason Taylor: | Mm-hmm (affirmative). |
Matt Watson: | Exceptions, the overall just time of the request, and I always tell people. Worst case scenario. It’s the world’s best log viewer, right? You can see all of your logging per request, where in most modern applications, web applications that do a lot of Ajax calls or their single-page applications, you load a page, it might load 10 different Ajax calls, and it’s really hard to look at your logging to know which log statements go to which thing, and so it ties all that together very nicely and it’s … |
Jason Taylor: | Tell me if you’ve ever been here as a developer. You’re stepping through your code, you’re debugging, and you stepped right over the break point, you want to stop on, the request finished, and it’s gone, and you’ve got to go back down, debug it all again, or you can open Prefix and see, “Oh, here’s what happened. Here’s my call stack. Here’s the SQL.” Like I’ve got a DVR for my debugging session in a way. |
Matt Watson: | Yeah, and that brings up a great point. What’s awesome about Prefix is it’s very lightweight, so it can run all the time in the background. It’s always there just like our stuff that runs on the production servers with Retrace that you can run on the servers. It doesn’t have much of an impact at performance. The same thing with Prefix. It can run all the time. It’s always there, and for things like the scenarios that you just mentioned, no matter what you’re doing, it’s always there if you need it. You just open it up, and it’s there, but it helps with like weird things like Entity Framework, or Hibernate and Hibernate type queries, or like, “What in the world did my code just do?” or you don’t know what the queries are. |
Jason Taylor: | The dreaded N+1 queries where I wrote two lines of SQL and just got this massive translated SQL statement that is doing a thousand sub-queries. |
Matt Watson: | Right. Yeah, and that brings up a good point. One of the things we did on Prefix is it also has some neat suggestions, so it can actually warn you about those types of things. We built in some kind of real basic pattern matching logic to look for those, those sorts of issues, so we … As we mentioned, Prefix is 100% free. It’s a free tool that we released about 18 months ago. There have been 20,000 people that have downloaded it now. We hit that 20,000 number this week, I believe. It’s been downloaded in 140 different countries. |
Jason Taylor: | Wow. |
Matt Watson: | Which still blows my mind. |
Jason Taylor: | I wasn’t quite sure how many countries there are, but that’s a big number. |
Matt Watson: | The United Nations only recognizes I think about 185. Our website received traffic from over 200 countries every week to our blog so … |
Jason Taylor: | That’s saying something. |
Matt Watson: | It’s a lot of countries. IT is very much a software [inaudible 00:06:55], very much a global thing. |
Jason Taylor: | Yeah. It’s great to see like development happening in so many places. |
Matt Watson: | I think we explain a little more about how Prefix is different. There’s tools like Fiddler, Google Chrome’s dev tools, stuff like that that help you analyze the client side. We also have tools like lightweight code profiler so Redgate ANTS, or on the Java side, YourKit, or other types of tools like that. Again, those are designed where you’re running your code over several minutes of time probably and you’re trying to see, “Okay. What part of my code takes the most CPU? This particular method takes this amount of CPU,” and that’s not what Prefix does just to make sure people understand the comparison of the tools. |
Prefix is very much more a … It gathers each web request or each transaction. It’s more of a transaction tracing mechanism, which makes it very unique, and then you also have other developer tools like ReSharper that .NET developers have come to love, which is more about the quality of your code, the style of your code, and preventing issues as you actually write your code, right? | |
Jason Taylor: | Very much static code analysis, and what we’re looking at is a little bit more of a runtime analysis. |
Matt Watson: | Exactly. |
Jason Taylor: | Once you hit “Compile,” a lot of things happen to your code, and it’s going to behave differently than it may look in the IDE. |
Matt Watson: | Yeah. Your code can be beautiful and you think you’ve got it all figured out, but then when you actually run the code, it’s a whole different world. That’s really what we specialize in as a company, right, is how to help understand what your code is doing, the performance of it. It’s amazing the things that people find in our software after they install our products and just have that like, “Holy moly, I had no idea I was running 500 SQL queries on this page and all this sort of things.” |
The goal of Prefix is to help find those things as you’re writing and testing your code, right, before you deploy your code, and Prefix works really … It’s a great tool for developers to have in their toolbox that works well with the other types of normal profilers we mentioned, right, which are designed for profiling each kind of method in your code. | |
Jason Taylor: | Yeah, and if you’re trying to hunt down a memory issue, doing memory profiling, that sort of thing is a different creature altogether. |
Matt Watson: | Yup, that’s a different creature. There are several different tools, and Prefix doesn’t replace any of those. They’re all just different, different tools in the toolbox, but I would argue that Prefix is actually one of the ones you would probably use the most often. I always say if you’re using some kind of code-level profiler usually to hunt down a CPU or memory problem, you’re probably having a bad day, right? |
Jason Taylor: | You’re having a bad day. You’re taking a lot of time to set up some pretty intensive debugging that you don’t want running all the time either. |
Matt Watson: | Right. It slows your app way down usually, and it’s because your app got CPU usage problems or memory usage problems, garbage collection problems, whatever it is. Prefix is really designed to be something that you can run all day long. It runs in the background. It’s like your best friend. It’s just there. |
Jason Taylor: | That comes in so handy because there’s times that you don’t realize you may need it, so another example and something that I use Prefix for a lot is you’re aware with the stack that we have here, and we’re highly decoupled system that we’ve got a lot of different layers of services and APIs, and I might be working on my machine on our frontend, which I’m sorry to our users. If I’m working on our frontend, you probably aren’t going to enjoy the experience, so I try not to work on our frontend, but let’s say I am. |
I’m calling on whatever API that’s also running on my machine, and I get back a 500 error. I wasn’t debugging the API at the time, and again, I’ve got Prefix right there. It was running. It was profiling that. I can view that request, see any exceptions that were bubbled up, and know exactly what failed without having to then launch another instance of my IDE, load up that code, attach to it, and try to recreate the scenario again and stepping through it on both sides. | |
Matt Watson: | Yeah. |
Jason Taylor: | It’s just always there. |
Matt Watson: | Yeah. I think you bring up a great point, so you don’t even have to have Visual Studio or your IDE running like Prefix is just always on the background, and so to your point, if you have one application that’s a consumer calling a web service and another application, Prefix can track both sides of it automatically and show you the traffic from both perspectives, which is really handy and your point like you don’t have to open Visual Studio. You don’t have to be debugging. You don’t have to do any of that stuff. It just works just there. |
Jason Taylor: | Yeah. It’s all about productivity like just being able to do that has probably saved me 20 minutes of chasing around a problem that I could easily identify in a few seconds, and then go on about whatever I was working on. |
Matt Watson: | Yeah. We talked to a lot of people that … especially people that are doing a lot of frontend kind of work where they’re calling a lot of web services and/or full-stack development from that perspective that they’ll put Prefix up on the second monitor on their computer, and it’s just always there, and I know … I don’t write a whole lot of code these days, but when I do, if you’re creating a brand new like MVC controller action or whatever, it’s like, “Okay, I got that. Let me run it, make sure it works, it loads.” I can see in Prefix, “Oh, it loaded. Okay. Let me add MySQL query. Okay. Let me see what that looks like in Prefix.” It’s like each step by step, you can, as you’re testing your app and testing your code, you have that constant feedback. |
Jason Taylor: | Absolutely. |
Matt Watson: | As we think about all the things that Prefix does, we’ve talked about some of the basics, it does some more advanced things. What is your probably favorite some of the more advanced things that you can do with it? |
Jason Taylor: | One of the things I love is how it works with Retrace, right, is that I can hook it up to Retrace, and I can see the corresponding request on the other side. If I’m making a call to an API on my servers in one of my other environments that has Retrace running, I can then dig into that side of this or performance over there and see the call stack from other there. |
Matt Watson: | Yeah, so that is also one of my favorite features. I don’t know what the best name for that is, but what I’ve always called it was remote tracing. |
Jason Taylor: | Right. |
Matt Watson: | Yeah. My code calls a web service that’s on a server somewhere, and that server somewhere has Retrace on it, and Prefix will show me what happened on my local machine, so I can see my control or action ran. What did I do? I ran this database query. Whatever. But then, I call the web service call, and what it will do is add the button there that basically says, “Retrace,” and then if you click that, it will go remotely behind the scenes, connect to that server that’s in the cloud or wherever it’s at, fetch that trace, the same sort of trace, and pull it back down, and make it visible so you can see in the end and debug your code all the way through, which to me is just like really, really cool. |
Jason Taylor: | Yeah, yeah. It’s just an extension of that scenario I gave earlier. If I have it all, multiple services, running on my own machine, that often times we’re developing against maybe one of our apps that’s already deployed on a stable version in a test environment, and that’s the API. Maybe it’s another team in my organization that is responsible for that, so they give me an endpoint to test against. If I have a problem, I don’t have to go bother that team and help them chase it down. I can just show them. “Hey, here’s what happens when I’m making a request that’s failing or slow,” and Prefix and Retrace are working together to help collaborate on it. |
Matt Watson: | Yeah. I think that’s an awesome example and scenario where one team maybe building the APIs, and then you’re consuming them, and you can help troubleshoot and debug their API for them, right? Through the remote tracing feature, you can see potentially the logging statements that were happening on the server side. |
Jason Taylor: | Mm-hmm (affirmative). |
Matt Watson: | You could see what SQL queries it was running. You could see all that stuff, and it just seamlessly pulls that right back down into Prefix and shows you. Now, granted if they’re using Retrace, they can also log into Retrace and go hunt that down to. |
Jason Taylor: | Absolutely. |
Matt Watson: | What’s nice about this is it sews together those exact transactions and just instantly shows it to you just effortlessly, which is so cool. |
Jason Taylor: | Yeah, yeah. |
Matt Watson: | What other features about Prefix do you really like? |
Jason Taylor: | What other features do I like about Prefix? |
Matt Watson: | What about the … We worked on making it so you could track any method in your code? |
Jason Taylor: | Oh, yeah. Let’s talk about that. That’s awesome because often times, you’re working on something, and what Prefix does great out of the box, as you were describing earlier, it’s going to work against a bunch of known frameworks, and we’re going to do some instrumentation of the things that you really care about, but every now and then, I personally might write some code that doesn’t perform that well in one of my class libraries. |
With Prefix, I can easily go in, hit the “Settings” button, and go in, and Prefix will reflect all of my assemblies, show me what classes and methods are available, and all I have to do is put a little checkbox next to the methods that I’ve written in my code libraries that I want to profile as well, restart my app, and Prefix is going to start instrumenting those as well and give me a lot deeper insight into what may or may not be poor-performing code that I wrote. | |
Matt Watson: | You don’t do that, do you? |
Jason Taylor: | Never, never. |
Matt Watson: | You’re not a normal developer? |
Jason Taylor: | No. It’s a hypothetical situation, right? |
Matt Watson: | Okay. |
Jason Taylor: | No, no. |
Matt Watson: | Asking for a friend? |
Jason Taylor: | I’m asking for a friend. Yes. |
Matt Watson: | If I can, can I reiterate right what you said there? We automatically instrument all the key frameworks, but to keep the overhead low, we don’t instrument every method in your code. |
Jason Taylor: | Right. |
Matt Watson: | Sometimes, you’re like, “Okay. I know it takes five seconds for something to happen. I don’t know what,” so you can go and look at your code and say, “Okay. Well, I know it calls this method, and this method, and this method,” and you can configure Prefix basically to profile those additional methods, and then it will spit those out, and you’ll be able to visualize them in Retrace? |
Jason Taylor: | Yeah. |
Matt Watson: | Retrace can do that as well on the server side. |
Jason Taylor: | It certainly can. Yeah. |
Matt Watson: | There’s some more ways to do that. It’s one of the things to be careful about because if you profiled every single method, again, it would bring your application to crawl. Most people don’t realize like there’s tens of thousands of methods that get called for every single web request. |
Jason Taylor: | Right. |
Matt Watson: | You absolutely don’t want to profile every one of them. |
Jason Taylor: | Yeah, yeah. |
Matt Watson: | We’ve done that before. |
Jason Taylor: | Yeah, and people also don’t realize that … or people do, but you don’t really realize the impact of it until you try to profile *.* is that every getter and setter for a property is a method of occasion, right? That can get very, very noisy very quickly, but it is sometimes fun to see. |
Matt Watson: | Right. Some of the other things you can do with Prefix that are cool. I really love the logging features, being able to configure … On the .NET side like Nlog and log4net, they’ll just add a simple config to that to add the Stackify logging appenders. Same thing on Java. We have support for on Java, and then all of that logging flows in, and you can see it all like per request. Like mentioned earlier, it becomes the world’s best log viewer to me. Actually, if you google that, we rank number one for that on Google. World’s best log viewer. |
Jason Taylor: | Do you have a coffee mug that says that? |
Matt Watson: | I need one of those. We need one of those. |
Jason Taylor: | World’s greatest log viewer. |
Matt Watson: | It also supports what we would call structured logging, so you can log not only just text, but you can log in object, and so that object could be like the client number, or transaction ID, or some parameters that you’re past to a SQL statement, or whatever you want it to be. It would help … helpful in debugging, right? You can build that like little dynamic object and log it, and then Prefix will automatically show that like as adjacent object. |
Jason Taylor: | Right. |
Matt Watson: | Right, Jason? |
Jason Taylor: | Right, Jason. Jason? Jason. Jason. |
Matt Watson: | I think that’s one of the cool things is we almost see … to see that, and that’s one of the cool things about Retrace too is that those same logging statements from the servers will feed in into Retrace, and then you can search on those custom parameters. |
Jason Taylor: | Right. |
Matt Watson: | That’s one of the things I always recommend to people that we do a pretty good job of is in all of our logging, we always try and log like our client number. |
Jason Taylor: | Mm-hmm (affirmative). |
Matt Watson: | You can go into Retrace and search by client number. If it’s like, “Client 32 has a problem,” “Well, here is every log statement across every app, every server.” |
Jason Taylor: | There’s a lot more granular search than opening up a file and adding control if and typing. You’re going to look for this object graph that has a field called “Client ID” with a value of 12345. |
Matt Watson: | Right. |
Jason Taylor: | A lot more powerful. |
Matt Watson: | Yup. Yeah, absolutely. There are few other products that are similar to Prefix, so Glimpse is a popular tool on the .NET side. |
Jason Taylor: | Glimpse is a big one. |
Matt Watson: | I believe there’s one on the Java side called “XRebel,” which is a cool product. One of the things that make Stackify different though, especially from Glimpse is how it’s used, the data it provides, how it’s installed. Can you speak to that, Jason? |
Jason Taylor: | There’s a couple big things about Glimpse that, as a developer, I don’t like. The first is all the configuration that’s required to get everything that you need out of it and to do all of that instrumentation is that, first off, it’s not being done at a bytecode level with profiling. It’s routing requests through providers they’ve built to essentially do some advance logging, so very similar ETW and application tracing. A good example is if I want profile MySQL inside of glimpse, I have to run everything through like their SQL provider, right? |
Matt Watson: | Yeah, you’ll create like a SQL connection object and pass it into their code. |
Jason Taylor: | Right. Right, right, which depending on how you have your SQL code encapsulated, that might be just a couple lines of code. For other people, it might be a lot more code, and so there’s a lot more configuration, and set up, and constant care and feeding of getting something like Glimpse always there running and working for you. The reporting and user interface side of it is quite sophisticated as what’s done with Prefix. |
Matt Watson: | It’s different. There are some pros and cons. Glimpse does some things better than Prefix does. |
Jason Taylor: | Yeah. |
Matt Watson: | They work a little differently. |
Jason Taylor: | One of the other things that bothers me about it, and I think this is underscored by the fact that there’s a couple of public utilities out there where you can have your ASP.NET website scanned for known vulnerabilities. One of those vulnerabilities is whether or not Glimpse is sending all of that data out publicly because Glimpse creates an endpoint inside of your application, a webpage to serve up all of the data. If you ship your application with the wrong flag set, you’ve exposed all of that to the outside world, which has a lot of sensitive data, and Prefix never ever, ever does that. |
Matt Watson: | Yeah. That’s one of the big differences, right, is Prefix is installed on your local machine. I think the only configuration that you ever have to do is configuring the logging appenders. |
Jason Taylor: | Yes. |
Matt Watson: | That’s about it. Where with Glimpse, you do have a lot of packages, and web config changes, and all those stuff. They do have settings around security and I think IP restrictions. That stuff is all there, but it does have a lot of baggage, a lot of configuration, and you got to make sure you do it the right way. |
Jason Taylor: | Absolutely. |
Matt Watson: | I just want to mention that that the products actually work together. If somebody has Glimpse and wants to use it, they can use Glimpse and Prefix both at the same time, so that’s no problem as well. One of the other features that I don’t think we talked enough about in Prefix, I think it’s really important like on the .NET side, it can click every single exception ever thrown. |
Jason Taylor: | It can. |
Matt Watson: | Which I think is a really, really cool feature. You don’t even have to configure the logging appender stuff. Because the way our profiler works, we’re able to get every single exception that’s ever thrown. Even if it is in a try-catch statement, it’s caught and just thrown away. It can surface those. |
Jason Taylor: | Mm-hmm (affirmative). |
Matt Watson: | That’s important because a lot of performance problems come from hidden exceptions. Now, some of them are just noise. There are a lot of actual internals in the .NET framework that throw exceptions, especially when the app first starts up, that are just noise. They’re not a big deal, but there are definitely other things that you see in people’s code that could be problems with trying to lazily parse integers or parse date times and things like that, so they’re not using int.tryparse, which handles it more gracefully. It can help you find all those hidden exceptions in your code, which I think is another big value to the tool. |
Jason Taylor: | What are the things that we use a lot here on our team is the ability, I don’t think we’ve spoken about this yet, to share traces out of Prefix back and forth. It gets saved off in a format that anybody who has Prefix can open up on their machine in Prefix, so that will happen sometimes. I’m working on something, and I see an error bubble up. I have a class library I’m using that another developer on the team is responsible for, and I’ll just simple say that trace off, and throw it into slack, and send it over to the developer, and say, “Hey, take a look at this. Tell me what you think,” or if we want, if it’s something that needs to be addressed on a larger scale, we can attach that to a work item in Jira. |
Our QA team in fact can do that. Our QA team will run branches of our builds locally to do some smoke testing. When they see these things, they can save that trace off, log it in a Jira item, and then when developer goes to pick it up, it saves a lot of time and having to reproduce the issue. They’ve got trace right here that shows the problem. | |
Matt Watson: | I think you bring up another use case for Prefix that we haven’t talked about, so it’s great for developers to use while they’re writing and testing their own code, but it’s great if you’re in QA or you’re a dev manager, or a lead developer, or something like that that is doing a review of somebody else’s code, right, and testing their application of finding potential problems. |
Jason Taylor: | Or perhaps, you’ve inherited an application that you didn’t write and you’re trying to figure out how it actually runs. |
Matt Watson: | Yeah. I think that’s a great scenario too. You have no idea what this thing does. You’re just trying to figure it out. It’s fun to use Prefix against some common open-source projects too. |
Jason Taylor: | Right. |
Matt Watson: | Say DotNetNuke or like NopCommerce and SimplCommerce. Like there are some different like open-source libraries or open-source projects like that. |
Jason Taylor: | Right. |
Matt Watson: | It’s fun to use it against those and just see all it does. |
Jason Taylor: | Yeah, it can be. It can be. |
Matt Watson: | We use some of those apps internally just for testing our software, right, just because there are just random apps out there that do all sorts of random things that we can test our Prefix and Retrace with. What else about Prefix shall we tell everybody? |
Jason Taylor: | That they need to come download it and try it today if they haven’t already. |
Matt Watson: | It is free. As we mentioned, it’s free. Now, there is a paid version of Prefix. I think it’s $15 a month, but it also includes a free license of Retrace for your server for pre-production. |
Jason Taylor: | Yes. |
Matt Watson: | 15 bucks a month is super cheap, and you get some of the advanced Prefix features. Plus, you get a complete license of Retrace, and that includes all the features of Retrace. It’s still really amazing to me that 20,000 people have downloaded Prefix and … |
Jason Taylor: | What amazes me the more is how many have told us about how much they love it. |
Matt Watson: | That is absolutely true. You can go search Twitter or something for Prefix, and we hear some pretty cool random stories of what people find. |
Jason Taylor: | Yeah. We’ve never once asked anybody for a testimonial on Prefix, but we have hundreds of them on our Twitters. |
Matt Watson: | Yeah, that’s absolutely right. The Twitters of the world are full of tweets about Prefix. |
Jason Taylor: | Yes. In most of those cases, I think what’s really endearing people to Prefix is that they installed it because somebody told them, “Oh, this is cool. You should check it out.” Within the first few minutes, they’ve discovered something about their app that they didn’t realize that they’ve used to improve. |
Matt Watson: | You can almost guarantee you’re going to learn something in the first few minutes that you didn’t know anything about. |
Jason Taylor: | I know. I did the very first time I used Prefix, and I helped write Prefix. |
Matt Watson: | Yeah. Luckily, nobody has to know what you found, right? |
Jason Taylor: | There you go. That’s the beauty of it. You’re prefixing it. |
Matt Watson: | You’re prefixing it, and so I think that brings up the real key value of Prefix is we live in this world now where it used to be developers did what they did and threw everything over the wall, and IT operations dealt with the fall out of that. Of course, that doesn’t work very well, and so we have devops, and site reliability, and all these movements now that are designed around developers and operations working together. Everything is what Gartner call “shifting left.” It’s shifting from operations to developers being more involved in things like deployment, things like monitoring, troubleshooting, all these things. |
Prefix and Retrace both just go to that story of giving the developers the tools they need to do these things, right? Developers can actually find bugs while they’re writing their code instead of waiting for them to get to QA, to do performance testing, or using more detailed performance analysis tools that maybe you’d only have traditionally in QA or production, right, is developers were able to do these things at the very genesis of creating their software, and then we provide Retrace, right, in QA, in production so they can do it through the whole life cycle. | |
Jason Taylor: | That’s a natural evolution. |
Matt Watson: | That’s really our whole goal at Stackify is to help developers do that, right? It’s to help them write better code, produce higher quality product in their deployments, right? Before you deploy your code, you can use Prefix, you can use Retrace, right, to help find problems, and then when you get ready to do the deployment, you can do the deployment, and you can sit there and watch the deployment live while it’s happening, see, “Okay. Look, we’re not getting any traffic because we took the servers down. Okay. Traffic is coming back up. Is performance back to what it used to be? Are we finding new errors?” |
Jason Taylor: | Okay. Yeah, that’s the big one. |
Matt Watson: | We did that today. |
Jason Taylor: | We did that today. We did that today, so we added deployment of Retrace today. You walked into my office about the time that it was happening, and you could see on my dashboard this little spike in there. It’s just for a few minutes, and that was something that we experience every time we do a VIP swap of production to staging nodes, and it’s the … Actually, the instances are coming out of production losing their connections, and they’re still reporting data to us for a while, but yeah, you see that instantly with a nice little demarcation as well from our CD system of, “This was the deployment.” |
Matt Watson: | Yeah. Any time you do a deployment, you’re going to have some sort of issues. You’re taking servers down. You’re putting servers up. Things are coming in and out of a load balancer. You’re killing several odds running right because you agreed to playing your app, so it’s all normal. |
Jason Taylor: | Right. |
Matt Watson: | It’s great to be able to see that in real-time, and then of course, the next day, do a postmortem of, “Okay. What happened? Now that the users have had a few hours to use the system, what new errors have been newly found?” |
Jason Taylor: | Oh, yeah. |
Matt Watson: | “Is performance still the same? Is it not the same?” All of a sudden, we got to see who queried that has problems that we didn’t know had a problem before, right? Then, being able to take all those insights and feed those right back into the next sprint, right? It’s like, “Okay. Well, we found we … This SQL query is slow. Let me go back to my workstation. Let me pull up Prefix. Let me test the code. Let me see. Where do we use that SQL query? How long does it take?” Prefix can help do that. |
Jason Taylor: | Yeah, absolutely. |
Matt Watson: | That’s that whole loop from writing code to production, all the way around. We’re really glad that we can offer Prefix for free and the developers can do that. Retrace is only 10 bucks a month in pre-production and starts at 25 bucks a month. |
Jason Taylor: | Right. It’s basically free. |
Matt Watson: | It’s not very expensive, especially considering how much software developers cost and everything else that … the amount of time it takes to pay somebody to chase these problems around. |
Jason Taylor: | Producing software is an expensive endeavor. |
Matt Watson: | Yeah, it’s a huge productivity-boost. |
Jason Taylor: | Yeah. |
Matt Watson: | Absolutely. Thanks everybody for listening today and hope you learned a few things about Prefix that you didn’t know. Again, it’s absolutely free. We encourage you to give it a try. It’s an excellent to have in your toolbox. Maybe you won’t use it every day. Maybe you will, but it’s definitely a tool you should carry around with you. |
Jason Taylor: | If you aren’t in one of the 140 countries that already has Prefix users, we especially want you to try it out. |
Matt Watson: | That’s right. We’re trying to get every country. |
Jason Taylor: | That’s right. |
Matt Watson: | Thanks, everybody. |
[adinserter block=”33″]
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]