>>Live from San Diego, California. It's the cube covering to clock in cloud native con brought to you by red hat, the cloud native computing foundation and its ecosystem. >>Welcome back to the queue bumps to men. And my cohost is John Troyer and you're watching the cube here at CubeCon, cloud-native con 2019 in beautiful and sunny San Diego today. Happy to welcome to the program a first time guest, Tom Willkie, who's vice president of product ECRO funnel labs. Thank you. Thank you so much for joining us. All right, so it's on your tee shirt. We've been hearing, uh, customers talking about it and the like, but, uh, why don't you introduce the company to our audience in a, where you fit in this broad landscape, uh, here at the CNCF show. Thank you. Yes. So Grafana is probably the most popular open source project for dashboarding and visualization. Um, started off focused on time series data on metrics, um, but really recently has branched out into log analysis and tracing and, and all, all of the kinds of aspects of your observability stack. >>Alright, so really big, uh, you know, broad topic there. Uh, we know many of the companies in that space. Uh, there's been many acquisitions, uh, you know, uh, recently in this, um, where, where do you fit in your system? I saw like databases, like a big focus, uh, when, when I, when I look at the company website, uh, bring us inside a little bit. Yeah. As a product to the offering. The customers most, um, >> most, most vendors in this space will sell you a monitoring product that includes the time series database normally includes visualization and some agent as well where pharma Lampson Griffon open source projects, very focused on the visualization aspects. So we are data source agnostic and we have back ends for more than 60 different data sources. So if you want to bring together data from let's say Datadog and combine it with some open source monitoring from, you can do that with. >>Uh, you can, you can have the dashboards and the individual panels in that dashboard combined data from multiple different data sources and we're pretty much the only game in town for that. You can, you can think of it like Tableau allows you to plug into a whole bunch of different databases for your BI with that. But for monitoring and for metrics. Well, so Tom, maybe let's, before we get into the exit products and more of the service and the, and the conference here, let's talk a little well on the front page of your website, you use the Oh 11, why word? So we've said where it's like monitoring here we use words like management, we use words like ops. Observability is a hot topic in the space and for people in a space that has some nuances. And so can you just maybe let the viewers and us know a little bit about what, how the space is looking at this and how you all feel about observability and what everybody here who's running some cloud native apps needs to actually function in production. >>Yeah. So I think, um, you can't talk about observability without either being pro or, or for, um, uh, the three pillars, right? So people talk about metrics, logs and traces. Um, I think what people miss here is that it's more about the experience for the developer, you know, Gruffalo and what we're trying to achieve is all about giving engineers and developers the tools they need to understand what their applications and their infrastructure doing, right? So we're not actually particularly picky about which pillars you use and which products you use to implement those pillars. But what we want to do is provide you with an experience that allows you to bring it all into a single, a single user interface and allows you to seamlessly move between the different sources of data and, and hopefully, uh, combine them in your analysis and in your root cause of any particular incident. >>And that for me is what observability means. It's about helping you understand the behavior of your application in particular. I mean, I'm, I'm a, I'm a software engineer by trade. I'm still on call. I still get paged at 3:00 AM occasionally. And, and having the right tools at 3:00 AM to allow me to as quickly as possible, figure out what happened and then dive into a fix. That's what we're about over funnel labs. All right. So Tom, one of the things we always need to understand and show here. There's the project and there's the company. Yep. Help us just kind of understand, you know, definitely a difference. The products, the, the, the mission of the company and how that fits with the project. So the Gruffalo project predates the company and it was started by taco. Um, he, you know, he saw a spot for like needing a much better kind of graphical editing of dashboards and making, making the kind of metrics way more accessible to your average human. >>Um, the final lab started really to focus on the it and, uh, monitoring observability use cases of profanity and, but the project itself is much broader than that. We see a lot of use cases in industrial, in IOT, even in BI as well. But Grafana labs is a company we're focused on the monitoring side of things. We're focused on the observability. So we also offer, we mean, like most companies, we have an enterprise version of. It has a few data sources for commercial vendors. So if you want to, you want to get your data dog or your Splunk into Grafana, then there's a commercial auction for that. But we also offer a hosted observability platform called Grafana clown. And this is where we take the best open source projects, the best tools that we think you need as an engineer to understand your applications and we host them for you and we operate them for you. >>We scale them, we upgrade them, we fix bugs, we sacrifice the clouds predominantly are hosted from atheists, our hosted graphite and our hosted Loki, our log aggregation system, um, all combined and brought together with uh, with the Gruffalo frontend. So yeah, like two products, a bunch of open source projects for final labs, employees, four of the promethium maintainers. And I'm one of the promethium maintainers. Um, we am employee graphite maintainers. Obviously a lot of Gryffindor maintainers, but also Loki. Um, I'm trying to think, like there's just so many open source projects. We, uh, we get involved with that. Really it's about synthesizing, uh, an observability platform out of those. And that's what we offer as a product. So you recently had an announcement that Loki is now GA. can you talk just a little bit about Loki and aggregation and logs and what Loki does? >>Yeah, I'd love to. Yeah. Um, a year ago in Seattle actually we announced the Loki project. Um, it was super early. I mean I just basically been finishing the code on the plane over and we announced it and no one I think could have predicted the response we had. Um, everyone was so keen and so hungry for alternative to traditional log aggregation systems. Um, so it's been a year and we've learned a hell of a lot. We've had so much feedback from the community. We've built a whole team internally around, around Loki. We now offer a hosted version of it and we've been running it in production now for over a year, um, doing some really great scale on it and we think it's ready for other people to do the same. One of the things we hear, especially at shows like this is I really, I really, you know, developers and the grassroots adopters come to us, say, we really love Loki. >>We really love what you're doing with it. Um, but my boss won't let me use it until it goes to be one. And so really yesterday we announced it's Don V. one, we think it's stable. We're not going to change any of the APS on you. We, uh, we would love you to use it and uh, and put it into production. All right. Uh, we'd like to hear a little bit more about the business side of things. So, um, I believe there was some news around funding, uh, uh, you know, how many people you have, how many, you know, can you parse for us, you know, how many customers have the projects versus how many customers have, uh, you know, the company's products. Well, we don't, we don't call them customers of the projects that users, yes, yes, we, uh, but I'm from a company where we have hundreds of customers. >>Um, I don't believe we make our revenue figures public and, uh, so I'm probably not going to dive into them, but I know, I know the CEO stands up at our, our yearly conference and, and discloses, you know, what our revenue the last year was. So I'll refer you to that. Um, the funding announcement, that was about a month ago. We, uh, we raised a great round from Lightspeed, um, 24 million I believe. Um, and we're gonna use that to really invest in the community, really invest in our projects and, and build a bit more of a commercial function. Um, the company is now about 110 people. I think, um, it's growing so quickly. I joined 18 months ago and we were 30 people and so we've almost quadrupled in size in, in the last year and a half. Um, so keeping up is quite a challenge. Uh, the two projects, uh, products I've already touched on a few hundred customers and I think we're, you know, we're really happy with the growth. >>We've been, uh, we've never had any institutional funding before this. The company is about five years old. So we've been growing based on organic revenue and, and, and, and, you know, barely profitable, uh, but reinvesting that into the company and, and it's, yeah, it's going really well. We're also one of the, I mean it's not that unique I guess, but we're remote first. We have a more than 50% of our employees work from home. I work from my basement in London. We have a few tiny like offices, one in Stockholm and one in New York, but, but we're really keen to hire the best people wherever they are. Um, and we invest a lot in travel. Uh, we invest a lot in, um, the, the right tools and getting the whole company together to really make that work. Actually a really fun place to work. What time? >>We're S we're still in the business here and I don't know how much time you've spent at the booth this year, but I don't, can you compare, I mean, we've been talking about the growth of this community and the growth of this conference. Can you compare say this year to last year, the, the people coming up, their maturity, the maturity of their production, et cetera. Are they, are they ready to buy? Are they still kicking? Are they still wondering what this Cooper Cooper need easy things is, you know, where, where is everybody this year and how does that, how has it changed? Yeah, and that's a good question where we're definitely seeing people with a lot more sophisticated questions. The, the, the conversations we're having at the booth are a lot longer than they've been in previous years. The um, you know, in particular people now know what key is. We only announced it a year ago and gonna have a lot of people asking us very detailed questions about what scale they can run it at. >>Um, otherwise, yeah, I think there is starting to be a bit more commercial intent at the conference, some few more buying decisions being made here. It's still predominantly a community oriented conference and I think the, the, I don't want that to go away. Like, that's one of the things that makes it attractive to me. And, and I bring my whole team here and that's one of the things that makes it attractive to them. But there is a little bit more, I'm a little more sales activity going on for sure. Any updates to the, to the tracing and monitoring observability stories of the projects here at CNCF this year since you as you're part of the promethium project? >> Yes. So we actually, we had the promethium conference in Munich two weeks ago and after each committee conference, the maintainers like to get together and kind of plan out the next six months of the project. >>So we started to talk about um, adding support for things like exemplars into Prometheus's. This is where each histogram bucket, you can associate an example trace that goes, that contributed towards that, that history and that latency. And then you can build nice user interfaces around that. So you can very quickly move from a latency graph to example traces that caused that. Um, so that's one of the things we're looking to do in Prometheus. And of course Jaeger graduated just a week ago. I think. Um, we're big users of Jaeger internally at for final amps. And actually on our booth right now, uh, we're showing a demo of how we're integrating, um, visualization of distributed tracing, integral foreigner. So you can, you know, using the same approach we do with metrics where we support multiple backends, we're going to support Yeager, we're going to support Zipkin, we're going to support as many open source tracing projects as we can with the Grafana UI experience and being able to seamlessly kind of switch between different data sources, metrics all the way to logs all the way to traces within one UI. >>And without ever having to copy and paste your query and make mistakes and kind of translate it in your head. Right. >> Tom, give us a little bit, look forward. Uh, you know, a lot of activities as the thing's going to, you know, graduating and pulling things together. So what should your users be looking for kind of over the next six to 12 months? >> That's a great question. Yeah, I think we do a yearly release cycle for foreigners. So the next one we're, we're aiming towards is for seven, like for me to find a seven's going to be all about tracing. So I really want to see the demo we're doing. I want to see that turned into like production ready code support for multiple different data sources, support for things like exemplars, which we're not showing yet. Um, I want to see all of that done in Grafana in the next year and we've also massively been flushing out the logging story. >>I'm with Loki, we've been adding support for uh, extracting metrics from the logs and I really think that's kind of where we're going to drive Loki forward in the future. And that really helps with systems that aren't really exposing metrics like legacy systems where the only kind of output you get from them is the logs. Um, beyond that. Yeah, I mean the welds are kind of oyster. I think I'm really keen to see the development of open telemetry and um, we've just starting to get involved to that project ourselves. Um, I'm really interested to kind of talk to people about what they need out of a tracing system. We, we see people asking for a hosted tracing systems. Um, but, but IMO is very much like pick the best open source ones. I don't think that's, that's emerged yet. I don't think people know which is the best one yet. >>So we're going to get involved in all of them. See which one's a C, which one's a community kind of coalesces around and maybe start offering a hosted version of that. >> You know, our final thing is, uh, you know, what advice do you have for users? Obviously, you know, you like the open source thing, but you know, they're hearing about observability everywhere there are, you know, the, the whole APM market is moving this direction. There's acquisitions as we talked about earlier. Um, there's so many moving pieces and a lot of different viewpoints out there. So just, you know, from a user, how do you know, how will things ma, what makes their lives easier and what advice would you give them? Yeah, no, definitely. I think a lot of vendors will tell you like to pick a, pick a vendor who's going to help you with this journey. >>Like I would say like, pick a vendor you trust who can help you make those decisions. Like find someone impartial who's gonna not make, not try and persuade you to buy their product. So we would, uh, you know, I would encourage you to try things out to dog food and to really like invest in experimentation. There's a lot going on in, uh, in, in the observability world and in the cloud native world. And you've got to, you've got to try it and see what fits. Like we embrace this, uh, composability of the, uh, of the observatory of, of the observability ecosystem. So like, try and find which, which choices work best for you. Like I, uh, whenever, whenever I talk to him, you still have to lick all the cupcakes in 2019. I think. I mean, I would, it depends on your level of kind of maturity, right? >>And sophistication. Like, I think if, uh, if, if this is really important to you, you should go down that approach. You should try them all. If this is not one of your core competencies that may be going with a vendor that helps you is a better approach. But, but I'm, I come from the open source world and, uh, you know, I like to see the, um, the whole ecosystem and all the different players and all the different, new and exciting ways to solve these problems. Um, so I'm, I'm always going to encourage people to have a play and try things out. All right, Tom, final word, Loki. Explain to us, uh, you know, when you're coming up with it, how you ended, uh, are you the God of mischief? Well, so the official line is the Loki is the, um, is the North mythology equivalent of Prometheus's, uh, in Greek mythology and, and lochia logging project is, is, is Prometheus's inspired logging. So we've tried to take the operational model from, from atheists, the query language from, from atheists and, and the kind of a cost efficiency from, from atheists and apply it to logs. Um, but I will admit to being a big fan of the Marvel movies. All right, Tom Willkie. Thank you so much for sharing the updates on, on the labs. Uh, we definitely look forward to hearing updates from you and thank you. All right, for, for John Troyer, I'm Stu Madmen back with more coverage here from San Diego. Thank you for watching. Thank you for watching the cube.

