Screaming in the Cloud - The New New Relic with Bill Staples

Episode Date: August 27, 2020

About Bill StaplesBill Staples is New Relic’s chief product officer, responsible for driving the company’s market-leading platform strategy and leading New Relic’s product management, engineering and design functions. Staples is an execution-focused product and engineering leader who loves to build and scale cloud-based businesses. Previously Staples was at Adobe, where he led the 1,500+ employee global engineering team behind Adobe’s market-leading Experience Cloud. Prior to Adobe, Staples spent 17 years at Microsoft, including his last role as vice president of Microsoft’s Application platform. At both Microsoft and Adobe, he successfully led transformative product, culture and technical innovation agendas, helping both companies expand multi-billion dollar cloud portfolios with developers and IT as the customer.Links ReferencedMain company site: https://newrelic.com/Twitter: https://twitter.com/bstaplesLinkedIn: https://www.linkedin.com/in/williamstaples/

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Welcome to Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Bill Staples, New Relic's Chief Product Officer.

Bill, welcome to the show. Hey, thanks, Corey. It's great to be here. So before this, you were over at Adobe, and before that, you spent a brief 17-year stint at a small company called Microsoft. Brief 17 years, that's correct. And now you've been at New Relic for a whopping six months, which in technology terms is close to about seven years. And given this whole pandemic era that we're living in, it kind of feels like it's close to that, even without the joke. It's true.

I mean, I'm starting to not feel like the newbie anymore here at New Relic. It's been an awesome six months, though. Wow, what a ride. New Relic is one of those interesting companies in that it feels like, at least from my perspective, that it's been around forever. It's a product that I used at first begrudgingly and then happily, and then I, you know, like any shiny thing, I wound up doing my raccoon act, seeing something shiny somewhere else and wandering off into the weeds. It was a really innovative product for a while. And it seemed that it was, there was

nothing else in the market quite like it. And what surprised me was how long it seemed that that lasted. Innovative product for a while, Corey. We got to get you back into New Relic. We need to win you back. That's the problem is I still have this mental model of New Relic being, oh, that's the thing you use for application performance monitoring. What is that? Well, it's a buzzword, but what it really means in practice is you open up a webpage and it tells you why your website is loading slowly or your application isn't working anymore. Right. That has always been the way I have contextualized New Relic. One of the things I see across the industry, though,

is that we have these companies like Datadog, for example, that have a monitoring strategy of, yes, whatever it is that you have to do in the world of monitoring that you could possibly do, that's what they do. And every company, for whatever reason in the monitoring space, seems to start off as doing something that is niche. With New Relic, it was the application performance monitoring piece. A bunch of other companies are focusing on the log analytics piece.

Other folks are doing synthetics. There's the idea of the Pingdom style of, is the site up or down or not? But over time, it seems that every monitoring company tends to expand into a broad-based platform of, yes, we're going to start doing all of those things as well and spreading out from the core competency. Why is that? Well, therein lies the problem. I mean, the reason for that is, you know, engineers choose the best tool for the job. And increasingly, the world has gotten more complex. Like the use case you described of you deploy an application, you want to see what's going on, so you deploy New Relic Agent,

open up a web page and see if it's running. That was so avant-garde 2008. In today's world, you've got increasingly complexity at the infrastructure layer with not only virtual machines and infrastructure as a service from public cloud providers, but container-based systems like Kubernetes. You've got increasingly a number of digital clients, not just your mobile phone, but TVs and other wearable computing and in-store advertising and all kinds of devices that deliver an experience to you. And then in between,

you've got this explosion of distributed services, services, calling services inside your company and outside your company. And whether the application or I guess the customer experience is being served or not, is not a simple question of, is the application up and running anymore? It's a question of all those layers working in concert to deliver the end user experience. And you need a more sophisticated approach to understand, is it up and running? And so increasingly, as you said, vendors and open source systems are striving to expand the capability set to cover that full stack view. And that's the journey New Relic's been on, and that's what we're doing with the New Relic One platform

and the announcements we made last week. Credit where due, the entire world has changed. When you have a system running on a single computer, it's pretty easy. Is it up or down? At some point, that narrative changes, and as we look into this world that we live in today of distributed applications, it's not, is the service up or is the service down?

It's, how down is it? And there's a monitoring evolution. I still tend to live in a world where you could say, okay, users are complaining. What is the monitoring story? And my honest answer is, what do you mean? You just told me my monitoring story. Yep, exactly. And the other factor that's, I think, playing into it is,, they want to move faster, they want to innovate. And with that complexity, the reluctance sometimes on behalf of companies to make changes in productions and put lots of barriers to ensure that the customer experience doesn't regress, slows down innovation.

