We at Engine Yard could not be more stoked about our partnership with New Relic. Tune in for Tom’s interview with New Relic CEO Lew Cirne—his insights on production visibility and the entrepreneurial spirit are not to be missed. Take note, because we’re sharing the love with Engine Yard customers by offering New Relic RPM Bronze for free! Tom: Our guest today is Lew Cirne, CEO of New Relic.
Lew: I really have to thank you personally for giving me a kick in the butt in late 1997 to take this prototype that was a precursor to the New Relic RPM and bring it to market. I think it was your sponsorship of the idea that made me really decide to take a run at this. It’s been a great relationship we’ve had over the years.
Tom: I appreciate that. All I remember doing is just being blown away and saying, “Man, you’ve gotta do this thing, because everybody needs it.” It was really impressive when I saw it, and I think it’s ten times more eye-opening now than it was today. So, congrats on all the hard work you’ve done. Can you give our listeners the New Relic “elevator pitch”?
Lew: Sure. I guess the easiest way to describe what New Relic does is to say that we’ve got the production tool that developers love. And what I mean by that is we provide production visibility into live web apps that is incredibly deep, and allows development teams to solve the kinds of production and performance problems that usually they can’t solve without trying to recreate the problem in a development environment, or crawl through log files for hours and days to find the clue as to why their app might be slow in production. The way we do that is we provide, through software-as-a-service, we have a web app that collects an enormous amount of performance data from over six thousand customers from our agent. And what our customers do is they install our agent into their app and the agent provides automatic instrumentation that reports on exactly what the app is doing 24/7, including where it’s spending it’s time. Then our customers can log into New Relic RPM to see the performance data and make good judgment calls as to what they need to do to fix performance problems, to fix availability problems and make their app delight their users.
Tom: I think that’s one of the key differentiators, as I see it, from the traditional way of doing things. Production is so critical, because you can run things like JMeter, or AB against a staging instance but it’s very synthetic and you don’t get the real-world usage patterns.
Lew: That’s absolutely right. It’s not to say that load testing isn’t important, or that profilers aren’t useful—but we believe there’s no substitute for true visibility in terms of what’s going on in production. You can never predict what your users are really going to do to your app, and of course your production database schema will often look different from what you try to create in a staging environment. So there are all sorts of reasons why you need the kind of visibility that we provide from the live production web app. If you’re relying solely on things like load testing or profiling in controlled environments, you’re basically on thin ice when it comes to your ability to deliver consistent performance for your end users.
Tom: I know that our support guys at Engine Yard, if they get a customer who has a performance problem, the first question we always ask is: are you using New Relic? It’s the 90% solution to identifying the problem almost every time.
Lew: We’re delighted to do that. We love partnering with Engine Yard, and we love providing software that helps your customers be successful and reduce the possibility of finger-pointing when there’s an absence of data as to what’s really going on. People tend to go to their gut feeling and suppositions and that’s where you get tension between various constituencies. It could be development vs. ops, it could be the platform provider vs. the application developer. We find that the ultimate mechanism by which you can get teams on the same page to collaborate and be successful is to provide the data that everyone can agree on.
Tom: Can’t we all just get along? In the past, we had a different economic arrangement. I think we purchased services at a discount and the new agreement that we just signed states that our customers get Bronze for free. Let’s talk about free a little bit. Why is that important to New Relic?
Lew: We’ve always had a free offering, which is Light—and Light will always be free for anybody who just wants to sign up for New Relic on their own—and to be clear, lots of customers find great value in Light. But Bronze is one level up from Light. And if you want to come directly to New Relic you can purchase RPM Bronze for as many servers as you run your application on. But like every other IT vendor, we believe that the cloud is just this incredible trend in which we want to participate, have mindshare and have ubiquity. We look to partner with the premium players in the cloud space and obviously Engine Yard is one of those companies. So we are willing to work out an arragement to provide something as valuable as RPM Bronze to Engine Yard customers with the belief that due to the higher value that you can get from Silver or Gold, customers who are really serious and that have an exposure to a high-value product like RPM Bronze are likely to become New Relic customers at a higher level. And we’re willing to do that based on the fact that the cloud trend is something we want to ride.
Tom: I think it’s a wise choice and I know our customers are going to appreciate it a lot. It’s always fantastic to be able to provide useful tools.
Lew: There’s a tendency in companies that people don’t really respect where there’s a little bit of bait-and-switch in their business practices where the claim falls far short of what they deliver. We want to flip that and over-deliver on our claims with the hopes that that turns into long–term business relationships as we grow our customer base.
Tom: Since the very first time I heard about Rails, I was also hearing all these questions about scalability. Though you guys have extended far beyond Rails itself, what do you see as the most common performance issues in Rails applications under monitoring?
Lew: The most common issues in Rails are also common issues in virtually any common web app that has layers of abstraction in the framework. That is, so long as there’s software development, there’s going to be evolution toward higher layers of abstraction in the development framework, meaning faster time to market. But that, by definition, means less transparency on exactly what your code is doing at run-time. You contrast what assembler code did thirty years ago when you knew what every instruction did and exactly how much it cost, to today when you call an active record “person.find,” and you add one extra param to the cache in that argument and all of a sudden you’re missing an index. And you may not notice that problem when you’re running on your development box when there may be a hundred rows in your table. But when you go into production you’ve got a couple million rows in that table. That’s a big problem. And that’s all sort of abstracted away by the beauty of active record, where you can do person.find. So, I love active record, I love abstraction layers, but what you need to keep in mind when you adapt these accelerants into time-to-market, through development technologies, is that it comes with a cost. That cost is that there is going to be a lack of transparency on what your app does at run time, which is a worthwhile trade-off, because time-to-market is so important and because today’s compute infrastructure allows you to run at very high speeds. But you need to know what the impact of your code is in production and where the hot spots are. So find the five percent of your app that is taking up time and diagnose it.
Tom: If we could get a little more specific, is it database queries that we’re talking about here?
Lew: Database queries is a great example of it. It could be a poorly formed query. Another great example is just too chatty with any backend system. Even Memcached. Memcached is lightning fast. In most operations it could be sub-milisecond. But it’s not faster than memory lookup in the same process. So you’ve got to be aware of when you’ve got loops of interprocess communications, even to fast systems like Memcached. And if you’re going over the cloud to an external system that could be in a remote datacenter, then you’ve got even higher latency issues.
Tom: I hate to speak as the eyes of age, but I tell young developers all the time that one of the problems with modern development is the answer to almost everything is, “Oh, that will be easy to do.” Now that everything’s easy to do, the problem is there’s just so much to do. Everything used to be really hard, but you only had to do one or two things. Now there’s twelve thousand things to do—you’ve got to sort out which ones are really important. So you write the app, and New Relic gives you the ability to quickly get to the hotspots, to where the bottlenecks are.
Lew: Performance problems tend to be app-specific. Therefore, app performance management is totally different from infrastructure performance management when you look at six metrics: CPU, Load, IO, etc. Right? In the app, you need to have application-centric metrics which allow someone with some familiarity with the design of the app to find out what the key parts of the app are that you need to pay attention to. So what we tried to do was put together the data in a form that makes it easy to come to that conclusion in your own app.
Tom: One thing we talked about the first day we met is, that performance gurus have always said, you cannot optimize until you measure. You measure first. And that’s what New Relic does—it gives you all that measurement, and then you can specifically go out and optimize the critical parts. New Relic is very much a cloud company, Engine Yard is a cloud company. The combination of the two allows a new kind of application development. Where do you see this headed, if you could just kind of put on a futurist hat?
Lew: I’m incredibly excited about this moment in time for the technology industry and for entrepreneurs. As a small company, we don’t have any on-premise software. All of our documentation lives in cloud-hosted services. What that means is, it completely lowers the upfront and ongoing cost of doing business at a high level. As someone who founded a company in ’98, that was a classic direct-enterprise sales company, we had to raise an awful lot more money and hire an awful lot more people, to achieve an awful lot less. And much of that was because the delivery of the software was on-premise, it involved a lot more hand-holding in our go-to-market. The fact that we’re in a cloud model now and we deliver our software over the web, we can sell a lot more efficiently and that means a lower cost for our customers. So as a cloud provider I can see a lot of efficiency there, and as a consumer of cloud technologies, our IT spend is far more manageable, predictable and lower than it was in the company I founded in ’98. We’ve got better products that are continually improving over time, because we’re subscribing.
Tom: As a serial entrepreneur like you, it’s incredibly cool to me to follow our EY Cloud Twitter account and to see a constant drumbeat of new functionality, bug fixes and whatnot coming out, as soon as they’re ready. It’s a beautiful feeling. It feels much more like the product is alive and is meeting the needs of the users than it used to—it used to be kind of a scheduled thing.
Lew: The customer has a problem with it and the vendor has a problem with it, because they’ve got to support back-versions of the software. So nobody wins when you’ve got on-premise software when you’ve got a Cloud alternative.
Tom: In the past, I kind of wondered what our customer base was. It was easy to say web developers and that sort of thing because those were the people we spoke to most often, particularly early on. When I was doing a lot of sales myself I was almost always speaking to the business people. I think that both New Relic’s and Engine Yard’s customer bases, and probably most cloud customers in general today are in one very solid group which I’m happy to be a member of, a group which has finally gotten its own national holiday—Entrepreneurs. I believe there was a book written called, Once You’re Lucky, Twice You’re Good, and I believe that qualifies you as good. Congratulations on that. What is it that has allowed you to do this twice?
Lew: I guess it may be an affliction rather than a talent. But I feel like there’s unfinished business with this problem that I started solving in ’98. As a bit of context, the company I founded in ’98 was a company called Wiley Technology, which took a bet on a then-fledgling technology: Java. The goal was to put production-visibility into Java web apps to help people diagnose problems and performance issues. We did it with on-premise, heavy-weight Java software which, for it’s time, was innovative and groundbreaking, but which now looks rather dated, like when you watch Seinfeld and you look at the computer on Jerry’s desk and you can tell…
Tom: He did have good computers, though.
Tom: So at this point, you’re probably well past the ten thousand hours of mastery in the startup phase. Are there any words of wisdom that you have for fledgling customers?
Lew: If you don’t love what you’re doing don’t even bother trying it. You’ve got to be so in love with the idea. I think that the most likely chance that your idea is going to resonate with the market is if it really solves a problem that you understand well. Wiley, my previous company, came out of my development experiences with Java and the challenges I had understanding how that Java app ran in production. I kept noodling on that problem to solve it for myself, and when I came up with an idea that I thought was an elegant solution, then I asked whether I thought that other people would be adopting Java in the next five years, and would they have this problem. If you can conceptualize a problem that you don’t have a visceral feeling for, I think that on a shoestring budget you’re less likely to develop a compelling solution for that problem. Look at 37 Signals. They developed Basecamp as a solution for themselves. So that’s the advice I’d give. Let your passion for the problem you solve be a vehicle by which you attract great people. They need to get passionate about the cause. You need to be open to making this a joint effort, not your personal effort, so that you attract a world-class group of people who, as a team, can build something magical.
Tom: Did you see the Michael Jackson documentary that was released posthumously?
Lew: I did.
Tom: I’d never put it this way myself, but I love his line, “For the love.” He really makes a huge issue out of it, and it shows in his work—in kind of a strange, genius, Michael Jackson sort of way. But it’s for the love, which is what you’re saying. So congratulations on loving application performance and thanks for doing so.
Lew: Thanks. It’s a strange affliction. I have no idea why I’m so consumed by solving this problem, but it’s what excites me about coming