>> Narrator: From New York City, it's theCUBE, covering New Relic FutureStack 2019, brought to you by New Relic. >> Hi, I'm Stu Miniman and this is theCUBE at New Relic FutureStack 2019 here in New York City. It's our first year of the event, but the event itself has been around for seven years and to help us end our coverage, no better person than the founder and CEO of New Relic, and the one who the name of the company came from, Lew Cirne. Of course, Lew Cirne is an anagram for New Relic. >> Indeed it is. >> Lew, thank you so much for having theCUBE at the event here and thanks for hosting us. >> I'm a huge fan of theCUBE. I've been watching it for a long time and it's such a pleasure to have you guys here. Thank you for coming. >> All right, so Lew, you're known as the coding CEO >> Lew: I am. >> And you come out with a vision of making software better. It's a great goal. Give us a little bit about the state of the industry. You know the internet challenge these days. It's going to fragment into a bunch of pieces and Open Source isn't what it used to be. There's so many changes going in the industry. Just kind of macro view before we get into New Relic. >> Yeah, from a macro view at New Relic we do this for the love of software. It's not just me, it's the whole company. We believe in software. We think it unquestionably is changing the world, transforming every industry. It's not enough just to build software that's great. You have to deliver more perfect software. That's now become almost obvious whereas when we first started out that was actually a bit of an evangelical sale where we had to convince people that they needed to observe their software. Now it's become a must-do thing, and that's why observability has become a household term. Everybody recognizes that anything that runs in production in internet scale needs to be observed, needs to be measured in real time. And so, that's been going on and has become a must-do thing for our customers. What we're so excited about is that we're delivering the first observability platform. What do we mean by that? Well, we see with this proliferation of tools, you might have metrics going to one place and logs going to another place and traces going to Zipkin or logs going to Elasticsearch. You want it all in one place, and more important, you want it to be connected so that you can see the relationship between the application and its server or infrastructure and the user experience all in one connected platform. That's what we're delivering with New Relic One today that's so exciting. >> Yeah. So, Lew, the IT industry in general is known for its fragmentation. >> Lew: Yeah, it is. >> When I want to build my application in the old days, I talk to the CIO. He's like, "Give me a million dollars and 18 months "and I will build you the Taj Mahal of my application." And we've got it beautifully designed and pull it out. Well, today things are moving much faster, but I've got everything from that Taj Mahal to the Kubernetes and Serverless, Microservice Architectures-- >> Lew: All that compartment-based stuff, yeah. >> There's usually a lot of different teams, and a lot of different tools in there. How does New Relic fit across that landscape and how are you helping to pull things together? >> Well, certainly the industry's moving from the monolithic application to the component-based application, often running in smaller and smaller services, usually running in something like Kubernetes or a containerized environment and with that comes a proliferation of things to monitor, and often a proliferation of tools. We have enterprise customers that have 20, 30 different monitoring and telemetry tools. It's not because they want it, it's because there might be one particular feature that one tool does that gives them the visibility they need. And what they want is a single platform. What people have historically used New Relic for is dropping our agents into their application or their infrastructure. Then our agents automatically put visibility in and then they report on the health of that system. We do that really well, but what we're announcing today is that we're opening up our platform to consume telemetry from Open Source, agentless sources. So that, if you've got something like Prometheus that's gathering data from Kubernetes, that can go straight into New Relic and be treated as first class data, so that you don't have to switch between a bunch of tools. None of our customers want that. They want it all in one place, but they need an open platform that's connected and most importantly programmable so that they can actually have one tool to see it all. And that's New Relic. >> A lot of the logging and tracing information out there isn't agent-led. What do you see as the future of agents, and what are some of the challenges of pulling all of these various data types together? >> Well, the most important thing for the future is that our customers have complete control in a choice. What we see particularly in large enterprises is they want both. They have a portfolio of more than a thousand applications. They want to observe them all. Most of them they'll want to drop an agent in because they don't have time to reinstrument them, but they still need to see them. Some of them they may want to manually instrument because they want a higher level of control or they want to adopt an Open Source API like OpenTelemetry. But then, if they're adopting that for some of their portfolio, when a transaction reaches across these different services, you don't want to lose visibility. We're delivering best of both worlds. You can manually instrument what you want. You can use OpenTelemetry in parts of your environment. And then you can also use our automatic instrumentation that comes from our agents. Our customers get to decide, and that's the future. >> So, Lew, you've laid out the case in a strong way as to why New Relic One should be the platform for the monitoring observability. I think you undersold a little bit the NRDB piece. When I look inside my business or I talk to customers, being able to see my data and act on my data can be challenging. You showed a demo of 10 terabytes and being able to change it in a snap. >> You know, NRDB is pretty magical. At some risk, let's see if this will show up on my phone right now. Just give you a sense of how fast NRDB is performing right now. Okay. One more time. So we've got-- >> Hold it up a little bit and show the camera this way. >> NRDB right at this moment is inserting 18 million events every second. Every second, 17.89 million pieces of data coming into NRDB in real time. And our customers are querying that in real time. Right now, in this moment, they're reading 24 billion pieces of data per second. Those pieces of data could be log messages. They could be someone pressing something on their app, could be a request going through a server. It's all in the same database. And the last one is a hundred millisecond response time on those queries, which is mind-blowing for these analytics queries. >> You actually showed the press an analyst this at lunch and it was over 20 million-- >> I think it was at 40 billion at that moment. >> 40 billion coming out and the same response time. A hundred milliseconds is Google good as to how fast I get a response. >> For this kind of data processing, it's mind-blowing. Now, the thing that our customers need to know is that all your metrics, all your events, all your logs, all your traces going into the same database with one query language. That's so much better than going to Elasticsearch and using its query language for logs, then using a totally different query language for getting at your metrics, and then trying to stitch it all together. We put it all not only in one cloud but in one database. That is the most powerful telemetry database in the world, which is NRDB. >> Lew, give us a little bit of the journey to the announcement today. Observability's been talked about in the industry for a while. VC money has been pouring into startups. There's been some acquisitions in this space already. Give us a little bit as to how we got to today. >> So how we got to today was when we started off as a company, we were championing the whole idea of observability, putting visibility into application code. As I said, that was a bit evangelical in the early days. People were wondering if they needed it. Now there's no question they need it. In fact, some people need it so badly they want complete control, and so they're manually instrumenting. OK, I've talked about that. Now where we see people going is now that all of this telemetry data is coming ideally into one place like New Relic, our customers are saying, "I need to go beyond dashboards. "Dashboards are good, but often dashboards are incomplete "to get the most out of the data we're collecting." That's why we're claiming we have the first and only platform for observability, with a capital P. What do I mean by that? It's only a platform if you can build software on it, and New Relic One is the first software development platform for observability applications. Our customers can take all this data and build real-time applications that leverage all the value out of it. When a customer buys something online, New Relic's database could be the first piece of, certainly, analytics database that sees that data. So you could a navigation that shows real-time sales for your business people all based on New Relic One. We can also solve all sorts of IT operations problems by building applications on this platform. And to prove it out, we're offering 12 free Open Source applications to anyone. They can download, they can clone them off of GitHub and push them into their New Relic account and they can use that as inspiration to build their own applications on top of our platform. >> Right. This is, if I understand, the first twelve, and you expect both New Relic and your customers will build many more. >> Yes, and actually it's thirteen already. We just added another one today. Some of those have been built by our customers already, and we're already seeing customers deploying these applications into their New Relic One accounts in production today. >> It really goes back to the promise of SaaS is that when customers need something and make a change or build on it, it's not just that customer that gets to be able to leverage that, but everybody else that is on the platform-- >> They can share and benefit. The way to think of it is, you're absolutely right, and without Force.com, Salesforce is just a CRM system. But with Force.com, companies could really leverage all the data inside Salesforce. Without programmability, ServiceNow is just a ticketing system, right? But how does ServiceNow become strategic? By allowing people to build applications tailored to their business. We believe the world needs an observability platform and the only one of its kind is New Relic One. >> All right. So, Lew, it sounds like this should be something that should accelerate growth for the company going forward. I read through your last earnings report. You're growing at 30, 35%, which is reasonable but less than the overall cloud marketplace itself is growing. So, how come the AWS, Azure, GCP tailwind isn't pushing New Relic faster? >> Well, it is a good tailwind for us, and I can't go into too much detail. We're a public company in a quiet period so I can't speak to specifics. What I can tell you is history has shown that people tend to adopt platforms at a certain rate and then, a few years later, they adopt the management technologies for those platforms. So we tend to be a little bit behind the adoption of cloud but then when people standardize and they go all in on it, then they really increase their investment in New Relic. I believe that things like our platform capabilities take our customers that might be spending... We have 850 plus customers that spend more than 100,000 a year with New Relic, and I believe when they start to adopt our platform and go strategic with us, many of them will be million-dollar customers, and that ought to be the basis of durable growth for the company. >> All right. So, Lew, there was some news leading up to the event. Some management changes. Let you speak a little bit of that, and you've got some history with, of course, Mike was already on the board, but-- >> We're so thrilled about Mike Christenson joining the company as President and COO. I've known Mike since 2006, when he acquired my last company, Wily Technology, which was really the very first APM company. Mike was the President and COO of CA, and so he had a similar role there to what he has here. Mike is, I think, one of the most brilliant operational minds I've ever met. He's been involved with New Relic for nine years. He's been one of the first investors in the company. He's been on our board of directors, and he's always had a keen mind for how to think about growing our business. I've been thinking for a long time on how to get him more involved as a member of the team and finally I convinced him to come join. Mike joined us as our President and COO. He's going to be my partner in growing the business. I think those that know me know that I love technology and products and thinking about where we are five years from now. Mike will be my partner to help make sure we're operating the company and growing the business on a day-to-day basis. >> Lew, you and your team helped create and democratize this wave of APM, Application Performance Management. As you look at it today, we talked about microservices. You talk about the dispersed nature of everything going on. How would you reframe the market today and New Relic, where it needs to be today and going forward? >> Phase 0 was people-monitored servers, back in the Stone Ages. Monitoring was just "Is the server up or down "and does it have enough CPU?" >>Blinking lights. >> Right. Then came APM. APM really was the precursor to observability. It was the notion that these are complex systems. They need to be observed at high granularity. APM gave birth to observability, so when New Relic first came along, we're "Let's democratize APM." And as observability came along, we saw this as an opportunity to open up the platform. Now where we are, if you look at our track record, first of all, my first company created the category of APM. New Relic then democratized APM, and now we're delivering the first observability platform. I believe that the future is programmable, and that New Relic is the future. >> Lew, you've always been enthusiastic when it comes to the vision that you put out, but it's been noted by some of my peers that your energy level and enthusiasm is even higher today than usual. So many things that you talked about, some of the things that you highlight, maybe behind the scenes, or things that might get missed beyond the headlines that you want to share. >> The idea for New Relic One was born two years ago. I took some of the brightest people in New Relic offsite and we fleshed out the thinking and the early prototype of what's become this. This is my life's work. This company's my life's work. I believe so much in this platform. I believe in its capabilities. I'm seeing our customers ripping it out of our hands, saying, "This is going to enable us "to fully achieve our goal of complete visibility "and completely tailored to the needs of our business." Why I'm so fired up and passionate is when you put your heart and soul into something that's new, that no one else has done before... There's been a handful of times I've done that in my life. The first time became APM. The second time became New Relic. The third was when I created NRDB. And now the fourth is New Relic One. And we're just getting started. >> Well, Lew, I want to let you have the final word as to what you want your customers taking away here from FutureStack 2019. >> My belief is that the future of observability is you need a platform. That platform needs to be open, connected, and programmable. We have such a beautiful, easy... It's a Heroku-like developer experience. So within seconds, you can be building an application that takes the telemetry data in New Relic and turns it into actionable business insights for your company. And if you want inspiration, there's 13 applications now up on GitHub that you can install right into your New Relic account, and maybe modify and tailor to your needs and republish to share with our other customers. >> I know you and your team are making sure that New Relic doesn't become a relic of the past. Thank you so much for having us here-- >> We're always in the future. >> And congratulations. I look forward to watching the progress going forward. >> Thank you, I enjoyed it. Thank you. All right, bye-bye. >> Thank you so much. And that's a wrap theCUBE's coverage of New Relic FutureStack 2019. I'm Stu Miniman, of course. Go to theCUBE.net for all of the coverage. A big thanks to the team here and everyone supporting and as always, thank you for watching theCUBE. (Electronic Music)