So it's as much about dealing with the complexity of the application and experience architecture as it is the need to unlock developers and moving fast and being agile. Again, the only way you can do that is if you measure everything, understand how things are performing now, and then understand how they appear to be performing after, say, a deployment

with the ability to roll back if things aren't going well. So both factors play a role in terms of companies looking harder at monitoring, both to deal with the complexity and to speed up or accelerate innovation. I've got to say, one of the challenges I had with New Relic for a long time was, I was at a couple of different companies now, where there was a fixed contract price for the year, things were great, and then, surprise, apps do what they do. They get bigger because it turns out that your infrastructure footprint and by extension your AWS bill is never a function of how many customers you have, it's a function of how many engineers you employ. And it seems like there's a natural state of truth to that problem. And midway through the cycle, it was, oh, you have the salespeople reaching out with,

hey, you're using more than we anticipated. Let's settle up again mid-cycle, which was just a terrible experience from where I sit. It's, oh, great. Now I get to go and tell my boss that, A, I'm bad at managing vendors. B, I need to get more money, which is always a compelling story to tell someone who has already done their own budget. And it basically led to a lot of unfortunate outcomes as a direct result. One thing that I find really interesting about what you folks are doing this year

is you've completely revamped the pricing model in such a way that even your messaging around this is pretty much burning the boats behind you. What led to that? I think it's something I haven't seen much of in this industry for a while, and I'm actually really excited about it. Yeah, I mean, you can disrupt lots of ways, and we're disrupting ourselves from a messaging standpoint.

I think I've said, as the company who invented or created APM, we're going to be the ones to end it. We no longer sell our APM, we're going to be the ones to end it. We no longer sell our APM product as an independent product anymore. With the announcements last week, we established a new packaging and pricing structure for the new Eloquent platform. And the intention there is to just make it simpler for companies to adopt observability. The number one problem, as I spoke with customers and their ability to take advantage of observability, is the complexity and the cost of it, frankly.

They're left with this expanding set of tools and vendors to deal with. And even from New Relic, if you look at any of our competitors, it's the same thing. Up until a week ago, we offered a dozen plus different products with lots of different pricing meters. And any VP of engineering or CIO who looked at that and tried to predict, geez, how is my infrastructure going to expand across all of these dimensions? And how can I forecast a budget to ensure that my developers have the best tools and are covered in what they need to do, it was almost impossible. So it led exactly to what you described in terms of surprise bills.

And that led then to companies deciding, hey, we can't afford to monitor everything. Let's only deploy agents on the most critical layers of the application stack. Or you start sampling, like, okay, one in every 10 servers is going to have this on it, and that gives us a rough statistical overview of these things. But then that leads to blind spots, and it leads to surprises,

and no engineer wants to wake up in the middle of the night because, oh, that service didn't get instrumented, or, oh, there's an outage in part of the production, degradation of service in part of the production degradation of service and part of the production cluster that didn't have the monitoring agents until it was caught too late. And so the changes we made are directly in response to that. We believe everything should be instrumented.

And the groundbreaking product we introduced last week is Telemetry Data Platform. It's been our back-end technology for a lot of the applications that we built up over the years, but we're now exposing it as a first-class platform. It handles metrics, events, traces, and logs. We've open-sourced all of our agents and integrations. So we're doing those roadmaps now in the open and accepting code contributions from the community

to make it easier and richer than ever to capture telemetry from everywhere. We're embracing open source systems. So we've announced as well support for Prometheus and its remote write capability directly into this telemetry data platform. So you can get extended retention, enhanced security, increased scale of your Prometheus systems, PromQL as a query language on top of it, so you can ask questions of that metrics data and use Grafana dashboards on top of it, all for incredibly low price. The multi-tenant nature of our architecture and the high scale of it allows us to pass those savings on to customers so that they truly can instrument everything now in the

telemetry data platform across data types and visualize and analyze that data in ways they've never been able to before, functionally or because of the economic barriers. And it's in direct response to those challenges you mentioned. It shouldn't be so hard to instrument your digital infrastructure and be able to get answers to questions that you didn't even think about when you were building the system. I mean, that's the major shift, right, between monitoring and observability, in my view, is monitoring you deploy after the fact to detect when something goes wrong. Observability you instrument up front so that you can understand why something's happening as it's happening, or even investigate and understand how the system's performing in

ways that you didn't think about given the complexity when you were building it. One of the things that struck me when I looked into a demo of New Relic about a year ago was when New Relic 1 was first announced. It ties directly to what you're saying. I ran into enough challenges along the way when I was writing my review that I eventually tabled the thing because, and I don't say this lightly, it was too mean. I tend to have a bit of a brand for punching up at publicly traded companies when they sell things that I don't like. And it was just a, to be blunt, terrible experience start to finish. It was confusing.

