 Okay, we're back here inside theCUBE. I'm John Furrier with Dave Vellante, here inside theCUBE, our flagship program. We go out to the events, extract the synth from the noise. We'd love to be here with Velocity or Riley Media Conference. We're joined with Patrick Lightbody. Welcome to theCUBE. Thank you. So a lot of geeks here at this conference, and it's a very tight knit community. So it's not a big vendor show. You know, in the sense of, you know, here's our marketing strategy. So my first question for you, because you've written about open source, you've been involved in a lot of open source projects. You're on the development side, but you got to look at the landscape. Share with the folks out there, what is Velocity Conference all about? Yeah, so, you know, tagline of course, web performance and operations, but it is, it's really about a community coming together and kind of working through huge changes in the landscape. I mean, this morning in the keynote, the two co-chairs were up there talking about, you know, how much has changed in Velocity from 2008 in the first conference to 2013, you know, the size of the conference, the different vendors and sponsors. But of course, you know, the biggest changes are things like, you know, the iPhone had just come out. I mean, you know, it's kind of weird to think about the, you know, you look around, everyone's got a smartphone. And you know, just when this conference got started, smartphones, apps wasn't, there weren't even things people were thinking about. The iPhone was closed at that point. You couldn't build apps for it. And this community's had to work around it. Web performance has completely changed too, right? Applications are all about AJAX and super fast interactions and things that are changing right on the page without reloading. And that presents all sorts of new problems for developers in terms of monitoring, optimizing, making sure that their users are getting the places they want to go. And so, you know, looking around here, whether it's the vendors or whether it's in the sessions or just in the hallways, it's people getting together and sharing tips and saying, oh, you know, web sockets, that's really hard to monitor. Here's the things I'm doing to make sure it's staying up. Actually, web sockets, we were at the Fluent Conference a couple weeks ago and that wasn't really talked about much, but the hallway conversation was very much, web sockets are back in vogue. You got, you know, with no JS exploding on the scene. I mean, why is something like web sockets so important now? I mean, it's like, you think, okay, well, okay, web sockets, no big deal. Hey, old school browser stuff. Well, I mean, is it because of the native OS on the browser? I mean, what's the, why is that hot? There's a confluence of things happening. You know, browsers are becoming so much more powerful. You know, you can run, just the other day, I was looking at a demo of Epic, the video game company, released the Unreal Engine to run in a browser, entirely in JavaScript, with a little bit of support from the browser. You know, that's crazy thinking about what JavaScript could do just a few years ago. So people know they can push the boundaries in the browser and in doing so, you also then, if you can snap the UI around, bring things up quickly, you also need the data to come quickly and the request response model of traditional HTTP doesn't lend itself really well to that. And so people are looking at long polling, open connections, web sockets, but on the other side of that, that is monitoring it and testing it. And it is a challenge, you know, there's Chrome DevTools, Firebug, and you go look at a web page that has web socket interaction going on, nothing shows up in those things right now. You see one connection, and you know data's flying back and forth, and nothing's visible. And so this conference is also about dealing with that evolving landscape and the tools that we've relied on just six months ago, maybe need to be rebuilt, reimagined, and that's what people are doing here in these hallway conversations. So Patrick, you're giving, I think, three talks at Velocity, right? Is that, so talk about the talks a little bit. What are you going to be talking about? Obviously, you know, performance monitoring and the like, but give us some detail as to what you're going to be talking about. Yeah, sure. I've got two tomorrow. One is, it is part of my company, New Relic, as our sponsorship. We get five minutes up on stage to say something. Personally, I don't like vendor talks, so I try to keep it interesting and fresh. So still working on exactly what it'll look like, but the basic gist of it is code is everywhere now. It used to be, you know, kind of had this really tight control over where your code was running. And now, you know, not only is code, obviously, in the browser and on mobile applications, but you've got old versions of your code that you can't take back that are running on people's old iPhone 3s and iPhone 4s. The code is all over the place. The infrastructure we use is becoming more programmatic. You can write recipes for Puppet and Chef that deal with how you deploy your stuff. And, you know, without us realizing it as an industry, we've really diversified and spread our code all over the place and it's hard to manage it all. So I just, my main theme is know where your code is and be aware of it and be tracking it all. Don't just imagine that your Java app server is the thing you've got to pay attention to. I just tweeted it. I just had to tweet that because I just love that epic quote, you know, code is everywhere. You know, one of the things Dave and I are really passionate about is obviously DevOps and we use the Durham infrastructure as code. And, you know, and one of the things that we were talking with earlier about John, with the co-chair earlier, John, was that the blending of design at the front end and infrastructure is now not decoupled. You have to kind of integrate that together. And so you have coders who want infrastructure to be like code. And you've got infrastructure who want to provide services for the coders, right? So that's a collision course, right? And that's what, you know, the web browser stuff is interesting, right? Because now you have an edge device, edge operating environment that's fast, low latency with no web sockets. So putting that together, how do you talk to someone? Because when you talk about the iPhone in 08 and, you know, we go back and I was actually with Sergey Brin when he launched Chrome and I looked at him and said, it's an operating system. He said, no, because that's the messaging. No, it's not an operating system. And the browser, he smiled and had smirk on his face. But that's what it is. You're talking about code. That was only in 2008. The world has changed so much. So how do you explain to the folks out there, you know, IT guys, geeks who aren't in the trenches like you guys who run under the hood doing this innovation. How do you explain to them about this trend? Infrastructure is code and code is everywhere. How does that conversation go like get to the future? You know, it's, there's a lot of things going on. I mean, there's like code.org, right? There's all these, you know, new startups and nonprofit organizations trying to encourage people to code. And they suffer from the same problem because they're trying to say, you know, software is like the English language. You know, it used to be 20, 30 years ago if you wanted to succeed in international business, you know, you had to learn English. Well, now they're saying you've got to learn software. You've got to know how to code. And so Chris Bosch, Chris Bosch was on one of these videos, you know, he was just playing in the NBA finals game six and he was a software engineer major before he went into the pros. And so everyone's got to kind of learn it. You made a nice block at the end of the game yesterday. That's for sure. Yeah, that's right, that's right. And so I, you know, what I tell people is, look, you know, you're coding, even if you're in a spreadsheet, a lot of, you know, a lot more people are in Excel than they are coding. You're still coding, right? You know, you might be more advanced. You might be doing VLOOKUPs, but the reality is, is that we need to figure out ways to bend machines to our will. And what we're doing as an industry and what the people here at Velocity are doing is they're finding ways to deliver value to the customers faster. And so that means we've got to automate. We've got to, you know, automatically respond to things. We've got to decipher through gobs and gobs of data. And that's all that's happening. It's- You know, I got to ask you, I had to jump off, Dave's going to finish the rest of the interviews. I had to jump for a meeting, but we always talk about agile. We love agile, it's a great message. Hey, agile this, but agile is sometimes a shortcut for QA, you know, that's something that's soft for your spot. What does agile mean? Push code, you know, Mark Zuckerberg has the phrase break stuff. It's okay, just ship code and what we'll iterate. Iterate means, you know, people are bypassing QA. Then you got mobile, where mobile user experience is a little bit different. People aren't downloaded in the apps, they're not updating experience. So a bad user experience on mobile is a little bit different than web, all the refresh to page, right? So, you know, agile and mobile and then obviously QA and automation, these are really important things. Can you share the current state of the art and your vision around how to make great QA, how to automate in this agile mindset on mobile and changing web environment? Well, I think it all comes back to what's your risk profile. This morning we had a great keynote on risk management and risk assessment, you know, and not just for web apps, but risk in general. There was, you know, some great pictures up there of the, I think it was the Concordia that crashed off the coast of Italy. And, you know, you picked up on it right away, right? Mobile, it has a higher risk because you can't react to problems. You know, if there's a bug that ships or a performance issue, you might have to take a month or two to get even your earliest adopters back on the next version. Whereas a web app, you know, I'll just deploy my hot, you know, hot deploy my fix right now. You know, and even in the web app space, it varies, right? Job apps. But Android has auto updates, or do they? Some of them do, and certainly, you know, you see Apple, well, Apple's getting there with the next version of iOS 7. They're finally getting auto updates out there. But even then. The users have the older version, they have to update. There's, you know, users that need to upgrade their OS. There's people on older hardware. There's people who choose not to do it. There are people who, well, there's also the whole approval process. So even if they're auto updating, it could take a week or more to get the version out. So you're going to take an old school pre-packaged software mentality to QA because what you're saying is you might not get those guys back. If there's a problem. You've got to be a little more careful. And it's not just for mobile, but any software application. I'll tell you, at New Relic, most of our software sass, but we do ship agents that run inside of the application. And so we have a very different risk profile for half our team, which is shipping software once a month. And they know that upgrades take a long time versus our other half of the team, which is doing a web app and data collection services. And so, you know, our QA controls in those two different teams are very, very different. But one last thing I'll say about mobile and making changes. It's something that developers, I would encourage them thinking about writing their mobile apps to be able to respond to changes. And so the more you can shift out application logic that can like pick up from a web service and choose to display a menu or not display a menu or maybe we'll cut off ads, if you can remote control some of that kind of stuff, you're in better shape because you don't need a whole new mobile app to be downloaded. You know, there's only so far you can go with that with mobile apps, but developers are starting to pick up on that trend that some knobs and dials, it administratively to control the mobile experience really helps. So how do we get there from where we are today? Is that something that we have to kind of rip and replace the existing infrastructure that's out there or code? Yeah, I mean, there's a lot of work we're going to have to build up. And again, that's why this conference is here. You know, no one person knows how to figure all that out and involves too many pieces, right? Apple controls, for example, on the iPhone apps, they control a lot of the widgets and the controls that people use to display popups and screens and whatnot. And then all along the stack, you've got push messaging players like Urban Airship, who shares our development headquarters in Portland, Oregon where New Relic is also based for development. And then of course you get all the way through the network layer and the application layer and they all have to kind of be part of the conversation. What I can say is that we probably are re-imagining how we ship code, distribute code, monitor code, all of that, we're going to probably have to take three or four looks at it over the next few years and rebuild it. And so it's an exciting time. Hey Patrick, you referenced Yohan Bergstrom's talk this morning, which was really good. He's extremely articulate and talking about risk. And early on in this presentation he talked about the pretty simple formula of how you measure risk. It's a risk as a function of, let's see, so the probability of some event occurring and the severity of that event, which is a normal sort of way to measure risk. We talked about sort of code being everywhere now. Risk in code is by its very nature now is distributed. So what does that do for that equation? It certainly must, I would think, increase the probability of an event occurring. But maybe each individual event is smaller. I don't know. I wonder if you could comment on that in the context of that simple formula that Yohan put forth. Yeah, I think the basic formula certainly still applies. But when you dig into asking the questions, like to input those variables, right, you need to know what's the cost of the problem, what's the likelihood of it. And that's not simple to figure out. His example he had up there I think was 4%, a range from like 4% to half a percent of a failure for four square. $35,000. Yeah, there was some real simplifying in some sense. But where did 4% come from, right? And you know, I'm not at all saying that he trivialized it, but what I mean is that you've got to ask the questions. And the first step is being aware of it. In one of my other talks yesterday or, you know, what were some of the other talks I'm doing. The one I gave yesterday was all about visualizing performance data. And a key theme I kept coming back to was that it's all about adding new dimensions to the way you look at things. And, you know, there's a lot of people in these conferences that say, well, you know, average response time's not a good thing to look at. You've got to look at percentiles and histograms. And that's important. But you know, the reality is even averages can be pretty good if you look at it, you know, you peel back the layer of the onion, right? Looking at the average response time of your total application is one thing. But if you look at it broken down by, say, code paths that the code can go through, or by customer base and revenue by your top customers and your free customers, I think the same goes for code. You can't just say, oh, we got to monitor it, or we got to, you know, we got to be, you know, we got to add QA on. You got to ask, well, what are we testing? Are we testing those automation scripts or are we just assuming someone's going to put together a puppet recipe and it'll be just fine. So you got to be asking a lot more questions. Well, and to your point, I mean, everybody has trade-offs, whether you're, you know, a large, you know, web company or a small company, you got to figure out trade-offs and where do you put your resources, right? That's a real challenge and thinking about, you know, that simple equation again. It's not necessarily a disastrous event that occurs to lose money or make money. We heard the guy from the Obama for America say today that their conversion rate increased, I think he said 14% when they, you know, sped up the performance of the page by X. And that meant, you know, tens of millions of dollars. And so how do you help, you know, help us think through sort of how people make those trade-offs? And you're obviously a web performance expert. So where do I put my time and energy and resources and how do I make those decisions? Yeah, you know, a variant of that question I get a lot is if I had one thing to monitor, what would it be? And I always say, start with the user. It's got to be where the user is in their interaction because that's what inevitably leads to teasing out more areas to focus on. So, you know, a lot of people, especially in kind of the old way of building web apps, you know, instead focused on the server. You know, well, we got to watch the CPU. We got to watch the RAM because that's what they knew the most. But ultimately, does it matter if your CPU is at 90%? If your user is having a great experience? And so of course, you know, I even that I'm trivializing, what's a great experience? You know, you've got to actually ask the questions, you know, what do my users expect? But start with the user. So there's a lot of interesting talks this year. We've had it every year and it's been building up on real user monitoring, on being able to have probes inside the browser. There's a lot of companies, including New Relic, that are doing some interesting stuff with probes inside of the mobile app. And that's all focused on starting at the user and then working your way down. So, you know, Google of course gave a keynote this morning claiming, not claiming victory, I shouldn't say that. That's not fair, but basically showing evidence that the web is speeding up. And of course that's, you know, that's good. That serves sort of their goal of speeding up the web. But is it really? Is the web really getting faster? I mean, it feels like it's getting more functional. And it feels like, you know, web performance is kind of maintaining, you know, that speed with function. But it doesn't feel from, you know, you mentioned it. Look at the user, from a user standpoint, it doesn't necessarily feel like it's getting faster. What do you think? Can you weigh in on this? Well, what I can tell you is expectations continue to rise. And so, you know, I think we, you know, our response times are getting, you know, going down, but our expectations are going up. And so, from a total perception, it may be closer to flatlining. You know, I know my father, who's not super computer savvy, he said the other day, you know, if a page takes more than a few seconds to load, I just move on. You know, I can't stand those ads, he says. And he's, you know, that's a, that's, that used to be a impatient type of mentality that was reserved more for the early adopters. And now everyone assumes that. So there's a, there's an expectation level, you know, game keeping up with expectations. But the other piece too is the technology is changing. Even our ability to measure the speed of a page load, for example, you know, Ajax, you know, this is not new technology these days, but what a lot of people are doing is they're making their web apps more complex. And so they're bringing data in just in time. But most of the tools that measure page load time still are assuming paid, the onload event from JavaScript is the thing to measure. And yet the thing you really care about might be coming three or four seconds later. And as an industry, we're still wrestling with how to measure that. You know, we've been talking about, amongst my peers, browser, you know, entropy, pixels, you know, what shows up on the screen, it's getting hard. Yeah, what you're saying, when do you actually stop the clock? We know when to start it, but when do you stop it? Yeah. So in the meantime, onload is the best we've found, but that it's got to evolve. Hi, Patrick like body. Thanks very much for coming to theCUBE. Really a pleasure meeting you and good luck with your talks this week. And we'll be watching. All right, keep it right there, buddy, we'll be right back with our next guest right after this. Thank you.