(electronic music) >> From New York City, it's theCUBE. Covering, New Relic Futurestack 2019. Brought to you by New Relic. >> Hi, I'm Stu Minamin and we're here at New Relic's Futurestack 2019 in the middle of Manhattan. Right next door to Grand Central Station at the Grand Hyatt. Right next door to Grand Central Station at the Grand Hyatt. Happy to welcome to the program, first time guest, Nadya Duke Boone, who's the vice president and general manager of application monitoring here at New Relic. Thanks so much for joining us. >> You're welcome, it's great to be here. >> All right, so, a lot of announcements this morning. Of course, observability front and center Lou talking about how that fits into this space. You have handled really kind of the APM product inside New Relic, so I'm hoping you can help us understand kind of the journey that New Relic's going on. And I've heard in the marketplace, you know, there's AI ops, and there's observability in all of these things. And, you know, APM was the old world for the monolith. So, you know, how does New Relic help live across all of these environments that customers are living in today, and you know, undergoing so much change and new things? >> So as Lou talked about this morning, we think to be an observability platform like New Relic 1, you've got to be open, connected and programmable. That is, we think about that within the application monitoring space, um, we really think it comes down to the matter and issue of like, what are the questions you need to ask. And that really depends on like what stacks you need to see and what are the questions you need to ask. And so, I think it's a false dichotomy to say you need to like, pick a side in observability or monitoring. I think it's really a yes/and. You don't have to pick a side. And with New Relic, what we're able to do whether using our agents and all the rich data they give you or they're using our open platform, the important thing is that we're able to bring it all together in one place. So you can get all your questions answered. >> Yeah, I spent lots of time in my career trying to help break down silos. You know, the traditional infrastructure world, the networking and storage and compute teams. >> Sure >> You know, virtualization helped pull some things together. Software tends to be a unifying factor, but when I look at, you know, the people that own application and the developers. I mean, you've got monoliths, you've got this containerization in microservices coming. You've got the new serverless environments here. You've got a lot of fragmentation inside the customers. How does that impact your business today and are we going to see those, you know, pulled together over time? >> Yeah, what we hear from customers is that, you know, they're going to be running heterogenius environments for a long time. If you're over a year old company, you're not running a single tech stack. You've made choices for your business needs and you need to be able to see across your whole estate. And where New Relic's adding value for our customers, is by bringing this all together and connecting it. So, you can actually see, let's say from a lambda function and our lambda agents, all the way back through your Java monolith and down to the server whether it's running containers or on bare metal, you can see all the way down. And then you can connect it out to you front end as well. And I think it's that ability to see across, is where we're playing. >> All right, uh, can you bring us inside your customers? What are some of the challenges they're facing? And how do you help them along those transformations that they're undergoing? Cause, as you've said, they're going to have this heterogenius environment for quite a long time. >> Yeah, well I think one of the thing they're saying is that they're trying to move faster. And one of the ways they're moving faster is by changing the process by which they build software. So, you know, we've been talking about DevOps for years. We've been talking about Agile for much longer than years. Um, but those changes bring about new needs also, for observability. Cause now, you've got a team that maybe wants to see very deeply with, um, the things they're on call for. But software refuses to break neatly at team boundaries. It just won't, it's going to break wherever it wants to break. So you need to be able to quickly assess, across your whole enterprise what's going on and help those teams talk to you. So, that's definitely a problem we're solving for our customers now. And if I were to pick one more, that I'm hearing, um, well, I'll pick one from this morning and that's cost management, right. As people move to the Cloud, um, its so powerful and easy to be able to start up new services in the Cloud but then, do you know what you have, do you know what is costs, do you know how to optimize? Um, we announced 12 new applications this morning. One of them is addressing exactly that point. >> Yeah, um, okay, what are some of the challenges customers have really monitoring across these different environments? I think cost, it's, well, the promise of Cloud is to help me understand and control my cost quite a bit. But, you know, I understand my data center cost and, in general, much more than I do what I have in the Cloud. >> So, you mean, trying to understand in their software? >> So, I guess, just, if they have these different environments that need to span from a monitoring standpoint what are some of the challenges that customers have and the differences and how does New Relic pull those together for them? >> Well, I think some of it is bringing their teams together. If you've got folks that have a Dev accent and an Ops accent, they may have different points of view about monitoring right? And so, a Dev team might be saying lets go all in on this method or this tool. But an Ops team might be saying something else. And then as you introduce new technologies and maybe now people don't always want to run an agent. They want to have complete visibility over their software. And so, with New Relic, we're giving them those choices. We're giving them, like, hey, you can run an agent, you can, if you've already got stuff at Zipkin, cause maybe, internally, you've got like a great Zipkin champion. Like, great, we're going to be there with you on that too. So, we want to be able to help these teams come together. Um, rather than forcing them to sort of live in silos. >> All right, uh, Lou put a real emphasis talking about platform. And he said platform with a capital 'P'. >> Yeah >> Help us understand a little bit about that and the impact that's going to have for your customers. >> Yeah, absolutely, I think, you know, anyone can say I've got more than one product, therefore I have a platform I think. When we talk about a Platform, we think of software engineers, a Platform is something I can build on. So, I think a capital 'p' Platform is the ability to build apps, to be able to extend it, to be able to add data because you're open. Um, and then the power that we bring, you know, I got to put in my plug, is by connecting it all together. Um, but I think the power of the Platform, um, has been really showing off in the work that we've been doing with our customers to build these new applications. >> All right, um, you mentioned open, which was one of the three features of the Platform itself. Uh, there's open and with API'S and then there's open source can you help us tease through a little bit because there's the openness and then there's some open source pieces. How do those go together and um, I guess, more importantly, what does it mean for the customers? >> Mhmm, thanks for asking, cause I do think those words kind of got tumbled up. So, let's first, let me like tease it apart a little bit. So, first part of open, you sort of already mentioned this, is like, we're open to all data. So, metrics, vents, logs, traces, you can send that data. That's, that's the first thing. You don't have to be running a New Relic agent to use New Relic. The second part though, uh, is that we are actually building and contributing to the open source community software development kits and exporters to make it easy for our customers. And so, we've shipped, we're shipping Open Census and Drop Wizard and Micrometer and exporters and Prometheus scrapers so that these are open source tools that our customers can get, can extend if they need to, to get that data in. So, we're making it easy to get the open data in by providing these open source tools. Um, and we're in there with the communities contributing to the communities as well. And then, finally, you know, the last one is with our new programmable Platform, we are also all in on open source on that. So, we're contributing to open source for folks building on New Relic and our customers are telling us that they're excited to also be able to do that and to share and exchange with each other. >> There's value to the customer and I guess the question is, your relationship with your customer is going to change though. As they're building applications not just, you know, more than just a tool. And I've heard from many of the customers that use New Relic, is, they talk about the partnership. And it really is taking that partnership to the next level. What I say is, New Relic is not coming out and saying oh, we're an open source company and we're building our company around open source. So, you know, it seems that somewhat a maturation of the model but not open source being the be all and end all of New Relic's mission. >> Our mission is to help customers build more perfect software. I mean, that's why we come to work. Is to help them do that and we think this is the right step. Um, to be able to do that and our community around New Relic, as you said, is excited and dynamic. It's great to be here at Futurestack and hear them talking to each other and hear the buzz. I was at our customer advisory board meeting yesterday which is 11 execs from some of our biggest customers and they were talking about how excited they are to see how this is going to help them with their business cause they can connect, now their telemetry data to sort of higher order business problems. Um, and they're also excited to share. So, I think it's the right step for New Relic and our customers. >> There's a lot of startups out there that attack pieces of what New Relic's trying to deliver. Um, you know, how does New Relic look at the landscape out there and the challenge when you're trying to be a platform is, are you providing good enough solutions? Or, you know, are you providing, you know, best solutions across all of these environments? >> Yeah, I think any of our point solutions could go head to head with anything on the market. Um, you know, and the fact that the market is so dynamic is because it's a real problem space for people who are building software. So, folks are going to keep innovating and coming up with new ideas and my mission is to make sure that everyone writing software, is instrumenting it and able to observe it. So I think, I love that more and more folks are joining this conversation. I think it's a great time to be working on monitoring observability. >> Okay, uh, let's start at the top talking a little bit about observability, what should customers be looking at, should they be thinking about that? What feedback are you getting from some of your key customers? Uh, in the space in general and how New Relic's looking to address it? >> Yep, well I think comes down to, a little bit of what we talked about earlier, visibility and answerability and if I were talking to an exec or if I was talking to an engineer, and I was looking at their tools, you know, whatever level you're at and saying, what do you need to monitor how can you get that data in and can you answer the questions? Do you have the tools, the ability to query, to connect the data. Um, to see, hey there's an event that happened and how did my systems change? So I think a lot of it comes down to, is it visible, can I ask the questions? And then for every stack, and no matter what job I'm doing. >> All right, um, when we look at this broad term which gets overused some, but, digital transformation Um, the comment I've made is the long pole in the tent of going through that transformation, really is the application portfolio. You know, I can modernize my platform, I can go to Cloud, but, you know, changing my applications, especially the ones that run my business, is really tough you know. If I'm a company that's been around 15-20 years, you know, I probably have applications that are as old as the company, if not longer. >> Yep. >> Uh, just broadly, how are your customers doing, uh, are they being able to kind of, you know, move along that modernization journey of the application uh, better today than they might have a couple of years ago, or just kind of macro level? >> I think so, I think, you know, between what the Cloud vendors are doing and what we're doing, folks are getting both tools and they're also getting support. I think, you know, the community, the software engineering community is really leaning into this moment. And talking about how to do these types of trasnformations. So I think there's a lot of just, knowledge sharing going on, there's a lot of advice and consulting that you can get. And then I think the tools are lending themselves to being able to do, you know, some people move to the Cloud or lift and shift. Some people use it as an excuse to re-architect. A lot of folks pick and choose. Because not every apps work the same and some apps are, you know, are, um. For some given app, it might be a more relevant time to change it, a more relevant time to let it stay put and you can make those choices. And I think people are approaching it with a certain rational sense. >> Yeah, uh, one last question for you, New Relic's a leader in, according to, the analyst firms that look at the APM market. New Relic's doing a lot of the things that I hear from, you know, the startups getting lots of money thrown at them, so, how should customers think of New Relic today? >> I think, we're the best leading APM product on the market for a reason. And we can never rest our laurel. So I think customers should at us as a trusted partner. Who's going to continue to grow and meet them wherever they are. Our customers are going to Cloud, we want to be there first to meet them there and welcome them in the door. And that comes back to how do we help customers through digital transformation? We're a big software company. We get it, like, we are going through the same, we go through these same questions ourselves. Um, and we talk to our customers all the time. So I think for our customers, it's like, we're the platform and the right partner. Because we're never going to stop. >> Nadya, thank you so much for sharing the updates. Congratulations on the launch today and, uh, best of luck going forward. >> Thanks a bunch. >> All right, lots more here at New Relic Futurestack 2019, I'm Stu Minamin, thanks for watching theCUBE. (electronic music)