The documentation on how to install it on the serverless side disagreed with itself. Talking to the support folks to get up and running, it seemed that some of them didn't know that this product existed. And it was a very disjointed story. I knew what it was going to cost, at least, because it was a fixed fee. But A, it was a lot of money. And B, the annoying part is after the demo was done, it took my normally $2 serverless app and add another $40 in AWS charges on top of that for the way that it was set up to do, to pull the monitoring and all the rest. I mean, again, it was, this is not the

end of the world stuff, but it was frustrating, and it led to a point of, oh, I guess, yeah, I'll just continue to consider New Relic from an APM perspective and move on to other things in the rest of the world. Now that you've relaunched the telemetry platform, it's, okay, this is unifying this in a way that how I try and view a monitoring product from a vendor or monitoring offering from a vendor. And now it's really coming across as, oh, okay, this is a cohesive product where someone has taken the bold step of introducing various product managers to each other. And now you finally have relaxed the NDA that prevented

internal service teams from speaking to one another. Now it feels like there really is a sense of this is an actual product offering that's aimed at user problems, not a component-by-component microservices product offering strategy that each one goes into different bits and pieces. I mean, I was, I've got to say, a little concerned at the Iopipe acquisition on those grounds of, oh dear lord, is this going to be yet another attempt at a second or third Lambda service monitoring system? No, I'm seeing integration stories coming out of this. I really should have given those folks more credit. They're great. I was a paying Iopipe customer. And it's nice to see that those folks are clearly being listened to,

as well as many other obviously intelligent folks at New Relic. Yeah, absolutely. And apologies, you didn't have a great experience the first time around with New Relic One. It was ancient history. It was more than six months ago before you were there. We'd love to have you back and give it a shot and give us feedback on, you know, if we've addressed the issues you hit. More to come on that for sure. Good, good. I definitely think we heard the feedback from you and other customers as well. And I believe we've solved some really fundamental problems with announcements last week. As you said, starting with experience, we heard that the user experience was too disjoint. We had a lot of our existing applications and monitoring tools in a separate experience from the new RelicOne experience.

We heard that it was too complex to get started and to learn to use new features. And then, as we've already talked about, we heard that the economic barriers just didn't make sense, didn't help with adoption. Yeah, and there were engineering stuff that was irritating, too. How do I install this? Oh, grab this janky script off of GitHub and run it. Okay. I read the script because you can only trick me into doing things like that once before, okay, I'm going to learn on this. And okay, read things before you run them. That's one of those things that's extremely valuable to know right after you should have known it. But it was fine. It did everything I would expect, except there was no uninstall option at that point.

It's, oh, great. Then I get to go through, see what it did, and manually remove resources if the trial doesn't work out. I have checked. That's not the case anymore. It's, okay, someone is paying attention to this stuff. It's not just a repositioning slash cash grab, if you'll pardon the cynicism.

No, this is something that is actually envisioned through a lens of what a customer wants. So I've got to say, I'm an inherently cynical person. It's nice to see it. I can tell. And speaking of cash grab, you probably saw we're offering now a very generous free tier. I think it's like 10x more generous than any other vendor out there. 100 gigabytes free ingest telemetry per month. That's great. I'm starting using my logs as a database. I've already been using DNS that way for years.

So now it's time to upgrade. Take all your logs, put them in New Relic, 100 gigabytes free per month, or metrics or events or tracing, your choice. And you get our full stack observability product on top of it, which is the complete set of APM infrastructure, digital experience monitoring, synthetics. You get full access to all of that, one user, free forever.

So no more money grabs. And I'll say to the experience question that you had earlier, one of the explicit focus points for us over the last several months as we prepared for this launch is the out-of-box experience and the minutes to joy. We had a goal of five minutes to joy. We want any engineer to be able to sign up for our new offering, get into the experience. Automatically, we provide a built-in data set. It's actually kind of an interesting data set. We've aggregated all of the public API calls that our customers are using across all of our customer base. And we actually provide analytics

on all of those public API endpoints and how they're performing. So you get an out-of-box data set that's kind of interesting to explore, built-in dashboard, so you can kind of see the capabilities of New Relic dashboarding and visualization,

explore that, and then begin to ingest your own data from more than 300 different sources of telemetry and start to create your own dashboards and dive in to understand how your own systems are performing. Like that five minutes to joy, that simplicity of experience has been a big focus for us. And we hope people take advantage of the free tier to check it out. So I have to ask, because this is the sort of thing that no one is ever going to ask in a formal CNBC-style interview, because they have this thing called, you know, tact. I'm going to come out and ask it. How the hell did that fly?

