We're here in Austin, Texas at the Five Runs headquarters, we have two exciting guests with us. Would you like to introduce yourself, guest? Sure. I'm Steve Sanderson. I'm the VP of Development and Technology here at Five Runs. Yeah. I'm Bruce Williams. I'm a developer here at Five Runs. I was here today, you guys were telling me about sort of the exciting new release you guys have coming out. And I mean, before we get to exactly what's in the new release, do you want to just give a quick overview of what Five Runs does? Our products are for the Ruby and Rails market monitoring, we also have an installed product that builds up an environment, provides an environment for developers, but generally we're focusing on how to create success for the application developer and deployment in the whole Ruby and Rails world. Right. So essentially you're sort of everything except actually writing the code for Rails. Yes. We haven't figured out how to solve that for them. That's a problem that's not too hard to solve. Yeah. I think more than anything we're kind of focused on the end. So developing a Rails application isn't really a difficult thing to do. It takes some skill and it takes some time, but it's definitely a lot easier to do than using some other application frameworks. So we're focused on the harder part, which is deploying and maintaining once it's out there. Right. At the moment, what are the different components you have in your portfolio for doing those things? Yeah. The main component we've got, the flagship one, is Manage. As you mentioned, we're coming out with a new version of that. Manage provides for production operations, whether you might be a developer that's managing several apps in production or you're actually a dedicated operations person. We provide the ability to monitor those applications in production, get feedback on what their status is, and drill really deeply into what's going on with them from a Rails and Ruby perspective, and then see how they fit into a larger ecosystem of other components like MySQL or Apache or what have they. Right. So what do you think about the Rails application? I mean, is it, I mean, if I just had a naive straw man, I mean, is it, it's gotta be more
2:01than just like your database is down or something like that. I mean, what, what does it get to that makes it Rails management versus just normal management? Well, the, the, the quick answer to that is, is we drill really deeply into, uh, what's going on within the Rails framework and your code's interaction with that. And we are able to instrument all those key points, allow you to set all sorts of triggers to say, um, tell me, send alerts out when certain, uh, thresholds are crossed. So that, um, you can use some of the existing triggers that we have out of the box, or you can start to customize them and say, well, I really need to know if this part of my application is behaving in a certain way. I want to be notified of that. Right. Obviously that the more, the more straightforward piece, which is, well, tell me if a piece of my environment is down, like you said, that's, you know, that's pretty standard. Um, but what's key for us is to really talk about how we drill down into the Rails world and tell you, uh, you know, what you can hook up to, what you can monitor, and then generate events and feedback for you so that you can go fix some things. Yeah, we do a lot more than just say, it's broke, which is, which is the other approach. Yeah, right. Um, and we let you know what's broke, at least as far, as far as a, uh, as a computer can tell you. In what context did it break, so we let you take a look at, you know, what happened in MySQL at the same time, what happened in your OS at the same time, um, so you have a little bit firmer of an idea and you can, you can follow, you can follow up and try to figure it out. Right. The typical, sort of, um, what would you call it, sort of sibling technologies that people end up having in Rails, and we mentioned the database, and one would, one would assume that you have Apache or a web server running, but I mean, what are other things that, that you guys manage that, that, uh, that might be running alongside these things? Uh, Memcache is a good example. The funny thing with Rails is, it's not just a cut and dry framework and here's your, here's your box and it just runs. There's a lot of things that end up running along with it in the ecosystem, so. Right. Besides your OS and your database, there's a, there's a lot of things that you might run alongside. Memcache is a, is a really, really simple example.
4:01And there's a wide range of web servers that you can use with it. And we try to take care of all of that for you. Right. That's an interesting, sort of, difference from, say, like, J2EE, where it's, sort of, you're locked down as, as what, uh, the sanctioned things to run. And so, I mean, as, and when you guys are thinking of different technologies to support, what's sort of the heuristic you go through to say, like, oh, we should support Memcache, or we should support this other thing, or something like that? To some degree it is subjective. Um, it's certainly not a mathematical formula we can just punch numbers into and see what comes out of the other side. Yeah. But, you know, being hooked into the community, I think, is an important part of, of what we do. And so, we, we see what the community is really interested in, what they're using, and, uh, some of the leading companies, what, what they're focused on, and what they're supporting. And what we've found, not surprisingly, is that the community is, um, you know, passionate about what they're doing. They don't have a problem giving us feedback and saying, you know, we're really interested in this widget. Please help us with this, support this widget. So, um. I think developers have no problems with opinions. Yeah. That's right. Absolutely. And so, you know, obviously we want that so that we can figure out what the next thing... And as that community matures more, I mean, what are you finding the...is the task of managing and deploying things a lot different, or are there sort of...is it sort of like old wine and new bottles, or is it new bottles with old wine? The idea being that, um... I guess it's more like moonshine sometimes. There you go. That's right. So it's new stuff. But, you know, you can always...there's always a very salt-encrusted, or yet to be salt-encrusted people might say, this is the same old stuff, just different... I think people are trying a lot of new ways. I mean, and, you know, I think you're eminently more qualified about this than I am. However, you know, my, my sort of perspective is people are trying new ways about, about stuff. They're challenging the convention about, well, you always got to do it this way. This is the way they did it in, you know, favorite language 5, and 10, and 15, and 20 years ago. Yeah, I think there's a real danger in assuming that the best practice from something else is going to work just fine here and now, too. Sure, sure. So that's the whole Cargo Cult concept. You were talking about this earlier, and maybe you can shed some more light on it, but there's a certain new thing you can do with the dynamic nature of Ruby itself that really would be
6:07thought of as insanity. Right, people's minds occasionally, yeah. There's a fine line between insanity and genius. Absolutely. So you have to drill the line. Yeah. You have to be a little careful. I mean, it's one of those things, a double-edged sword. So it does open up a lot of doors, but it does open up a lot of dangers as well. Right. And I think that's kind of where we do come in. We try to at least, the thing is when you're dealing with a dynamic language, sometimes these problems don't pop up until you're in production. Right. So you can do all the testing that you want to in your development environment, but once you start adding weird new data from customers and it's up running in some slightly different configuration, which is different from everybody else's because there is no standard, you know, things pop up that you don't expect. Well, I think that actually sort of points out a reason why, you know, going and having deep rails monitoring, you know, the sort of integration of the rails and Ruby world and the components is really important. It's because unlike, you know, non-dynamic languages, unlike frameworks in the past, there's a desire, there had been a desire in sort of the larger technical community. Let's figure out everything. By the time we go to production, it's frozen. You stamp it out. It's really a distribution issue. Right. It's a manufacturing issue. And, you know, it's like a car. We've sent it out and, you know, maybe we need to touch up the paint when we dig it. But after that, it's pretty much still a car, you know, with the dynamic nature that we've got with Ruby. And there's a lot more possibilities and a lot more things that can change, that can be connected, you know, with the data and having the right tools to be able to give you insight into that. You need tools that are a little more tuned in that perspective than the more conventional sort of systems management, systems monitoring tools. They really need to understand the fact you're dealing with a really much more dynamic. And it seems like the main sort of technological difference is you guys actually, well, you guys, one who would be doing this, meaning you guys in this case. It's a royal we. That's right. Yes. That's the thing that you're managing and monitoring rather than like more traditional approaches don't so much instrument.
8:08They treat the components at some level as a black box. Right. And we're, you know, we're not thinking of that world as a black box, just the opposite. And when we go to think about things like MERB, you know, when we actually instrument inside the Rails framework, you know, A, we're using the stuff, you know, we're actually, oh boy, I'll use that cliche phrase, we're eating our own dog food, right? Sure. Because we're using these tools in production. We're monitoring our own stuff in production. So the instrumentation we get, we're immediately, of course, turning around in our own little feedback loop and saying, is that data that we're getting out for, you know, this interaction here really interesting and relevant to us? Right. So it has to pass sort of that giggle test. But, you know, we're actually in there trying to figure out what's the right kind of data. And there are, you know, pretty regular dialogues about, yeah, we got that number out, but that's a goofy number. So do we really need to put that number out? Or is there some other aspect that we need to surface that's going to help people understand? Really have, you know, I think the world, because of the dynamic aspects, really moved away from this sort of treating all these as fixed, already baked black boxes. You just don't need to worry about it. You deploy them and you get someone at the other end of the console who's not necessarily caring about what's inside that black box. I think the sort of Rails and Ruby world demands at this point that the consumer of some of that information does have sort of propensity to think, well, this isn't just a black box. I do want to know what's in there because it is going to change, even from an operations point of view. I see this is going on. I need to change some of my operations infrastructure. That's interesting. I mean, it reminds me of anecdotes I always hear about Amazon, or always. Not that I hear them every day, but every now and then I hear about Amazon where there's essentially more of a philosophy of if you write the code, you own the code and production. Additionally, in management, there's more of a split between the developers and there's a giant wall that the code gets thrown over to operations. Yeah. And I mean, I wonder if that, you know. That would be nice. Yeah. That was good. And I'm sure being a SaaS company, it seems like SaaS companies run like that, absolutely, just because they seem to run like that.
10:10But in your customer base, do you find people are having this splitter? When I first got here, you know, we've all sort of been around the web 1.0 and there's web 2.0 and all of that sort of tag. And then we sort of sat back, I think, some of us and said, well, yeah, we understand what developer 2.0 looks like, right? It's Ruby. It's agile. It's dynamic languages. It's, you know, very short, rapid feedback, iterative cycles. We had a product that supposed what we, you know, don't stick by this name, but, you know, sort of an Ops 2.0. What does Ops 2.0 look like? Right. Are they the classic ops guys who have drunk the 2.0 Kool-Aid? Are they developers who also happen to pick up ops stuff? We don't really know. And that's part of what we're finding out when the product goes out there. But a lot of people that are using our product, I think, have developer sensibilities. If not, they are developers themselves. Right. So they're more prepared to deal with it. At least at this point. We'll see if it changes in time when we have a lot more corporate interests and we've got some more of these traditional structures that pop up. Right. That have pre-existing roles in hiring. Yeah. And so that's, as the wave gets larger and it starts to, you know, overtake, you know, the last Java developer to, you know, convert, you know, what happens to the Ops guys? Right. Do they, do they sort of drink the Kool-Aid and see a, and then in turn come back to us and go, you know, this isn't interesting. I need something else. Right. So, okay. You have the, the 2.0 version of Manage coming out. And so what, what's going to be in that version? I mean, what, what was the baseline of things that we already discussed sort of the baseline that's in there already sort of just monitoring rails things. Right. It's associated goodness, but, but what's the deal with the 2.0 version? Well, there's, there's a lot of things that have changed. It's a, it's a complete, completely different product in a lot of ways. Um, we've, we've taken some things out and we've, that didn't really make sense, um, in this space and we've added some things in. Um, we, we've taken out some of the, some of the corrupt your components that we, we didn't
12:12see a lot of use out of, like, uh, monitoring Tomcat, things of that nature. We've added more interesting things like Nginx, memcache, um, much better rails instrumentation, um, yeah, with a, the capability to extend that much faster, um, to new subsystems. That makes sense. We've also, I think probably the biggest change would probably be the trigger system that we have now. Um, previously we just had these kind of basic thresholds of people to be able to set on metrics and now they can kind of mix and match and create their own triggers. Um, so they can, they can, uh, they can make the events make a lot more sense to what, what their needs are. Can you say a little bit more about the difference between a threshold and a trigger is? Yeah. A threshold is just saying if, let's say the fine time, um, for a model goes over a specific time period. Right. Um, then go ahead and notify me. But a trigger allows you to say if that happens and it's in this, and it's in this controller and the following other circumstances exist, then send me an email. A lot of the time, um, before you, you do, you run the risk of, uh, of getting an event where it doesn't really make sense. Right. So now you have a lot more control, um, over, over doing that. And we come with a lot of pre-canned triggers as well. So people can just turn them on and they get a lot of benefit right out of the box. So you can essentially make synthetic events as it were, right? Right. There's another aspect of the product that, that, um, is not necessarily visible to you from the user's perspective, but it's certainly visible from you operationally. And that is, is the, the client. Um, the original client was, um, based on some technology that made its footprint very large and not matching what a lot of our customers want. The new client is much smaller, much more compact, um, and is, uh, already successfully deployed in a number of different, you know, virtual slices, um, up and down size scale. Right. Um, so it's basically, uh, a full Ruby implementation of a client. Uh, it's got dynamic updatability and, uh, it's a much smaller, much better footprint.
14:17So that was a huge. Yeah. Ninety percent smaller. I think that old technology you're talking about was a JVM. Um. The technology will remain nameless. Yeah, it will remain nameless, but it's called the JVM. Yes. We're using Ruby nowadays. Right. It's kind of, it's kind of funny to see so many developers transition from Java to Ruby and for our own client to transition from Java to Ruby as well. Yeah. So, and, uh, we actually worked with, um, with the guys over at InfoEther to, to make that happen. Yeah, that was. So Chad Powell and Rich Kilmer. There's some other great guys there to make that happen, so. Yeah. We've got a lot of usability improvements. Um, I think some of the sort of key features of those are, uh, um, we've sort of collapsed and integrated graphs. Right. We have interactive graphs now. Before we just had stock image graphs. Now we have flash graphs with interactive cursors and things like that. Oh, exciting. So a lot, a lot easier to, to cross reference. There's some, and there's some, you know, there's some elegant stuff that's in that, that while it doesn't rise to the level of being, you know, a whole feature. Um, in those graphs you can see events that have occurred. You can see triggers that are set. Right. And you could click through those graphs and go to the trigger behind that. You can go to the event behind that. And so it's, uh, it really gives you a lot more information from a single place and the ability to branch out to where you need to go. One of the feedback, uh, feedback that I got from folks when, uh, with the old product was that I had to do a lot of clicking to get to where I needed to be, where I should be able to just do, you know, a couple clicks. And obviously, you know, we took that to heart. Yeah. There's a lot of user experience feedback that kind of rolled into this release. Right, right. Yeah. That's, that's always, uh, I think every single management product I ever see has, uh, limitless usability improvements to be had on it. Yes. So that's always a nice area to improve on. Yeah. And it's a challenging, um, combination. Uh, we've got, we've had a chance to work with some really good, uh, usability folks. Right. And we've got some really great feedback. And one of the things to see is how many times, in the best cases, how you have to change context. You're on the website, you download the app, you log on your server, you come back and back and forth. Right. So how to do that in a way that, um, you don't lose track of where you're at, you don't get interrupted by the phone and then come back and yeah, I'll get to that later.
16:19So, um, we've really tried to make the flow and the app aware of the flow, uh, with respect to sort of your, your initial onboarding, launching, getting started as well as adding new systems. So we've tried to simplify that as much as possible.