>> Narrator: From New York City It's theCUBE covering New Relic FutureStack 2019. Brought to you by New Relic. >> Hi, I'm Stu Minimen and we're here at New Relic's FutureStack 2019 at the Grand Hyatt, next to Grand Central Station, here in New York City. Happy to welcome to the program a first time guest, Roger Scott who's the Chief Customer Officer at New Relic. Roger, thanks so much for joining us. >> Thanks, Stu. Thanks for having me on. Good to be here. >> Alright so, I love this morning actually in addition to hearing all of the announcements, my first hand full of guests on theCUBE were customers. So I got to hear from them and we know your team is always excited about the announcements, but definitely enthusiasm from the customers, things in the keynote that got people. >> Fired up! Yeah. >> Clapping, and fired up. >> Great to see. >> Things like, oh wait! 10 terabytes of data, pressure thing, refresh for like a second, and >>oh my gosh! There's results. Yeah >> Pretty impressive so maybe give us a little bit of insight into customer engagement and how it's let to the bevy of announcements here at the show. >> Oh it's a great question actually and I think in my capacity as Chief Customer Officer and the functions I'm responsible for, we're continually engaging with customers as you can imagine. And one of the things we take a lot of pride in is being a proxy for the voice of the customer back into the organization. So we have a pretty rigid process. Not rigid, a pretty discipline process, I would argue, that allows us to get feedback from the field, listen to our customers, understand what's important to them, and reflect that in our product roadmap. And I'll let you know that's on a weekly cadence we do that. Now we're not doing that in a reactive fashion such that our roadmap diverts every single week in there, but we hear that constant feedback from the field as to what our customers are lacking. So lot of what you hear today, in terms of those six great announcements that we have were a combination of feedback that we've had over the last couple of years, I would argue. Because it's a dramatic shift to go from what we were previously, which was essentially six individual products that work really well together. But through the release of New Relic 1 in May earlier this year and what we announced today has truly developed us in to a observability platform. So monitoring with six different products to a true observably platform that's open, connected and programmable is a dramatic shift. And that's a combination of a bunch of feedback from our customers over the years. >> Yeah. I'm sure it's pretty much feedback from all customers. They're not asking for more tools and more interfaces and more things that they need to learn. >> Roger: Not at all, right. >> In many ways software can be a unifying feature especially that term platform who spend a bunch of time emphasizing what's needed from platform. >> Maybe, what were your costumers struggling with that kind of New Relic 1 in general is looking to solve as well as the observability piece? What went into that launch that was costumer pinpoints and things that they'd been asking for. >> Yeah maybe to stand back a little bit and understand some of the challenges that costumers had and then why they were asking for different solutions or evolution of our solution. If you think about today's world, there's this rapid development an deployment of software, so it's almost got to the point of continuous software deployment. And so your speed of needing to be able to react to problems in your environment, your costumer experience are degrading, ect. Being able to respond to that really quickly is essential, understanding the costumer experience is essential. You talked about operational efficiency of reducing the number of tooling sets or data sets that I'm looking at continually. So anything that we could provide to our costumers that allowed them to get to answers quicker, understand the why, and then be able to remediate that really easily so that the costumers have a greater experience. And at the same time reduces this friction that's unnecessarily introduced when you're going from one product to another, one tool to another and you're spending too much time rationalizing data sets across those tool sets. So consolidation is a big theme, ability to get to your answers really quickly is a big theme and that's really been the genesis of being able to create a platform. But not just a platform for consolidation, for better visibility, and observability but we believe it's not truly a platform until you can develop on it. If you think back in technology history of all the different peradams we've had throughout the history of technology, those who've won the platform wars over the years have been really good at being able to provide tools and ease of adoption of the platform by virtue of being able to build things on top of it. The ability to give people tools that allow them to build technology is really a therasense of the platform as well. >> You know, Roger, there's a certain trust level that costumers have to have if they're going to be building on top of your platform. >> When I've talked to costumers in New Relic they do talk about a partnership >> and the good back and forth but there's definitely a certain amount of stickiness once they've built something on your platform. >> Roger: Right, yeah. >> Any concerns from them as to, you know there's that term lock in out there as to the how do I know that this is going to work for me, and that I'm not going to have my pricing kind of crank up over time and be like oh my gosh, a year or two later, what did I get myself into? >> Right. It's a really important point that I'd like to start off by actually reemphasizing the point you made. I think we pride ourselves on the relationship we have with our costumers. It truly is the heart of everything at my organization does. We have this saying that we are because they are. In the realization that if we don't serve our costumers really well they have choices frequently, we're a saas vendor, the contracts come up for renewal frequently. And if you're unable to deliver on the promises that you made in the sales process, once they implement your solutions and try to use those in production, environments and everyday work if you can't deliver on those promises then you're going to breakdown that level of trust. And trust is at the center of all relationships as you know. Whether it's a personal relationship, you're playing on a sports team, whether you're working with your costumers. And so we want to make sure that we can deliver on those promises once we've sold them the product. So I haven't heard any specific concerns about lock in or anything, I think what they regularly come to us though with is they want us to have a really strong point of view, want us to be opinionated, tell them how this should work effectively together, what does best practice look like, what's the gold standard, what are some of the artifacts, tools, frameworks, reusable templates that we can share with them that accelerates their time to value. So I think the value significantly outweighs the concerns around lock in or reduction of the number of vendors that they're working with. >> If I look at really the enterprise space, you've got costumers working through their application modernization. They've got their modelist their going after micro services. I heard a stat that only about five to ten percent of apps are monitored at the app level today. >> Yeah, pretty scary, isn't it? >> Yeah, how many of your costumers are dealing with the installed state versus new deployments and what are some of the challenges you're hearing from costumers there? >> Yeah and I think it's important to pause that number because I think it's five to ten percent or growing to twenty percent as I think got indicated. If you look at those organizations Born In The Cloud or Born Digital it's significantly higher percentage of that which is possibly an indictment of the low level of instrumentation we see in a lot of legacy software technology stacks. And so I think in today's world we're tryna get that level of instrumentation observability up as much as possible. But maybe to link back to your previous question as well I think there's an important aspect here of when we move to a platform. When you're a product company your differentiation comes through product, comes through the capability of that product features and functions and we've certainly found ourselves in a significant number of those battles against competition where it's feature and function based. That's not a great comfort for the costumer. I think when you move to a platform it's very much around the networks differentiation. When I say network differentiation I think it's about getting the users of your service access to third party applications to third party data sources be they open source data emitters, opentelementry, open sensors, Zipkin any of those data sets that we are now in support for today. Giving them access to those data sets and being able to enrich the experience that we provide them that network effects and that's really where we see the opportunity to deliver significantly more value to our costumers with the ability to then build your own applications on top of the platform. That's second to none in the industry in my opinion. >> Roger, what's New Relic's role in helping costumers as really they're modernizing their work force? When I talk to so many companies it's like they need to retrain and they have to have new skill sets they need to make sure as certain cloud in automation changes where they focus on things and embrace devops and new ways of doing things. There are a lot of challenges there. Where does New Relic play in that modernization for costumers? >> You know what I think it's in a couple ways. The ways that we, my organization, can help the costumer in terms of just sheer understanding of the capability of the platform, what are best practices, how we can drive better accountability as you move to these new technology stacks and new ways of working much more agile environments. And so I think we can do a combination of that just sheer skills development, working really tightly with the likes of AWS you would've heard Dave McCann this morning talking about how when costumers migrate the application work goes to the AWS cloud environment. Hopefully they're not just doing that by way of compute lift and shift but they were actually looking at modernizing and refactoring those applications and when they do that, you heard Dave talk through a number of assets and frameworks and models and reusable best practices that we're trying to work with them on that we can give to our costumers that accelerate their journey 'cause it's not easy. We were talking to Chris Dillon this morning from Cox Automotive and when you think of an organization like that that's forty, fifty years old and has had to transform itself in terms of digital experience for it's costumer base, it's a significant cultural adjustment quite often to get teams to work in fundamentally different ways. So it's not an insignificant challenge but that's partly why we've invested so heavily in costumer success. Taking the costumers on the journey, thinking about their maturity over time, and constantly look for them to get better value from the platform. >> Roger, there are a number of things that have jumped out at me. Things like oh hey, we can save you potentially millions of dollars on your AWS cloud bill. You've already got costumers building on top of the platform, you had the future Haka event just a couple of weeks ago. Any other kind of interesting or exemplary costumer outcomes that you might be able to share? Either doesn't have to be about the new stuff but just that you've recently with your costumers. >> You know, one of the things that's most gratifying for me when talking to costumers is when we've been able to see when you work with older, more traditional companies that are undergoing some form of digital transformation and they're trying to shift a lot of the applications into a more modern stack and environment, become more agile, etc. they frequently sort of peel off part of the business and will have a digital division that will build some innovative, typically mobile based, apps. We've seen a number of different retailers that we've worked with. Number of different travel organizations where we've started out intrumenting the mobile application because they've built a new application to give their consumers or costumers access through to their services, and at some point that application is going to merge into the backend and have to connect back into older technology. And it's been the beauty of being able to connect those two different environments together. Not starting off at what we would've got as slightly easier place to start which was the more modern application environment where we are really well suited to. But then seeing the full value of being able to instrument the front end all the way through to the backend, link that back to the costumer's experience and to the impact on the business in terms of funnel analysis from number of people using the mobile application to actually ordering something to once they've ordered it, feeling satisfied in actually receiving the goods that they ordered. Being able to instrument all of that and understand the impact of performance and availability on the overall business arcam, that's when it's been truly transformational in working with costumers and that's certainly where we'd love to help more of our costumers in that fashion. >> Alright, Roger, want to give you the final word. Of course you bring together a number of costumers here at FutureStack in the U.S as well there's a few of those run in other geographical areas but throughout the year, any other key things you want to highlight as to how costumers can get engaged even more. >> Yeah, I mean, we've got a sort of what I would argue is a tiered approach to costumer success. At the very high end of our engagement model we have a significant number of resources. Solution architects, costumer success managers that we can deploy directly with our costumers. We typically do that in conjunction with them, build out success plans, etc. What we looking at investing Heavily at the moment is also having a good understanding of what the ideal costumer journey is like. Realizing that a costumer can come to an event like this and learn about our product but the best way for them to experience that is in the course of using the product. So heavy focus on product lead growth and how we actually deliver better value through the product itself, remove friction and adoption and getting to better value. We want to automate some of that costumer journey so that we know that if you've just signed up and, for instance, you've configured you're agent and you've done your learning policy but you haven't yet configured a custom apdex on that application or you haven't understood what your key transactions are, we've got all that data in the backend. So we're working really hard to understand how we get that information back out to costumers and go hey we know you haven't necessarily done this yet, here's some access to great assets. A short video clip, a self paced learn guide that somebody can get on demand from an LMS system. So trying to use a combination of direct resource investment, events like this where it's great to make announcements like we did about the six grade innovations and then increasingly using digital through the products but also through just the general costumer journey to say hey this is really important content and information, you should look at this now 'cause it's going to add value in what you're doing today. >> Alright, well Roger Scott, Chief Customer Officer at New Relic, thanks so much for joining us. >> Thanks so much, it's been great talking to you. >> All right. I'm Stu Minimen back with lots more here at New Relic FutureStack 2019 in New York City. Thanks for watching theCUBE. (outro music)