When you're sitting in an internal strategy meeting and someone says, now listen here, you know how we normally charge people a whole bunch of money and put them into contracts? So it's A, charge them a lot, B, know what it's going to cost, and C, be able to book that revenue for several quarters out. Yeah, we're going to get rid of all of that and just charge people for what they use instead and still be employed 20 minutes after saying that. How did that happen? one of the new relic values and i have to say i've been you know at some pretty great companies but new relic lives its values more than any company i've been at one of our values is bold and this was a really really bold decision you know we we spent a lot of time not only coming up with that idea but validating with. So before we ever rolled it out, we did, as you can imagine, a lot of customer studies. We've done pilot deals. We made sure that what we were doing was actually solving customer problems as opposed to making a great

PR move. And that's what gives us the confidence to take these lumps in terms of uncertainty in the market to really serve our customers. Because we believe when we serve our customers in the right way, it'll pay off in the long term. So that's what we're doing. I have a complicated relationship with usage-based pricing models just because it comes off as being, in general, yes, it can be a lot less money. I mean, I look at it through a lens of AWS as a general rule. But the problem is it is virtually impossible to predict. And you wind up with thinking you're doing everything right, and then finance has a general rule. But the problem is, is it is virtually impossible to predict. And you wind up with thinking you're doing everything right, and then finance has a minor question about why month-over-month spend is up 20%, and the answer is always the data

warehouse. But looking at that from a perspective of, especially during these unprecedented times, as we've taken to calling them, it does have a very customer-friendly aspect to it that I hadn't really appreciated until confronted with a worldwide pandemic, where I have a number of customers who have a infrastructure strategy where, all right, their user traffic has dropped off of a cliff, and their infrastructure scaling and spend has not because of how things were structured and how they were built. We're hearing horror stories from other companies in the space where their entire model is that they are not letting customers do any contract adjustments whatsoever. Because you sign the line, you get to pay for it at the end.

Usage-based pricing, like what you're doing, solves for that. And that's really kind of a neat lens to view this through because it winds up becoming such a, I guess, such a friendly story of you pay for what you use. If you don't like what you're paying, use less and the problem solves itself. Absolutely. And there's an extra dimension of the way we structured our usage-based billing that I think is worth calling out because you pay for what you use. But one of the challenges, even in that model, is if the meters that you're being charged for are hard to predict, it's really hard to budget for. And if you look at the meters in any public cloud provider and also maybe some of our competitors, you can see examples of that. One of the choices we made early on is to say one of the most predictable things that every company

has is their people costs, their headcount. Typically, those don't go up and down very wildly. And so as we looked at a pricing model for our full-stack observability product, which for most companies will be the majority of their spend with New Relic, we intentionally chose that as a metric, A, because it's used very commonly in other industries. You think about, for example, sales teams with, say, Salesforce as a software service. They charge based on the number of users, the number of salespeople. Very predictable model, very common.

If you look at, say, the design industry with, say, Creative Cloud from Adobe, again, you pay by the user for your enterprise to access all your designers can access the Creative Cloud tools. Same thing now is true with observability. You can now essentially cover your engineering team with access to the full stack of observability tools that we provide. For one price, it's extremely predictable and you only pay for what you're using. So if your engineers are getting value of it, then you pay for it. If they aren't, then you don't pay for it. And we love that kind of mutually beneficial or reinforcing value proposition, right? Like, if we're not giving you enough value that incents your engineers to want to use it, then you shouldn't pay us. And we're motivated to create more value. And in return,

customers are willing to pay for it. So that's an exciting change. It resonates. I mean, my least favorite software that I use right now is Tableau. And the reason is because it's a per seat license and it's on a year or multi-year contract, which means that every time I'm sitting here saying, oh, we've hired someone new, do they need access to Tableau or not? The tool's incredibly useful and it's good. And there's really nothing else quite like it, But it's an investment decision. Every time, I have to weigh the trade-offs of those things. Because the price is not small, especially as you continue to scale up.

Getting away from models like that, where, well, I have this new application I'm launching. Do I want to wind up splurging on licenses for new Relic with it? I mean, I will say, part of me, I'm cynically going to miss the days where it was charged per instance, because in the early days, before everyone fully understood how AWS Lambda worked, I could spin up 20,000 concurrent executions and have it reporting into the New Relic library.