>> Live from Barcelona, Spain it's theCUBE, covering KubeCon, CloudNativeCon, Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation and Ecosystem Partners. >> Welcome back. This is theCUBE's coverage of KubeCon, CloudNativeCon 2019. I'm Stu Miniman, my co-host for two days wall-to-wall coverage is Corey Quinn. Happy to welcome back to the program first Ben Sigelman, who is the co-founder and CEO of LightStep. And welcome to the program a first time Morgan McLean, who's a product manager at Google Cloud Platform. Gentlemen, thanks so much for joining us. >> Thanks for having us. >> Yeah. >> All right so, this was a last minute ad for us because you guys had some interesting news in the keynote. I think the feedback everybody's heard is there's too many projects and everything's overlapping, and how do I make a decision, but interesting piece is OpenCensus, which Morgan was doing, and OpenTracing, which Ben and LightStep were doing are now moving together for OpenTelemetry if I got it right. >> Yup. >> So, is it just everybody's holding hands and singing Kumbaya around the Kubernetes campfire, or is there something more to this? >> Well I mean, it started when the CNCF locked us in a room and told us there were too many projects. (Stu and Ben laughing) Really wouldn't let us leave. No, to be fair they did actually take us to a room and really start the ball rolling, but conversations have picked up for the last few months and personally I'm just really excited that it's gone so well. Initially if you told me six or nine months ago that this would happen, I would've been, given just the way the projects were going, both were growing very quickly, I would've been a little skeptical. But seriously, this merger's gone beyond my wildest dreams. It's awesome, both to unite the communities, it's awesome to unite the projects together. >> What has the response been from the communities on this merger? >> Very positive. >> Yeah. >> Very positive. I mean OpenTracing and OpenCensus are both projects with healthy user bases that are growing quickly and all that, but the reason people adopt them is to future-proof their own software. Because they want to adopt something that's going to be here to stay. And by having these two things out in the world that are both successful, and were overlapping in terms of their goals, I think the presence of two projects was actually really problematic for people. So, the fact that they're merging is net positive, absolutely for the end user community, also for the vendor community, it's a similar, it's almost exactly the same parallel thought process. When we met, the CNCF did broker an in-person meeting where they gave us some space and we all got together and, I don't know how many people were there, like 20 or 30 people in that room. >> They did let us leave the room though, yesterday, yeah that was nice. >> They did let us leave the room, that's true. We were not locked in there, (Morgan laughing) but they asked us in the beginning, essentially they asked everyone to state what their goals were. And almost all of us really had the same goal, which is just to try and make it easy for end users to adopt a telemetry project that they can stick with for the long haul. And so when you think of it in that respect, the merger seems completely obvious. It is true that it doesn't happen very often, and we could speculate about why that is. But I think in this case it was enabled by the fact that we had pretty good social relationships with OpenCensus people. I think Twitter tends to amplify negativity in the world in general, as I'm sure people, not a controversial statement. >> News alert, wait, absolutely the negatives are, it's something in the algorithm I think. >> Yeah, yeah. >> Maybe they should fix that. >> Yeah, yeah (laughs) exactly. And it was funny, there was a lot of perceived animosity between OpenTracing and OpenCensus a year ago, nine months ago, but when you actually talk to the principals in the projects and even just the general purpose developers who are doing a huge amount of work for both projects, that wasn't a sentiment that was widely held or widely felt I think. So, it has been a very kind of happy, it's a huge relief frankly, this whole thing has been a huge relief for all of us I think. >> Yeah it feels like the general ask has always been that, for tracing that doesn't suck. And that tends to be a bit of a tall order. The way that they have seemed to have responded to it is a credit to the maturity of the community. And I think it also speaks to a growing realization that no one wants to have a monoculture of just one option, any color you want so long as it's black. (Ben laughing) Versus there's 500 different things you can pick that all stand in that same spot, and at that point analysis paralysis kicks in. So this feels like it's a net positive for, absolutely everyone involved. >> Definitely. Yeah, one of the anecdotes that Ben and I have shared throughout a lot of these interviews is there were a lot of projects that wanted to include distributed tracing in them. So various web frameworks, I think, was it Hadoop or HBase was-- >> HBase and HDFS were jointly deciding what to do about instrumentation. >> Yeah, and so they would publish an issue on GitHub and someone from OpenTracing would respond saying hey, OpenTracing does this. And they'd be like oh, that's interesting, we can go build an implementation file and issue, someone from OpenCensus would respond and say, no wait, you should use OpenCensus. And with these being very similar yet incompatible APIs, these groups like HBase would sit it and be like, this isn't mature enough, I don't want to deal with this, I've got more important things to focus on right now. And rather than even picking one and ignoring the other, they just ignored tracing, right? With things moving to microservices with Kubernetes being so popular, I mean just look at this conference. Distributed tracing is no longer this kind of nice to have when you're a big company, you need it to understand how your app works and understand the cause of an outage, the cause of a problem. And when you had organizations like this that were looking at tracing instrumentation saying this is a bit of joke with two competing projects, no one was being served well. >> All right, so you talked about there were incompatible APIs, so how do we get from where we were to where we're going? >> So I can talk about that a little bit. The APIs are conceptually incredibly similar. And the part of the criteria for any new language, for OpenTelemetry, are that we are able to build a software bridge to both OpenTracing and OpenCensus that will translate existing instrumentation alongside OpenTelemetry instrumentation, and omit the correct data at the end. And we've built that out in Java already and then starting working a few other languages. It's not a tremendously difficult thing to do if that's your goal. I've worked on this stuff, I started working on Dapper in 2004, so it's been 15 years that I've been working in this space, and I have a lot of regrets about what we did to OpenTracing. And I had this unbelievably tempting thing to start Greenfield like, let's do it right this time, and I'm suppressing every last impulse to do that. And the only goal for this project technically is backwards compatibility. >> Yeah. >> 100% backwards compatibility. There's the famous XKCD comic where you have 14 standards and someone says, we need to create a new standard that will unify across all 14 standards, and now you have 15 standards. So, we don't want to follow that pattern. And by having the leadership from OpenTracing and OpenCensus involved wholesale in this new effort, as well as having these compatibility bridges, we can avoid the fate of IPv6, of Python 3 and things like that. Where the new thing is very appealing but it's so far from the old thing that you literally can't get there incrementally. So that's, our entire design constraint is make sure that backwards compatibility works, get to one project and then we can think about the grand unifying theory of a provability-- >> Ben you are ruining the best thing about standards is that there is so many of them to choose from. (everyone laughing) >> There's still plenty more growing in other areas (laughs) just in this particular space it's smaller. >> One could argue that your approach is nonstandard in its own right. (Ben laughing) And in my own experiments with distributed tracing it seems like step one is, first you have to go back and instrument everything you've built. And step two, hey come back here, because that's a lot of work. The idea of an organization going back and reinstrumenting everything they've already instrumented the first time. >> It's unlikely. >> Unless they build things very modularly and very portably to do exactly that, it's a bit of a heavy lift. >> I agree, yeah, yeah. >> So going forward, are people who have deployed one or the other of your projects going to have to go back and do a reinstrumentation, or will they unify and continue to work as they are? >> So, I would pause at the, I don't know, I would be making up the statistic, so I shouldn't. But let's say a vast majority, I'm thinking like 95, 98% of instrumentation is actually embedded in frameworks and libraries that people depend on. So you need to get Dropwizard, and Spring, and Django, and Flask, and Kafka, things like that need to be instrumented. The application code, the instrumentation, that burden is a bit lower. We announced something called SpecialAgent at LightStep last week, separate to all of this. It's kind of a funny combination, a typical APM agent will interpose on individual function calls, which is a very complicated and heavyweight thing. This doesn't do any of that, but it takes, it basically surveys what you have in your process, it looks for OpenTracing, and in the future OpenTelemetry instrumentation that matches that, and then installs it for you. So you don't have to do any manual work, just basically gluing tab A into slot B or whatever, you don't have to do any of that stuff which is what most OpenTracing instrumentation actually looks like these days. And you can get off the ground without doing any code modifications. So, I think that direction, which is totally portable and vendor neutral as well, as a layer on top of telemetry makes a ton of sense. There are also data translation efforts that are part of OpenCensus that are being ported in to OpenTelemetry that also serve to repurpose existing sources of correlated data. So, all these things are ways to take existing software and get it into the new world without requiring any code changes or redeploys. >> The long-term goal of this has always been that because web framework and client library providers will go and build the instrumentation into those, that when you're writing your own service that you're deploying in Kubernetes or somewhere else, that by linking one of the OpenTelemetry implementations that you get all of that tracing and context propagation, everything out of the box. You as a sort of individual developer are only using the APIs to define custom metrics, custom spans, things that are specific to your business. >> So Ben, you didn't name LightStep the same as your project. But that being said, a major piece of your business is going through a change here, what does this mean for LightStep? >> That's actually not the way I see it for what it's worth. LightStep as a product, since you're giving me an opportunity to talk about it, (laughs) foolish move on your part. No, I'm just kidding. But LightStep as a product is totally omnivorous, we don't really care where the data comes from. And translating any source of data that has a correlation ID and a timestamp is a pretty trivial exercise for us. So we do support OpenTracing, we also support OpenCensus for what it's worth. We'll support OpenTelemetry, we support a bunch of weird in-house things people have already built. We don't care about that at all. The reason that we're pursuing OpenTelemetry is two-fold, one is that we do want to see high quality data coming out of projects. We said at the keynote this morning, but observability literally cannot be better than your telemetry. If your telemetry sucks, your observability will also suck. It's just definitionally true, if you go back to the definition of observability from the '60s. And so we want high quality telemetry so our product can be awesome. Also, just as an individual, I'm a nerd about this stuff and I just like it. I mean a lot of my motivation for working on this is that I personally find it gratifying. It's not really a commercial thing, I just like it. >> Do you find that, as you start talking about this more and more with companies that are becoming cloud-native rapidly, either through digital transformation or from springing fully formed from the forehead of some God, however these born in the cloud companies tend to be, that they intuitively are starting to grasp the value of tracing? Or does this wind up being a much heavier lift as you start, showing them the golden path as it were? >> It's definitely grown like I-- >> Well I think the value of tracing, you see that after you see the negative value of a really catastrophic outage. >> Yes. >> I mean I was just talking to a bank, I won't name the bank but a bank at this conference, and they were talking about their own adoption of tracing, which was pretty slow, until they had a really bad outage where they couldn't transact for an hour and they didn't know which of the 200 services was responsible for the issue. And that really put some muscle behind their tracing initiative. So, typically it's inspired by an incident like that, and then, it's a bit reactive. Sometimes it's not but either way you end up in that place eventually. >> I'm a strong proponent of distributed tracing and I feel very seen by your last answer. (Ben laughing) >> But it's definitely made a big impact. If you came to conferences like this two years ago you'd have Adrian, or Yuri or someone doing a talk on distributed tracing. And they would always start by asking the 100 to 200 person audience, who here knows what distributed tracing is? And like five people would raise their hand and everyone else would be like no, that's why I'm here at the talk, I want to find out about it. And you go to ones now, or even last year, and now they have 400 people at the talk and you ask, who knows what distributed tracing is? And last year over half the people would raise their hand, now it's going to be even higher. And I think just beyond even anecdotes, clearly businesses are finding the value because they're implementing it. And you can see that through the number of companies that have an interest in OpenTracing, OpenTelemetry, OpenCensus. You can see that in the growth of startups in this space, LightStep and others. >> The other thing I like about OpenTelemetry as a name, it's a bit of a mouthful but that's, it's important for people to understand the distinction between telemetry and tracing data and actual solutions. I mean OpenTelemetry stops when the correct data is being omitted. And then what you do with that data is your own business. And I also think that people are realizing that tracing is more than just visualizing a single distributed trace. >> Yeah. >> The traces have an enormous amount of information in there about resource usage, security patterns, access patterns, large-scale performance patterns that are embedded in thousands of traces, that sort of data is making its way into products as well. And I really like that OpenTelemetry has clearly delineated that it stops with the telemetry. OpenTracing was confusing for people, where they'd want tracing and they'd adopt OpenTracing, and then be like, where's my UI? And it's like well no, it's not that kind of project. With OpenTelemetry I think we've been very clear, this is about getting >> The name is more clear yeah. >> very high quality data in a portable way with minimal effort. And then you can use that in any number of ways, and I like that distinction, I think it's important. >> Okay so, how do we make sure that the combination of these two doesn't just get watered-down to the least common denominator, or that Ben just doesn't get upset and say, forget it, I'm going to start from scratch and do it right this time? (Ben laughing) >> I'm not sure I see either of those two happening. To your comment about the least common denominator, we're starting from what I was just commenting about like two years ago, from very little prior art. Like yeah, you had projects like Zipkin, and Zipkin had its own instrumentation, but it was just for tracing, it was just for Zipkin. And you had Jaeger with its own. And so, I think we're so far away, in a few years the least common denominator will be dramatically better than what we have today. (laughs) And so at this stage, I'm not even remotely worried about that. And secondly to some vendor, I know, because Ben had just exampled this, >> Some vendor, some vendor. >> that's probably not, probably not the best one. But for vendor interference in this projects, I really don't see it. Both because of what we talked about earlier where the vendors right now want more telemetry. I meet with them, Ben meets with 'em, we all meet with 'em all the time, we work with them. And the biggest challenge we have is just the data we get is bad, right? Either we don't support certain platforms, we'll get traces that dead end at certain places, we don't get metrics with the same name for certain types of telemetry. And so this project is going to fix that and it's going to solve this problem for a lot of vendors who have this, frankly, a really strong economic incentive to play ball, and to contribute to it. >> Do you see that this, I guess merging of the two projects, is offering an opportunity to either of you to fix some, or revisit if not fix, some of the mistakes, as they were, of the past? I know every time I build something I look back and it was frankly terrible because that's the kind of developer I am. But are you seeing this, as someone who's probably, presumably much better at developing than I've ever been, as the opportunity to unwind some of the decisions you made earlier on, out of either ignorance or it didn't work out as well as you hoped? >> There are a couple of things about each project that we see an opportunity to correct here without doing any damage to the compatibility story. For OpenTracing it was just a bit too narrow. I mean I would talk a lot about how we want to describe the software, not the tracing system. But we kind of made a mistake in that we called it OpenTracing. Really people want, if a request comes in, they want to describe that request and then have it go to their tracing system, but also to their metric system, and to their logging stack, and to anywhere else, their security system. You should only have to instrument that once. So, OpenTracing was a bit too narrow. OpenCensus, we've talked about this a lot, built a really high quality reference implementation into the product, if OpenCensus, the product I mean. And that coupling created problems for vendors to adopt and it was a bit thick for some end users as well. So we are still keeping the reference implementation, but it's now cleanly decoupled. >> Yeah. >> So we have loose coupling, a la OpenTracing, but wider scope a la OpenCensus. And in that aspect, I think philosophically, this OpenTelemetry effort has taken the best of both worlds from these two projects that it started with. >> All right well, Ben and Morgan thank you so much for sharing. Best of luck and let us know if CNCF needs to pull you guys in a room a little bit more to help work through any of the issues. (Ben laughing) But thanks again for joining us. >> Thank you so much. >> Thanks for having us, it's been a pleasure. >> Yeah. >> All right for Corey Quinn, I'm Stu Miniman we'll be back to wrap up our day one of two days live coverage here from KubeCon, CloudNativeCon 2019, Barcelona, Spain. Thanks for watching theCUBE. (soft instrumental music)