And then later that day, which is superhero speed underpants, outside the pants of style for enterprise software people, you'd have one of the salespeople calling me and the hardest challenge was not making a cash register sound with their mouth. And now it's a very different story. The world and markets understanding of how software is continuing to evolve has itself evolved. And now it's just this, it's a much different universe. It seems that now rolling out something like New Relic can also increasingly become a bottom-up strategy

as opposed to being something that has to go through procurement in the traditional style of determine your usage before you roll it out for anything more than a POC. Absolutely. Shouldn't observability just be part of the basic engineering process? We take for granted now a vast array of developer tools, source code control systems, issue tracking. There are many open source versions, many commercial systems, tools that are free, GitHub, wildly popular. Shouldn't observability be the same way? Engineers can

adopt as basic part of their tool chest, use it where they want, and then companies pay for what kind of coverage they want to have for their employees and deploy it everywhere and instrument everything so that they're not left with surprises and waking engineers up in the middle of the night because they couldn't afford to monitor everything. One question I've always heard from folks, whenever you talk about a software product or anything that aligns with selling something that is consumption-based, SaaS particularly, well, what happens when AWS decides to compete with you? It's always a fun story.

I mean, in the monitoring space, I don't hear it nearly as much because the easy, obvious rejoinder is, let's get them to update their status page in a timely manner first, then we'll worry about how they're going to magically fix all of my other monitoring and observability challenges. But I'm curious to get your take on that.

Is Amazon going to try to compete with you is probably the right question to ask. You know, they've got CloudWatch and they've got monitoring and other tools. So does Microsoft. You know, I think every smart public cloud provider will provide out-of-box monitoring tools for their services. Again, it's an essential part of providing a service nowadays. However, customers are often multi-cloud, and customers are not all in the public cloud.

And so you need a system that can span clouds and span your on-premise data centers and your public cloud instances. In fact, the very nature of observability of measuring things is you want to measure the differences between those environments, right? And especially as you're moving applications or services between environments, you need to understand, is the performance going up or down or being less reliable? And so we think there's a very strong need to have an independent cross-cloud observability vendor, and New Relic strives to be the best one. I'm really excited to see where it winds up heading from here. The market seems to like it so far, but the challenge is that it's super easy to get positive responses and everyone to say nice things when the engineering effort involved is more or less a press release. I think it's really going to come down to how the market responds once people start seeing how this works for themselves. I will say, having done an analysis of the pricing model, I don't see too much to complain about there at all. So I'm eager to see what happens.

Well, I am as well. And we hope you give it a shot. We'd love to check it out and let's do a future podcast on your experience. If it goes well, then you'll be allowed as a visionary. If not, you're going to be invited to one of those fun meetings where someone from HR you've never met before is sitting there and they don't offer you coffee. That's always the warning sign. Last question for you before we wind up calling this an episode. Right now, as you look at New Relic across the spectrum and analysts being analysts and all the rest, what do you think is currently being the most misunderstood about the company? I think, you know, some of the sentiment and maybe some of it's earned is, I've heard the old relic sentiment

that New Relic is the 8 p.m. vendor of yesterday. You can't call it old relic. That's not an anagram of the founder's name. Well, that's true. That breaks that pattern. But there's some sentiment that New Relic's best days are behind it. I am definitely a believer

that the best days for New Relic are ahead. And it's been so exciting to be part of the reimagination of not only the New Relic One platform, but the company. I mean, we talked about the bold pricing changes that impact our business model. Not many companies would be willing to take that kind of risk. And New Relic, like I said, lives our values. Bold being one of them, we've made some really big changes. And it's just the start of really exciting things to come. So I'm excited by the future of New Relic. Well, I'm looking forward to seeing how it shapes out.

Again, if it goes well or if it doesn't, I'm going to be here either way, casting stones from my particular corner of the world in which I produce remarkably little. Well, have fun doing that and stay in touch because we want to hear how it's going along the way. Oh, you'll hear, unfortunately. That's what Twitter is for. If people want to hear more about what you have to say and what you're up to, where can they find you? I'm bstaples on Twitter, and you can search for my name on LinkedIn. Hard to find. Perfect. And of course, newrelic.com is where people can go

to kick the tires on your new offering if they want to try it out for themselves rather than listening to me cast slings and arrows from a place of relative impunity. Yes, go to newrelic.com, click on one of the many free buttons to try it out. Again, it's not a trial. It's free forever.

And we'd love to hear what you all think. Thank you so much. Thank you. Bill Staples, Chief Product Officer at New Relic. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. Whereas if you've hated this podcast, please leave a five-star review on Apple Podcasts. Whereas if you've hated this podcast, please leave a five-star review on Apple Podcasts and a comment, and one of our enterprise sales reps will reach out to you in three to five weeks.

This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever Fine Snark is sold.