>> Narrator: Live from Austin, Texas. It's theCUBE, covering KubeCon and CloudNativeCon 2017. Brought to you by Red Hat, the Linux Foundation, and theCUBE's ecosystem partners. >> Hey, welcome back everyone, we're here live at theCUBE in Austin, Texas for KubeCon 2017, 2nd annual conference of the Kubernetes Conference, I'm John Furrier, here with my co-host, Stu Miniman, Ben Sigelman, who's the CEO of LightStep, welcome to theCUBE. >> Thank you so much. >> So you're also involved in open tracer, all this stuff with service mesh, really instrumental tech work going on right now. >> Mmhmm, yep. >> With this KubernetesCon, I mean Kubernetes has been successful. People are now learning for, the first time in mainstream, but it's really galvanized the community. At many levels, and I haven't seen this much action and so fast, up and down the stack. You know, you got the infrastructure plumbing guys, and you got the app plumbing guys all building really, really fast. What's the state of the union? Give us a peak of what's happening, what's solid, what's foundational? What are the building blocks that are being built on and what's the current task of jobs being worked on projects and what not? >> Yeah, and that's a great question. I was, emerged my hotel room yesterday just to get on the elevator and Kelsey Hightower emerged from his hotel room, turns out two doors down from me, and we're walking to the elevator together, I'm like, "Hey! You know, so, what's your big announcement?" He's so good on stage, he's a brilliant communicator, and he's like, you know, honestly, the big news right now, is that actually there's not that much news from a release standpoint about Kubernetes, which is actually a really big deal. It's gotten to the point where it's feature set is actually appropriate and somewhat stable. And now we finally are at the point where it's, I think, it has a really natural architecture for plugins and extensions and now we can build this entire ecosystem around it, instead of building around something that's a bit of a moving target. I think it's incredible how, it is truly incredible, to see this conference over the last couple of years. >> So Pete's foundational elements are in place. >> Yeah. >> That's his, kind of his... >> Yeah, exactly. And it's incredible to see how much of, not just a commercial ecosystem, but a technology ecosystem, that's built around those primitives, and so I think those really are the right primitives, to democratize the pieces that should be democratized, and to centralize the pieces that should be centralized. So to me, this year is really about going a level up in the stack, and delivering value that's beyond, you know, the container, Kubernetes level, and that's what a lot of the projects that I'm excited about are doing. >> Yeah, so Ben, and that leads right into one of the things that we've been talking about all week here, service meshes. >> Ben: Yeah. >> So, you gave a keynote yesterday, maybe give our audience a little bit about service meshes, servibility, and there's something about a pigeon? >> (laughs) Yeah that was very funny. Just the reference about the pigeon, the first slide in my talk was a picture of a murmuration of starlings, this beautiful cloud of birds moving in harmony, and while I was waxing on about how this represented microservices, an actual bird flew above me on stage. There was a pigeon trapped in this room `(laughter) and so everyone started laughing, I didn't know what was so funny, I'm like... >> Jeez. What a great demo. >> ...like what did I do wrong? Do I have a note on my back or something? And then the hilarious thing is the second slide was actually the operational experience of deploying this sort of microservice technology is actually very difficult, and so it was this slide from Alfred Hitchcock's "The Birds," with these birds attacking this poor child. And so, and the bird is still circling around above me. It was perfect stagecraft, I wish I had tried to do it, it would have been amazing to take credit for arranging an actual live animal as part of my presentation. But in terms of the actual material in the presentation, which may be less entertaining than the bird flying around my head, but the material of the presentation is something I feel very strongly about, and I alluded to this a moment ago, I think that containers are incredibly important, I think Kubernetes is incredibly important, and I am extraordinarily confident that in ten years, they're going to be everywhere. That said, they're not something an application developer really should care that deeply about as part of their job of writing business logic for the service that they are maintaining and developing. That shouldn't be a layer that they care about. And there are a lot of really, really important problems that crop up at the application layer. At Google, the way we addressed this, was by having not a monolithic architecture, but a monolithic software repository where everyone developed the same code base, but one of the things that I thought was interesting was being at Google, if you wanted to deploy an application, even something that just printed out 'Hello, world' or something, it was like a 150 megabyte binary, because there's so much stuff that was crammed in to level 7, user level stuff, and that was right for Google, it's not really the best architecture for a lot of enterprises out there and I think what's so cool about service mesh, is that it's taken a bunch of really, genuinely hard computer science problems, like service discovery, connection, and load balancing, and reconnection, health checks, security and authentication, observability and tracing, these are really hard things to do well, and it's factored them off into a side car that you can run alongside ordinary applications that were not even developed with that in mind and take advantage of these application level, level 7 primitives. We've had people who are trying to build solutions for any number of managerial and monitoring tasks at the container level, where often that stuff is completely obscured. Like by the time you're at the kernel that you can't see any of this stuff. If you're up at level 7 in the service mesh, you have easy access to application level data, which makes everything a lot more elegant and straightforward for developers, so it's like, to me, it's this single point of integration that removes a bunch of hard computer science problems from ordinary application development. >> And so people were stuffing containers basically and trying to overdrive that. Makes total sense architecturally and I want you to take a step back and kind of unpack that a little bit. We didn't get here by accident. We got here through real hard work, I mean people were out there building from open-source large-scale systems. >> Yeah. >> Uber, Lyft, there's a handful of other examples. What was the driver around this, because you're talking about a really elegant architecture that allows for solving a problem for the guys that solve their own problems. Thousands, hundreds of thousands of transactions, services, millions of transactions per second. >> Yup. >> So this was not like "Hey, let's just design a new system!" It was some scar tissue. >> Yeah. >> How does that connect to like, reality now for, whether it's a start-up saying "Hey, you know, we're a couple of years old, we're on AWS, and we're growing, and I want to add more value, but I don't want to relearn machine learning, I want to build on all this stuff and create business value from my enterprise, growing an enterprise. Or, big enterprises, trying to be cloud enabled. So that's, how should someone think about that? And what specifically was the problem that was solved? >> Yes. Well, I'm an obsessive person, I'll admit that. And I'm personally obsessed with performance, and so when I think about this, I actually think about profiling the engineers who are building this stuff. You have developers, let's profile them, like what are they spending their time on? 'Cause that's really a precious resource right now, right? It's like, it's hard to even hire people fast enough, right? So if you think about profiling people, you have folks that are spending a lot of time trying to get their services communicated properly, to authenticate, to observe these systems, in a way that's sane. And so it's only natural you try to factor that out and make that factored out. You try to amortize the cost of solving that problem across your entire organization. And I think that you've seen people who've been at other companies, and want to recreate something like what they had at Google or Facebook or Twitter or what have you, but they want to do it in a way that meshes with their existing systems. I'm actually not surprised that super, super young companies that are starting with the true green field code base, move in this direction. What has been interesting to me, and although I shouldn't say surprising, this is actually very rational, but you also have companies that are much larger, and we, LightStep has, we have customers that are running a mainframe, alongside legacy Java VMs, alongside microservices, and they're all working in concert to the service application requests from end users. And these things need to talk to each other, and I think what's actually really fun for me, Google gets a lot of credit for building things the right way, I don't know if that's accurate for not, but it's really funny 'cause the problem is actually a lot more interesting outside of Google, because you have to integrate with a much larger surface area and the thing that's so exciting to me about a lot of the technologies that are really taking off here, is that they're designed for that kind of heterogeneity, certainly I've talked about service mesh a million times already here, open tracing also exists specifically because of heterogeneity, we didn't need open tracing at Google because everything was perfectly factored, so it was unnecessary. Outside of Google, it's necessary to have a common API to describe transactions as they propagate, because otherwise, you can't make sense of anything that's happening in your application. This sort of heterogeneity has encouraged projects that standardize at the right layer, and I think those are the ones that are proliferating. >> What is service mesh about now? I mean, how would you describe it, I mean, how would you define, in the world of Kubernetes, in the world we're talking about, for someone just getting, tech person, just getting started. What's the hubbub about with service mesh? What is it? >> Well, I mean, I think at the most basic level, it's something that sits in between any two processes that are communicating in your system, and it sits in between them at a layer where you can observe the application itself. Like, you're able to access application levels, security information application level, primitives like, you know, the particular path you're hitting for any HTP requests, something like that. It's something that sits in between at that layer. Because microservices, you know, I've seen Lyft up close 'cause they're also a customer for LightStep, and to see Envoy deployed at their company is really instructive. It's amazing, I mean it's really amazing. They went from having no integration with our product to having 100% integration with our product by flipping a configuration bit to on, you know. Actually it wasn't even on, they could do it by percentage, I mean, they can roll these things out with perfect, perfect precision. And, I mean, it's an incredibly powerful thing to be able to have that kind of leverage over an entire architecture and that didn't require all their developers to redeploy. This system required the service mesh to redeploy, so you make these sorts of changes without touching application CSCD stuff, you can do all these infrastructural level changes independently from application pushes-- >> All right, >> And that's very powerful. >> So, so hold on, I know Stu wants to get a question in, but let's stop there for a second. Compare and contrast what the old way would have been. >> Stu: Yeah. What would it have taken to do this similar concept that full team had met, assuming they had another architecture. >> I've seen, I mean, you know- >> John: Months, weeks, redeploys... >> So, you know, the model that I've seen at Google where would we make changes to software that was linked into every application would go out with the next release, we would make that change in some central place, I'd say 50% of the services would be deployed within a week, 90% within two weeks, but to get to 99% would take over a year, and so the issue is if you need a change that's going to cut across your entire system, it is not feasible to wait for people to redeploy because there are going to be services that are not being maintained by human beings anymore, and no one's about to volunteer for that chore- >> John: It's a nightmare basically. >> Of reintegrating, taking in months of code changes, making sure it still works and deploys. >> Yeah, they're going to quit right there. I mean, no one wants that. >> It's infeasible. >> Yeah, it's not feasible. >> Ben, I wanted you to be able to share a little bit about founding LightStep, you know what's kind of the need in the market, and what you're seeing from your early customers. >> Sure, LightStep is, it has a pretty simple mission. We aim to deliver insights about very complex production software, which is commonplace at this point. Anyone who's building a meaningful business is building meaningful production software, and that means it's complicated. So that's what we want to do. The way that we're doing that with our first product, LightStep XPM, is by delivering root cause analysis for the symptoms that are of most interest to these businesses, regardless of their application or architecture, as I said earlier, we have customers that run mainframes as well as microservices at the same time, multi-cloud, it doesn't matter. We follow transactions across these distributed services and use those to explain behaviors that they're puzzling over and help them with performance analysis and root cause analysis. >> And what's the relationship between the open source projects and... >> That's a great question. It's not a normal open core model. Open tracing is really an API project that's designed to ease integration with any number of vendors, and open tracing is supported by LightStep of course, but also by Jaeger, and CNCF, it's compatible with Zipkin, it's supported by New Relic and Datadog, I'll give a shoutout to some competitors. We're all in this together in the sense that I think we see that we all have a much bigger market as things like open tracing proliferate, and make it easier to actually observe your own system. I would love to compete in the playing field of solutions and not worry so much about integration, so open tracing is an integration project, it's not our core technology. Our core IP is something that's very powerful, that's designed to absorb a lot of information about these distributed systems and deliver value about that. >> And when I look at your website, and see kind of some of your early customers, I mean, jump out, you know, Lyft, Twilio, Digital Ocean, I mean, these are not kind of your typical companies, is it, you know, fully kind of cloud-native, you know, horn of the web, type companies? >> I'm really glad you asked that. No. >> Stu: Yeah. >> I mean, most of our customers at this point are, have actually never seen a full microservice deployment, certainly not at one of customers. It's always a combination of a monolith in the middle and microservices on the outside, but a lot of our customers are more traditional enterprises that we haven't put on our website for logo rights reasons, but they get a lot value out of the solution, I would say even more value in some cases because they're dealing with a greater diversity of technology generations they need to cut across. >> Yeah, I want to go back. You mentioned the time for people these days and you talk about developers and people building, the fight for talent is huge out there. What are you seeing in your customers? Is that something that you help? How's kind of that interaction? >> Yeah absolutely, I mean, I think, Digital Ocean says they're saving, I think 1000 engineer hours a month or something like that on LightStep. It's a huge timesaver for people who are trying to get to the bottom of issues. So it's a labor issue, but also root cause analysis, I mean, every second counts. Seconds cost hundreds of thousands of dollars for some of our customers for any big outage, and so we help people get those, Twilio's addressing the instance 92% faster after using LightStep, so it's a big change to their root cause analysis. >> Yeah, there was a great quote I saw that said, "When something goes wrong, it used to be you knew, now it turned into a murder mystery." >> Yeah. (laughter) >> Tell the story of why did you start the company. Was there an itch you were scratching? You saying, "Hey, you know, I've seen this movie before, I want to get out there, help customers, I mean, I heard, your mission is really straightforward, clean, good positioning. Why start the company? What was the rationale? What was the motivation? >> That's a very easy one for me. I mean, the reason I left Google was not necessarily to start a company per se, it was that I wanted to have as much of an impact on the industry as I could, I wanted to see things, not just make money and siphon cash away from companies, but actually to change the way that software is built. And the first act for us, this product, is a way for us to kind of get into the tendril, get our system deep into the fabric of an application, and from that point, I'd like to see LightStep really change the way people build software. I think people right now, it's almost like everyone's programming an assembly. Like we're all trying to operate this level that's totally inappropriate, and I'd love to see LightStep be a part of this story for making the industry move up the value chain and really focus on building applications, and that's what I want to see us do. >> You know, we've been saying, first, we have a similar mission along our media business, but one of the things we're seeing, we go to all the shows, sometimes it's like, why is theCUBE covering, you know, Node.js, or why are you covering Hadoop in 2010, why are you, because we see it early, we get in early, as I said, we can see the innovation, we like it, but I got to tell you, we've been seeing recently, I've been seeing it specifically, we see a huge renaissance in software development companies. >> Yeah, for sure. >> And my piece is, I want to test this with you because I think this is going to change the culture, certainly in Silicon Valley and around the world. Certainly with open source is exponentially growing, you know, Zemlin puts that stat up pretty clear. All software development models was crafty and built a product you QA and you'd ship it, it either worked or it didn't work, put some art to it, around ownership, and then AdJail derisked that risk, but you can get it to the market quicker, and you listen to the data, you learn from the data, but it kind of took the craft out of it. You know what I'm saying, almost we're coding and we're iterating, we're on a treadmill, which is good. But now, with what we're seeing here, is that you're getting back to extracting away, to your point, all these services you don't need to worry about anymore. I could actually focus all of my attention on the artisan aspect of the solution. Not UX, love UX design, not that kind of art, but something about software art. What's your reaction to that? Do you see that coming? Because if this continues, we're going to have a whole class of software developers just essentially painting software art, if you will. >> Yeah. >> I mean, that potentially is a scenario. Your thoughts. >> Yes, I agree with that scenario being feasible. I think it's probably more than a couple of weeks away, but I'm really excited about it. I think you're right on the money, I think a lot of the changes that we're seeing allow people to operate more independently and that's what motivates the transitions to microservice in the first place, it wasn't just to rewrite everyone's software for fun, it was because we want everyone to be able to be independent of each other and operate in that mode. The thing that I think is exciting about that vision which I would echo is a lot of the primitives that we see in the marketplace right now allow developers to focus on the semantics of application and the requirements of application which is where all of the interesting stuff is, and what we all get excited about. And I think we do see a lot of the, this number of people here right now, that investment as a community in allowing developers to focus on the logic and nothing more is really tremendous and exciting to me. >> How has community changed? I know you believe in community. Community's more important than ever now, in this new model, 'cause there's so much leverage going on with the software. How important is community and how is it changing and how should it evolve to handle all this awesome growth? >> Yeah I do have some thoughts about that. It's definitely important, I mean no one's going to deny that. I think one of the biggest challenges that I think about anyway in this sphere, has to do with, I referred to this earlier, it's important to figure out what problem you're solving with the community aspect of things, like with open tracing we thought really hard about this, like are we going to focus on, like, the bits and bytes and the wire protocols, or on the part that really needs to be standardized. I think community makes sense when standards are appropriate and standard interfaces are appropriate. I'm actually a little bit skeptical of community driven solutions where it's, you're delivering the entire package as a community because it ends up intersecting in ways that are complex I think with business motivations. I think the most successful projects are areas where the community really must collaborate, which usually has something to do with standardization. Those are the areas where I'm most excited. And then you actually literally, I was talking with Ken Goldberg yesterday, and they intentionally carved out areas for vendors to play, because they don't want to kind of meddle in that are. It's actually better not to meddle in that area. It's actually better- >> It's like microservices, you put the vendors over there and you put core commuters over there. Ben Sigelman, thanks for coming on theCUBE, I appreciate it. Congratulations on LightStep and the success and your talks here. Early community exploding, cloud native is not only a movement, it's clear to everyone, cloud and data and software and open source is making it happen, easier, accelerating velocity. It's theCUBE, doing our part, bringing you the data, here in Texas, I'm John Furrier, with Stu Miniman. We're back with more live coverage after this short break. >> Thank you. (techno music)