(lively music) >> Good afternoon cloud community and welcome back to beautiful Las Vegas, Nevada. We are here at AWS re:Invent, day four of our wall to wall coverage. It is day four in the afternoon and we are holding strong. I'm Savannah Peterson, joined by my fabulous co-host Paul Gillen. Paul, how you doing? >> I'm doing well, fine Savannah. You? >> You look great. >> We're in the home stretch here. >> Yeah, (laughs) we are. >> You still look fresh as a daisy. I don't know how you do it. >> (laughs) You're too kind. You're too kind, but I'm vain enough to take that compliment. I'm very excited about the conversation that we're going to have up next. We get to get a little DevRel and we got a little swagger on the stage. Welcome, Austin. How you doing? >> Hey, great to be here. Thanks for having me. >> Savannah: Yeah, it's our pleasure. How's the show been for you so far? >> Busy, exciting. Feels a lot like, you know it used to be right? >> Yeah, I know. A little reminiscent of the before times. >> Well, before times. >> Before we dig into the technical stuff, you're the most intriguingly dressed person we've had on the show this week. >> Austin: I feel extremely underdressed. >> Well, and we were talking about developer fancy. Talk to me a little bit about your approach to fashion. Wasn't expecting to lead with this, but I like this but I like this actually. >> No, it's actually good with my PR. You're going to love it. My approach, here's the thing, I give free advice all the time about developer relations, about things that work, have worked, and don't work in community and all that stuff. I love talking about that. Someone came up to me and said, "Where do you get your fashion tips from? What's the secret Discord server that I need to go on?" I'm like, "I will never tell." >> Oh, okay. >> This is an actual trait secret. >> Top secret. Wow! Talk about. >> If someone else starts wearing the hat, then everyone's going to be like, "There's so many white guys." Look, I'm a white guy with a beard that works in technology. >> Savannah: I've never met one of those. >> Exactly, there's none of them at all. So, you have to do something to kind stand out from the crowd a little bit. >> I love it, and it's a talk trigger. We're talking about it now. Production team loved it. It's fantastic. >> It's great. >> So your DevRel for Lightstep, in case the audience isn't familiar tell us about Lightstep. >> So Lightstep is a cloud native observability platform built at planet scale, and it powers observability at some places you've heard of like Spotify, GitHub, right? We're designed to really help developers that are working in the cloud with Kubernetes, with these huge distributed systems, understand application performance and being able to find problems, fix problems. We're also part of the ServiceNow family and as we all know ServiceNow is on a mission to help the world of work work better by powering digital transformation around IT and customer experiences for their many, many, many global 2000 customers. We love them very much. >> You know, it's a big love fest here. A lot of people have talked about the collaboration, so many companies working together. You mentioned unified observability. What is unified observability? >> So if you think about a tradition, or if you've heard about this traditional idea of observability where you have three pillars, right? You have metrics, and you have logs, and you have traces. All those three things are different data sources. They're picked up by different tools. They're analyzed by different people for different purposes. What we believe and what we're working to accomplish right now is to take all that and if you think those pillars, flip 'em on their side and think of them as streams of data. If we can take those streams and integrate them together and let you treat traces and metrics and logs not as these kind of inviolate experiences where you're kind of paging between things and going between tab A to tab B to tab C, and give you a standard way to query this, a standard way to display this, and letting you kind of find the most relevant data, then it really unlocks a lot of power for like developers and SREs to spend less time like managing tools. You know, figuring out where to build their query or what dashboard to check, more just being able to like kind of ask a question, get an answer. When you have an incident or an outage that's the most important thing, right? How quickly can you get those answers that you need so that you can restore system health? >> You don't want to be looking in multiple spots to figure out what's going on. >> Absolutely. I mean, some people hear unified observability and they go to like tool consolidation, right? That's something I hear from a lot of our users and a lot of people in re:Invent. I'll talk to SREs, they're like, "Yeah, we've got like six or seven different metrics products alone, just on services that they cover." It is important to kind of consolidate that but we're really taking it a step lower. We're looking at the data layer and trying to say, "Okay, if the data is all consistent and vendor neutral then that gives you flexibility not only from a tool consolidation perspective but also you know, a consistency, reliability. You could have a single way to deploy your observability out regardless of what cloud you're on, regardless if you're using Kubernetes or Fargate or whatever else. or even just Bare Metal or EC2 Bare Metal, right? There's been so much historically in this space. There's been a lot of silos and we think that unify diversability means that we kind of break down those silos, right? The way that we're doing it primarily is through a project called OpenTelemetry which you might have heard of. You want to talk about that in a minute? . >> Savannah: Yeah, let's talk about it right now. Why don't you tell us about it? Keep going, you're great. You're on a roll. >> I am. >> Savannah: We'll just hang out over here. >> It's day four. I'm going to ask the questions and answer the questions. (Savannah laughs) >> Yes, you're right. >> I do yeah. >> Open Tele- >> OpenTelemetry . >> Explain what OpenTelemetry is first. >> OpenTelemetry is a CNCF project, Cloud Native Computing Foundation. The goal is to make telemetry data, high quality telemetry data, a builtin feature of cloud native software right? So right now if you wanted to get logging data out, depending on your application stack, depending on your application run time, depending on language, depending on your deployment environment. You might have a lot... You have to make a lot of choices, right? About like, what am I going to use? >> Savannah: So many different choices, and the players are changing all the time. >> Exactly, and a lot of times what people will do is they'll go and they'll say like, "We have to use this commercial solution because they have a proprietary agent that can do a lot of this for us." You know? And if you look at all those proprietary agents, what you find very quickly is it's very commodified right? There's no real difference in what they're doing at a code level and what's stopped the industry from really adopting a standard way to create this logs and metrics and traces, is simply just the fact that there was no standard. And so, OpenTelemetry is that standard, right? We've got dozens of companies many of them like very, many of them here right? Competitors all the same, working together to build this open standard and implementation of telemetry data for cloud native software and really any software right? Like we support over 12 languages. We support Kubernetes, Amazon. AWS is a huge contributor actually and we're doing some really exciting stuff with them on their Amazon distribution of OpenTelemetry. So it's been extremely interesting to see it over the past like couple years go from like, "Hey, here's this like new thing that we're doing over here," to really it's a generalized acceptance that this is the way of the future. This is what we should have been doing all along. >> Yeah. >> My opinion is there is a perception out there that observability is kind of a commodity now that all the players have the same set of tools, same set of 15 or 17 or whatever tools, and that there's very little distinction in functionality. Would you agree with that? >> I don't know if I would characterize it that way entirely. I do think that there's a lot of duplicated effort that happens and part of the reason is because of this telemetry data problem, right? Because you have to wind up... You know, there's this idea of table stakes monitoring that we talk about right? Table stakes monitoring is the stuff that you're having to do every single day to kind of make sure your system is healthy to be able to... When there's an alert, gets triggered, to see why it got triggered and to go fix it, right? Because everyone has the kind of work on that table stake stuff and then build all these integrations, there's very little time for innovation on top of that right? Because you're spending all your time just like working on keeping up with technology. >> Savannah: Doing the boring stuff to make sure the wheels don't fall off, basically. >> Austin: Right? What I think the real advantage of OpenTelemetry is that it really, from like a vendor perspective, like it unblocks us from having to kind of do all this repetitive commodified work. It lets us help move that out to the community level so that... Instead of having to kind of build, your Kubernetes integration for example, you can just have like, "Hey, OpenTelemetry is integrated into Kubernetes and you just have this data now." If you are a commercial product, or if you're even someone that's interested in fixing a, scratching a particular itch about observability. It's like, "I have this specific way that I'm doing Kubernetes and I need something to help me really analyze that data. Well, I've got the data now I can just go create a project. I can create an analysis tool." I think that's what you'll see over time as OpenTelemetry promulgates out into the ecosystem is more people building interesting analysis features, people using things like machine learning to analyze this large amount, large and consistent amount of OpenTelemetry data. It's going to be a big shakeup I think, but it has the potential to really unlock a lot of value for our customers. >> Well, so you're, you're a developer relations guy. What are developers asking for right now out of their observability platforms? >> Austin: That's a great question. I think there's two things. The first is that they want it to just work. It's actually the biggest thing, right? There's so many kind of... This goes back to the tool proliferation, right? People have too much data in too many different places, and getting that data out can still be really challenging. And so, the biggest thing they want is just like, "I want something that I can... I want a lot of these questions I have to ask, answered already and OpenTelemetry is going towards it." Keep in mind it's the project's only three years old, so we obviously have room to grow but there are people running it in production and it works really well for them but there's more that we can do. The second thing is, and this isn't what really is interesting to me, is it's less what they're asking for and more what they're not asking for. Because a lot of the stuff that you see people, saying around, "Oh, we need this like very specific sort of lower level telemetry data, or we need this kind of universal thing." People really just want to be able to get questions or get questions answered, right? They want tools that kind of have these workflows where you don't have to be an expert because a lot of times this tooling gets locked behind sort of is gate kept almost in a organization where there are teams that's like, "We're responsible for this and we're going to set it up and manage it for you, and we won't let you do things outside of it because that would mess up- >> Savannah: Here's your sandbox and- >> Right, this is your sandbox you can play in and a lot of times that's really useful and very tuned for the problems that you saw yesterday, but people are looking at like what are the problems I'm going to get tomorrow? We're deploying more rapidly. We have more and more intentional change happening in the system. Like it's not enough to have this reactive sort of approach where our SRE teams are kind of like or this observability team is building a platform for us. Developers want to be able to get in and have these kind of guided workflows really that say like, "Hey, here's where you're starting at. Let's get you to an answer. Let's help you find the needle in the haystack as it were, without you having to become a master of six different or seven different tools." >> Savannah: Right, and it shouldn't be that complicated. >> It shouldn't be. I mean we've certainly... We've been working on this problem for many years now, starting with a lot of our team that started at Google and helped build Google's planet scale monitoring systems. So we have a lot of experience in the field. It's actually one... An interesting story that our founder or now general manager tells BHS, Ben Sigelman, and he told me this story once and it's like... He had built this really cool thing called Dapper that was a tracing system at Google, and people weren't using it. Because they were like, "This is really cool, but I don't know how to... but it's not relevant to me." And he's like, the one thing that we did to get to increase usage 20 times over was we just put a link. So we went to the place that people were already looking for that data and we added a link that says, "Hey, go over here and look at this." It's those simple connections being able to kind of draw people from like point A to point B, take them from familiar workflows into unfamiliar ones. You know, that's how we think about these problems right? How is this becoming a daily part of someone's usage? How is this helping them solve problems faster and really improve their their life? >> Savannah: Yeah, exactly. It comes down to quality of life. >> Warner made the case this morning that computer architecture should be inherently event-driven and that we are moving toward a world where the person matters less than what the software does, right? The software is triggering events. Does this complicate observability or simplify it? >> Austin: I think that at the end of the day, it's about getting the... Observability to me in a lot of ways is about modeling your system, right? It's about you as a developer being able to say this is what I expect the system to do and I don't think the actual application architecture really matters that much, right? Because it's about you. You are building a system, right? It can be event driven, can be support request response, can be whatever it is. You have to be able to say, "This is what I expect to... For these given inputs, this is the expected output." Now maybe there's a lot of stuff that happens in the middle that you don't really care about. And then, I talk to people here and everyone's talking about serverless right? Everyone... You can see there's obviously some amazing statistics about how many people are using Lambda, and it's very exciting. There's a lot of stuff that you shouldn't have to care about as a developer, but you should care about those inputs and outputs. You will need to have that kind of intermediate information and understand like, what was the exact path that I took through this invented system? What was the actual resources that were being used? Because even if you trust that all this magic behind the scenes is just going to work forever, sometimes it's still really useful to have that sort of lower level abstraction, to say like, "Well, this is what actually happened so that I can figure out when I deployed a new change, did I make performance better or worse?" Or being able to kind of segregate your data out and say like... Doing AB testing, right? Doing canary releases, doing all of these things that you hear about as best practices or well architected applications. Observability is at the core of all that. You need observability to kind of do any of, ask any of those higher level interesting questions. >> Savannah: We are here at ReInvent. Tell us a little bit more about the partnership with AWS. >> So I would have to actually probably refer you to someone at Service Now on that. I know that we are a partner. We collaborate with them on various things. But really at Lightstep, we're very focused on kind of the open source part of this. So we work with AWS through the OpenTelemetry project, on things like the AWS distribution for OpenTelemetry which is really... It's OpenTelemetry, again is really designed to be like a neutral standard but we know that there are going to be integrators and implementers that need to package up and bundle it in a certain way to make it easy for their end users to consume it. So that's what Amazon has done with ADOT which is the shortening for it. So it's available in several different ways. You can use it as like an SDK and drop it into your application. There's Lambda layers. If you want to get Lambda observability, you just add this extension in and then suddenly you're getting OpenTelemetry data on the other side. So it's really cool. It's been a really exciting to kind of work with people on the AWS side over the past several years. >> Savannah: It's exciting, >> I've personally seen just a lot of change. I was talking to a PM earlier this week... It's like, "Hey, two years ago I came and talked to you about OpenTelemetry and here we are today. You're still talking about OpenTelemetry." And they're like, "What changes?" Our customers have started coming to us asking for OpenTelemetry and we see the same thing now. >> Savannah: Timing is right. >> Timing is right, but we see the same thing... Even talking to ServiceNow customers who are... These very big enterprises, banks, finance, healthcare, whatever, telcos, it used to be... You'd have to go to them and say like, "Let me tell you about distributed tracing. Let me tell you about OpenTelemetry. Let me tell you about observability." Now they're coming in and saying, "Yeah, so we're standard." If you think about Kubernetes and how Kubernetes, a lot of enterprises have spent the past five-six years standardizing, and Kubernetes is a way to deploy applications or manage containerized applications. They're doing the same journey now with OpenTelemetry where they're saying, "This is what we're betting on and we want partners we want people to help us go along that way." >> I love it, and they work hand in hand in all CNCF projects as well that you're talking about. >> Austin: Right, so we're integrated into Kubernetes. You can find OpenTelemetry and things like kept in which is application standards. And over time, it'll just like promulgate out from there. So it's really exciting times. >> A bunch of CNCF projects in this area right? Prometheus. >> Prometheus, yeah. Yeah, so we inter-operate with Prometheus as well. So if you have Prometheus metrics, then OpenTelemetry can read those. It's a... OpenTelemetry metrics are like a super set of Prometheus. We've been working with the Prometheus community for quite a while to make sure that there's really good compatibility because so many people use Prometheus you know? >> Yeah. All right, so last question. New tradition for us here on theCUBE. We're looking for your 32nd hot take, Instagram reel, biggest theme, biggest buzz for those not here on the show floor. >> Oh gosh. >> Savannah: It could be for you too. It could be whatever for... >> I think the two things that are really striking to me is one serverless. Like I see... I thought people were talking about servers a lot and they were talking about it more than ever. Two, I really think it is observability right? Like we've gone from observability being kind of a niche. >> Savannah: Not that you're biased. >> Huh? >> Savannah: Not that you're biased. >> Not that I'm biased. It used to be a niche. I'd have to go niche thing where I would go and explain what this is to people and nowpeople are coming up. It's like, "Yeah, yeah, we're using OpenTelemetry." It's very cool. I've been involved with OpenTelemetry since the jump, since it was started really. It's been very exciting to see and gratifying to see like how much adoption we've gotten even in a short amount of time. >> Yeah, absolutely. It's a pretty... Yeah, it's been a lot. That was great. Perfect soundbite for us. >> Austin: Thanks, I love soundbites. >> Savannah: Yeah. Awesome. We love your hat and your soundbites equally. Thank you so much for being on the show with us today. >> Thank you for having me. >> Savannah: Hey, anytime, anytime. Will we see you in Amsterdam, speaking of KubeCon? Awesome, we'll be there. >> There's some real exciting OpenTelemetry stuff coming up for KubeCon. >> Well, we'll have to get you back on theCUBE. (talking simultaneously) Love that for us. Thank you all for tuning in two hour wall to wall coverage here, day four at AWS re:Invent in fabulous Las Vegas, Nevada, with Paul Gillin. I'm Savannah Peterson and you're watching theCUBE, the leader in high tech coverage. (lively music)

(gentle music) >> Hello, welcome to theCUBE's presentation of the AWS Showcase season one, episode two with the ISV Startups partners. I'm John Furrier, your host of theCUBE. We're joined by Morgan McLean, director of product management at Splunk, and Danielle Greshock, who is the director of ISVs solution architects at AWS. Welcome to the show. Thanks for coming on. >> Thanks for having us. >> And great. Thanks for having us. >> Great to see both of you, both theCUBE alumni, but the Splunk-AWS relationship has been going very, very well. You guys are doing great business enabling this app revolution. And cloud scale has been going extremely well. So let's get into it. You guys are involved in a lot of action around application revolution, around OpenTelemetry and open source. So let's get into it. What's the latest? >> Danielle, you go ahead. >> Well, I'll just jump in first. Obviously last year, not last year, but in 2020, we launched the AWS Distro for OpenTelemetry. The idea being essentially, we're able to bring in data from partners, from infrastructure running on AWS, from apps running on AWS, to really be able to increase observability across all cloud assets at your entire cloud platform. So, Morgan, if you want to chime in on how Splunk >> Morgan: Certainly. >> has worked out OpenTelemetry. >> Yeah. I mean, OpenTelemetry is super exciting. Obviously, there's a lot of partnership points between Amazon and Splunk, but OpenTelemetry is probably one of them that's the most visible to people who aren't already maybe using these two products together. And so, as Danielle mentioned, Amazon has their own distribution of OpenTelemetry, Splunk has their own, as well, and of course there's the main open source distribution that everybody knows and loves. Just for our viewers, just for clarity's sake, the separate distributions are fundamentally very similar to, almost identical to what's offered in the open source space, but they come preconfigured and they come with support guarantees from each company, meaning that you can actually get paid full support for an open source project, which is really fantastic for customers. And as Danielle mentioned, it's a great demonstration of the alliance between Splunk and Amazon Web Services. For example, the AWS Distro, when you use it, can export data to Amazon CloudWatch, various Amazon backed open source initiatives like Prometheus and others, and to Splunk Observability Cloud and to Splunk Enterprise. So it's a place that we've worked very closely together, and it's something that we're very excited about. >> So, Morgan, I want to get your take on the on the product management side and also how product are built these days. >> One of the big things we're seeing in cloud is that open source has been the big enabler for a lot of refactoring. And you got multiple distributions, but the innovations on top of that, can you talk about how you see the productization of new innovations with open source as you guys go into this market, because this is the new dynamic with cloud. We're seeing examples all over the place. Obviously, Amazon's going next level with what they're doing, and that open source, it's not a one game for all of it. You can have mix and match. Take us through the product angle. >> And in many ways, this is just another wave of the same thing, right? Like, if you think back in time, we all used and still use in many cases, virtual machines, most of those are based on Linux, right? Another large open source project. And so, open source software has been accelerating innovation in the cloud space and in the computing space generally for a very long time, which is fantastic. Our excitement with something like OpenTelemetry comes from both the project's capabilities but also what we can do with it. So for those who aren't already familiar with OpenTelemetry, OpenTelemetry allows you to extract really critical system telemetry, application signals and everything else you need from your own applications, from new services, from your infrastructure, from everything that you're running in a cloud environment. You can then send that data to another location for processing. And so John, you ask like, how does this accelerate innovation? What does it unlock? Well, the insight you can gain from this data means you can become so much more efficient as a development organization. You can make your applications so much more effective because when you send that data to something like Splunk Observability Cloud, to something like Amazon CloudWatch, to various other solutions on the market, they can give you deep, deep insight into your application's performance, to its structure, they can help you reduce outages. And so, it's very, very powerful because it allows organizations to use tools like Splunk, like Amazon, like other things to innovate so much more effectively. >> Danielle, can you comment >> If I could... >> on the AWS side because this is again on the big point. You guys are going next level, and you're starting to see patterns in the ISV world, certainly on the architecture side of partners doing things differently now on top of what they've already done. Could you share how AWS is helping customers accelerate? >> Well, just as Morgan was talking about what OpenTelemetry provides, you can see how from a partnership perspective, this is so valuable, right? What the partner team here at AWS is in the business of doing, is really enabling customer choice, right? And having that ability to plug in and pull data from different sources, post it to different sources, make it available for visibility across all of your resources is very powerful and it's something from the partner community that we really value because we want customers to be able to select best of breed solutions, what works for their business, which businesses are different and they may have different needs, and that also fosters that true innovation. A small company is going to develop and release software a lot differently than a large enterprise. And so, being able to support something like OpenTelemetry just enables that for all different kinds of customers. >> Morgan, add to that because the velocity of releases, certainly operational, stability, is key every predominant security, uptime, these are top concerns. And, you mention data too, >> And you mention challenges. >> You got the data in here. So you got a lot of data moving around, a lot of value. What's your take? >> Yeah. So, I'll speak with some specifics. So a challenge that developers have had for years when you're developing large services, which you can now do with platforms like AWS. So, it's very easy to go develop huge deployments. But a challenge they have is you go and build a mess, right? And like, I've worked earlier in my career in Web Services. And I remember in one of the first orgs I was in, I was one of the five people who really understood our ecommerce stack. Right? And so like, I would get dragged into all these meetings and I'd have to go draw like the 50 services we had, and how they interacted, and the changes that were made in the last week. And without observability tools like Splunk Observability Cloud, like the ones offered by Amazon, like the ones that are backed by the data that comes with OpenTelemetry, organizations basically rely on people like this, to go draw out their deployments so they understand what it is they've built. Well, as you can imagine, this crimps your development velocity, because most of your engineers, most of your tech leads, most of everyone else don't actually understand what it is they've built what it is they're running, because they need that global context. You get something like OpenTelemetry and the solutions that consume the data from it, and suddenly now, all your developers have that context, all of them when they're adding functionality to a service or they're updating their infrastructure, can actually understand how it interacts with the rest of the broader application. This lets you speed up your time to development, this lets you ship more safely, more securely. And finally, when things do go wrong, which will be less frequent, but when they do go wrong, you can fix them super rapidly. >> If I'm a customer, let me ask a question. I'm a customer and I say, "Okay, I love AWS, I love Splunk, I love OpenTelemetry. I got to have open sources, technology innovation is happening." What's the integration? What are some of the standards? Can you take us through how that's working together with you guys as a shared platform? >> Yeah. So let's take the Amazon distribution for OpenTelemetry or even the Splunk one. One of the first things they do is they include all of the receivers, all of the sort of data capture components that you need, out of box for platforms like AWS, right? And so, right away, you get that power and flexibility where you're getting access to all of these data sources, right? And so, that's part of that partnership. And additionally, once the data comes into OpenTelemetry, you can now send that to various different data sources, including, as Danielle mentioned, to multiple at the same time. So you can use whatever tools you want. And so when you talk about like what the partnership is actually providing to you as a customer and still, this is just within the context of OpenTelemetry, obviously there's a much broader partnership between these two companies than just that. But within the context of OpenTelemetry means you can download one of these distributions. It's fully supported. It works with both solutions and everything is just great, right? You don't need to go fiddle with that out of the box. To be clear, OpenTelemetry is a batteries included project, right? This means that even the standard distributions of OpenTelemetry include the components you need. You have to go directly, reference them and ensure that they're packaged in there, but they exist, right. But the nice thing about these distributions is that it's done, it's out of the box, you don't even have to worry about is something missing or do I need to include new exporters or new receivers? It's all there. It's preconfigured. It just works. And if something goes wrong and you have a support contact, you pick up the phone, you talk to someone to get it fixed. >> Danielle, what's the Amazon side 'cause agility and scale is one of the highlights you guys are seeing. How does this tie into that and how are you guys working backwards from the customers to support the partners? >> Well, I think just to add on essentially to what Morgan said, I think that AWS is a cloud platform, has always really had a focus on developers. And, we talk a lot about how AWS and Amazon as a whole really embraces this continuous integration and continuous deployment methods inside of our organization. And we talk about services, and observability is a huge part of that. The only way that you're actually able to release hundreds, thousands of times a day like Amazon does, is by having an observability platform, to be able to measure metrics, see changes in the environment, to be able to roll back if you need to, and to be able to quickly mitigate any challenges or anything that goes wrong at any part of the process. And so, when we preach that to our customers, I think it's something that we do that because we live it and breathe it. And so, things such as OpenTelemetry and such as the products that Splunk builds, those are also ways in which we believe our customers can achieve that. >> Yeah. And we can... I mean, as I mentioned before, this partnership goes well beyond OpenTelemetry, right? And so, if you go use like Splunk Enterprise, Enterprise Cloud, Splunk Observability Cloud, and you're running on AWS, you have excellent support and excellent visibility into your Amazon infrastructure, into the services and applications you've deployed on top of that infrastructure. We try and give you, and I think we do succeed in this. We give you the best possible experience, the deepest possible visibility, into what it is you've deployed on AWS, so that you can be even more successful as a business, and so that you can be even more successful on AWS as a platform. >> Yeah. This is a great conversation, Morgan. You mentioned the early days of Web Services. AWS stands for Amazon Web Services built on web services. So interesting throwback there, but made me think about the days of the early days of web services. And if you look at data, what's going on now, the top partners in AWS, you're seeing a lot of people thinking about data differently, they're refactoring, a lot of machine learning, a lot of AI going on at scale. So then, you got cloud native, things like Kubernetes and these new services being stood up and teared down with automation. A whole new operating model's coming. And so when you think about observability, the importance of it, I mean, can you share your perspective on this whole 'nother level? I mean, I always say that whole another level sounds cliche, but it is next level. I mean, this is completely different. What's your reaction? >> Yeah. There there's a ton of factors here, right? So as you point out, companies are totally shifting how they use their cloud infrastructure. And part of this you see during their cloud migrations, a part of it you see after, and they're shifting from their sort of stateful VMs that they may have had in the past to infrastructure that they tear down and put up regularly. And there's a lot more automation. With this, comes as I mentioned before, complexity, right? And also, with this comes more and more businesses becoming even more reliant on their digital infrastructure. And so, not having observability into your applications, into your services, into your infrastructure, to me, is akin to running a business, say running a large warehousing or distribution company, but not having any idea where you're shipping products or where things are, or not having any accounting or CFO, right? Like, business has become so digital. Business is so reliant on technology, and that's unlocked a ton of new things. It's great. But not having visibility into how that technology works or what it is that's deployed or how to fix it is akin to having no visibility to anything else in your business. It's nuts. And so, observability is super, super critical, particularly for customers who are adopting this new wave of cloud technologies on platforms like AWS. >> Danielle, on your side too, you're enabling this new capability so that businesses can do it, the partners do it, we're calling it super cloud. We've been calling it super cloud kind of dynamic where new things are happening with the data. And you guys are evolving with that. Can you share what you're seeing on your side as your partners start to go to the next level? What are you guys doing? How does it all come together? >> Well, we always talk about what has happened with data in the last couple of years, which the cloud has really enabled around, you know, variety and velocity and there's one other "V" that's escaping me right now, but essentially, all of this data is coming in and providing the ability for us to make better decisions, to build better products, to provide better experiences for customers. And so, I just think, the OpenTelemetry project, as well as what Splunk is doing is just another example of how we're taking this massive amount of data and being able to provide better experiences and outcomes for customers. >> And you guys have been working along together for long time, Splunk, and, it's been a great partners, if we're going back with that been covering it on theCUBE and SiliconANGLE. So, we know that, the change is key observability. Can you imagine a company without a CFO, Morgan? That's just boggles your mind, but that's what it's like right now. So... >> It is, yeah. >> And the people who take advantage of that are winning, right? So it's like, that's the key. >> Yeah, I know. I mean, even in my own career, right, I've moved between different companies. And I remember, when I joined Google in particular, which is where I worked at previously, I was very impressed with their internal observability tools. And I'm certain, I haven't worked at Amazon. I'm certainly, I just assume inside of Amazon they're excellent as well, so a lot of the large cloud firms these days. But it was so refreshing going from an organization where if we had some outage or something went wrong, there were like a very small set of people who could actually understand what was going on. And then you would just have to manually dive through logs and correlate requests manually between services. It's very challenging. And so, when things went wrong, they went wrong for a long, long time. And so, the companies that understood this even in the past are already very successful as a result. I think now, the rest of the industry is really in the midst of adopting these observability practices and the tools that are required to implement them, because you're right. Otherwise your development velocity slows down. Now you're getting out competed by your competition. And then, when you have a problem, it blows up for ages. And once again, your competition can take advantage of it. >> And, can you just summarize the observability piece relative to the OpenTelemetry? Where is that going to go? Where do you see that evolving? >> Sure. >> I see open source is growing like crazy, we all know that. >> Of course. >> But OpenTelemetry in particular and open source, 'cause this is a big hot area. >> Yes. So to set the stage for people, OpenTelemetry, unlocks observability in many ways. As I mentioned earlier, OpenTelemetry is how you capture data out of your application. It doesn't process it. It's not a replacement for something like Amazon CloudWatch or any Splunk's products, but it's how we get the data out of your system, which is a remarkably difficult problem. I won't dive into it today, but, those who work in this space are very aware. That's why this project exists and it's so big, that actually extracting information, metrics, logs, distributed traces, profiles, everything else, from your applications and from your infrastructure is very, very difficult. So for OpenTelemetry, where it's going is just continually getting better at extracting more types of data from more sources, and doing that more effectively for people in a more standardized way. That will unlock firms like Splunk, firms, like Amazon and others to better process this data. In terms of where that's going, the sky's the limit, right? Like, everyone's familiar with APM, people are familiar with infrastructure monitoring, but there's a lot more capabilities coming there for security analytics, for network performance monitoring, for getting down all the way to single lines of coding your application, how they impact everything. There's just so much power that's coming to the industry right now. I'm really excited to see where things go in the next few years. >> And Danielle, you're in the middle of all the action as a solution architect, really set the stage for their companies and the ISVs, and this is a big, hot area. What are the patterns you're seeing and what are some of the best practices that you're doing will help companies? >> Right. So I think, summarizing our entire conversation, the big things that we're seeing in the market is essentially more and more companies are looking to move to a continuous deployment and a continuous integration environment. And they're looking to innovate faster and spend less time hot patching or hot fixing their environments and they want to spend more time innovating. And so, that you know, the patterns that we're seeing is... What I see and what I actually experience firsthand at re:Invent when I talk to probably over 40 or 50 ISVs, is customers want to know in their environment, where are their changes? Where are their security vulnerabilities? Where are their data changes, and what are customers really experiencing, whether it's latency, poor experience throughout their products, those types of things? So security, data, and observability are just key to all of that experience and that's what we're definitely seeing as patterns, what we're seeing with our customers and also what value our ISVs are providing in that space. >> That's awesome. And the other thing I would observe is that there's more of an integration story going on around joint projects, whether it's open source. >> Absolutely. >> Because this is where we want to get that services connected. And it's mutual beneficial. I mean, this is really >> Exactly. >> whole 'nother, new kind of interoperable cloud scale. >> Yeah, if I could say one thing else there, I think that, a lot of the customers who are trying to move into the cloud now are, maybe not technology forward companies and they really need that solution. And that's very important. I think COVID has pushed a lot of companies into the cloud maybe very quickly. And, that has been something else we've observed in the market. So, solutions and full solutions between ISVs and ISVs, or ISVs and AWS is just becoming more and more common thing that we see. >> And, you mentioned John, in the open source space as well. Like, we're certainly from Amazon to Splunk. So we're talking a lot about those, but there's a lot of other firms involved in projects like OpenTelemetry. And I think it's very endearing, very heartening to see how well they cooperate in this community and how, when their interests are aligned, how effective they can be. And it's been very exciting to work in the space and very pleasant, honestly, to see everything come together with this huge set of customers and partners. >> Yeah. The pleasant surprise of the pandemic has been that people come into the cloud and they like it and they, "Hey, this works," and they double down on it. Then they realize, there's more there and they refactor. So, you're seeing real examples of that. So, this is a great discussion, great success story. Congratulations Morgan, Danielle. >> Thank you. >> Great partnership between Splunk and AWS. We've been following for a long time. And again, this highlights this whole another level of integrating super cloud kind of experience where people are getting more capabilities and doing more together, so great stuff. >> And this is just one facet of that, right? Like, there's all the other connections of Splunk Enterprise, Splunk security analytics products, and others. It's a deep, deep partnership between these firms. >> Yeah. And the companies that innovate and get that new capability are going to have an advantage. And you're seeing... >> Yes. >> Right? >> Agreed. >> And this is awesome, and great stuff, thank you for coming on and sharing that insight. >> Thank you. >> Congratulations Morgan over there at Splunk, great stuff. And Danielle, thanks for coming on and sharing the AWS perspective. >> Thanks for having me. >> And you guys are going to the next level. You moving up to stack as they say, all good stuff for customers. Thanks. >> Thank you. >> Okay. >> Thank you. >> This is season one, episode two of the AWS Partner Showcase. I'm John Furrier with theCUBE. Thanks for watching. (gentle music)

(gentle music) >> Hello, welcome to theCUBE's presentation of the AWS Showcase season one, episode two with the ISV Startups partners. I'm John Furrier, your host of theCUBE. We're joined by Morgan McLean, director of product management at Splunk, and Danielle Greshock, who is the director of ISVs solution architects at AWS. Welcome to the show. Thanks for coming on. >> Thanks for having us. >> And great. Thanks for having us. >> Great to see both of you, both theCUBE alumni, but the Splunk-AWS relationship has been going very, very well. You guys are doing great business enabling this app revolution. And cloud scale has been going extremely well. So let's get into it. You guys are involved in a lot of action around application revolution, around OpenTelemetry and open source. So let's get into it. What's the latest? >> Danielle, you go ahead. >> Well, I'll just jump in first. Obviously last year, not last year, but in 2020, we launched the AWS Distro for OpenTelemetry. The idea being essentially, we're able to bring in data from partners, from infrastructure running on AWS, from apps running on AWS, to really be able to increase observability across all cloud assets at your entire cloud platform. So, Morgan, if you want to chime in on how Splunk >> Morgan: Certainly. >> has worked out OpenTelemetry. >> Yeah. I mean, OpenTelemetry is super exciting. Obviously, there's a lot of partnership points between Amazon and Splunk, but OpenTelemetry is probably one of them that's the most visible to people who aren't already maybe using these two products together. And so, as Danielle mentioned, Amazon has their own distribution of OpenTelemetry, Splunk has their own, as well, and of course there's the main open source distribution that everybody knows and loves. Just for our viewers, just for clarity's sake, the separate distributions are fundamentally very similar to, almost identical to what's offered in the open source space, but they come preconfigured and they come with support guarantees from each company, meaning that you can actually get paid full support for an open source project, which is really fantastic for customers. And as Danielle mentioned, it's a great demonstration of the alliance between Splunk and Amazon Web Services. For example, the AWS Distro, when you use it, can export data to Amazon CloudWatch, various Amazon backed open source initiatives like Prometheus and others, and to Splunk Observability Cloud and to Splunk Enterprise. So it's a place that we've worked very closely together, and it's something that we're very excited about. >> So, Morgan, I want to get your take on the on the product management side and also how product are built these days. >> One of the big things we're seeing in cloud is that open source has been the big enabler for a lot of refactoring. And you got multiple distributions, but the innovations on top of that, can you talk about how you see the productization of new innovations with open source as you guys go into this market, because this is the new dynamic with cloud. We're seeing examples all over the place. Obviously, Amazon's going next level with what they're doing, and that open source, it's not a one game for all of it. You can have mix and match. Take us through the product angle. >> And in many ways, this is just another wave of the same thing, right? Like, if you think back in time, we all used and still use in many cases, virtual machines, most of those are based on Linux, right? Another large open source project. And so, open source software has been accelerating innovation in the cloud space and in the computing space generally for a very long time, which is fantastic. Our excitement with something like OpenTelemetry comes from both the project's capabilities but also what we can do with it. So for those who aren't already familiar with OpenTelemetry, OpenTelemetry allows you to extract really critical system telemetry, application signals and everything else you need from your own applications, from new services, from your infrastructure, from everything that you're running in a cloud environment. You can then send that data to another location for processing. And so John, you ask like, how does this accelerate innovation? What does it unlock? Well, the insight you can gain from this data means you can become so much more efficient as a development organization. You can make your applications so much more effective because when you send that data to something like Splunk Observability Cloud, to something like Amazon CloudWatch, to various other solutions on the market, they can give you deep, deep insight into your application's performance, to its structure, they can help you reduce outages. And so, it's very, very powerful because it allows organizations to use tools like Splunk, like Amazon, like other things to innovate so much more effectively. >> Danielle, can you comment >> If I could... >> on the AWS side because this is again on the big point. You guys are going next level, and you're starting to see patterns in the ISV world, certainly on the architecture side of partners doing things differently now on top of what they've already done. Could you share how AWS is helping customers accelerate? >> Well, just as Morgan was talking about what OpenTelemetry provides, you can see how from a partnership perspective, this is so valuable, right? What the partner team here at AWS is in the business of doing, is really enabling customer choice, right? And having that ability to plug in and pull data from different sources, post it to different sources, make it available for visibility across all of your resources is very powerful and it's something from the partner community that we really value because we want customers to be able to select best of breed solutions, what works for their business, which businesses are different and they may have different needs, and that also fosters that true innovation. A small company is going to develop and release software a lot differently than a large enterprise. And so, being able to support something like OpenTelemetry just enables that for all different kinds of customers. >> Morgan, add to that because the velocity of releases, certainly operational, stability, is key every predominant security, uptime, these are top concerns. And, you mention data too, >> And you mention challenges. >> You got the data in here. So you got a lot of data moving around, a lot of value. What's your take? >> Yeah. So, I'll speak with some specifics. So a challenge that developers have had for years when you're developing large services, which you can now do with platforms like AWS. So, it's very easy to go develop huge deployments. But a challenge they have is you go and build a mess, right? And like, I've worked earlier in my career in Web Services. And I remember in one of the first orgs I was in, I was one of the five people who really understood our ecommerce stack. Right? And so like, I would get dragged into all these meetings and I'd have to go draw like the 50 services we had, and how they interacted, and the changes that were made in the last week. And without observability tools like Splunk Observability Cloud, like the ones offered by Amazon, like the ones that are backed by the data that comes with OpenTelemetry, organizations basically rely on people like this, to go draw out their deployments so they understand what it is they've built. Well, as you can imagine, this crimps your development velocity, because most of your engineers, most of your tech leads, most of everyone else don't actually understand what it is they've built what it is they're running, because they need that global context. You get something like OpenTelemetry and the solutions that consume the data from it, and suddenly now, all your developers have that context, all of them when they're adding functionality to a service or they're updating their infrastructure, can actually understand how it interacts with the rest of the broader application. This lets you speed up your time to development, this lets you ship more safely, more securely. And finally, when things do go wrong, which will be less frequent, but when they do go wrong, you can fix them super rapidly. >> If I'm a customer, let me ask a question. I'm a customer and I say, "Okay, I love AWS, I love Splunk, I love OpenTelemetry. I got to have open sources, technology innovation is happening." What's the integration? What are some of the standards? Can you take us through how that's working together with you guys as a shared platform? >> Yeah. So let's take the Amazon distribution for OpenTelemetry or even the Splunk one. One of the first things they do is they include all of the receivers, all of the sort of data capture components that you need, out of box for platforms like AWS, right? And so, right away, you get that power and flexibility where you're getting access to all of these data sources, right? And so, that's part of that partnership. And additionally, once the data comes into OpenTelemetry, you can now send that to various different data sources, including, as Danielle mentioned, to multiple at the same time. So you can use whatever tools you want. And so when you talk about like what the partnership is actually providing to you as a customer and still, this is just within the context of OpenTelemetry, obviously there's a much broader partnership between these two companies than just that. But within the context of OpenTelemetry means you can download one of these distributions. It's fully supported. It works with both solutions and everything is just great, right? You don't need to go fiddle with that out of the box. To be clear, OpenTelemetry is a batteries included project, right? This means that even the standard distributions of OpenTelemetry include the components you need. You have to go directly, reference them and ensure that they're packaged in there, but they exist, right. But the nice thing about these distributions is that it's done, it's out of the box, you don't even have to worry about is something missing or do I need to include new exporters or new receivers? It's all there. It's preconfigured. It just works. And if something goes wrong and you have a support contact, you pick up the phone, you talk to someone to get it fixed. >> Danielle, what's the Amazon side 'cause agility and scale is one of the highlights you guys are seeing. How does this tie into that and how are you guys working backwards from the customers to support the partners? >> Well, I think just to add on essentially to what Morgan said, I think that AWS is a cloud platform, has always really had a focus on developers. And, we talk a lot about how AWS and Amazon as a whole really embraces this continuous integration and continuous deployment methods inside of our organization. And we talk about services, and observability is a huge part of that. The only way that you're actually able to release hundreds, thousands of times a day like Amazon does, is by having an observability platform, to be able to measure metrics, see changes in the environment, to be able to roll back if you need to, and to be able to quickly mitigate any challenges or anything that goes wrong at any part of the process. And so, when we preach that to our customers, I think it's something that we do that because we live it and breathe it. And so, things such as OpenTelemetry and such as the products that Splunk builds, those are also ways in which we believe our customers can achieve that. >> Yeah. And we can... I mean, as I mentioned before, this partnership goes well beyond OpenTelemetry, right? And so, if you go use like Splunk Enterprise, Enterprise Cloud, Splunk Observability Cloud, and you're running on AWS, you have excellent support and excellent visibility into your Amazon infrastructure, into the services and applications you've deployed on top of that infrastructure. We try and give you, and I think we do succeed in this. We give you the best possible experience, the deepest possible visibility, into what it is you've deployed on AWS, so that you can be even more successful as a business, and so that you can be even more successful on AWS as a platform. >> Yeah. This is a great conversation, Morgan. You mentioned the early days of Web Services. AWS stands for Amazon Web Services built on web services. So interesting throwback there, but made me think about the days of the early days of web services. And if you look at data, what's going on now, the top partners in AWS, you're seeing a lot of people thinking about data differently, they're refactoring, a lot of machine learning, a lot of AI going on at scale. So then, you got cloud native, things like Kubernetes and these new services being stood up and teared down with automation. A whole new operating model's coming. And so when you think about observability, the importance of it, I mean, can you share your perspective on this whole 'nother level? I mean, I always say that whole another level sounds cliche, but it is next level. I mean, this is completely different. What's your reaction? >> Yeah. There there's a ton of factors here, right? So as you point out, companies are totally shifting how they use their cloud infrastructure. And part of this you see during their cloud migrations, a part of it you see after, and they're shifting from their sort of stateful VMs that they may have had in the past to infrastructure that they tear down and put up regularly. And there's a lot more automation. With this, comes as I mentioned before, complexity, right? And also, with this comes more and more businesses becoming even more reliant on their digital infrastructure. And so, not having observability into your applications, into your services, into your infrastructure, to me, is akin to running a business, say running a large warehousing or distribution company, but not having any idea where you're shipping products or where things are, or not having any accounting or CFO, right? Like, business has become so digital. Business is so reliant on technology, and that's unlocked a ton of new things. It's great. But not having visibility into how that technology works or what it is that's deployed or how to fix it is akin to having no visibility to anything else in your business. It's nuts. And so, observability is super, super critical, particularly for customers who are adopting this new wave of cloud technologies on platforms like AWS. >> Danielle, on your side too, you're enabling this new capability so that businesses can do it, the partners do it, we're calling it super cloud. We've been calling it super cloud kind of dynamic where new things are happening with the data. And you guys are evolving with that. Can you share what you're seeing on your side as your partners start to go to the next level? What are you guys doing? How does it all come together? >> Well, we always talk about what has happened with data in the last couple of years, which the cloud has really enabled around, you know, variety and velocity and there's one other "V" that's escaping me right now, but essentially, all of this data is coming in and providing the ability for us to make better decisions, to build better products, to provide better experiences for customers. And so, I just think, the OpenTelemetry project, as well as what Splunk is doing is just another example of how we're taking this massive amount of data and being able to provide better experiences and outcomes for customers. >> And you guys have been working along together for long time, Splunk, and, it's been a great partners, if we're going back with that been covering it on theCUBE and SiliconANGLE. So, we know that, the change is key observability. Can you imagine a company without a CFO, Morgan? That's just boggles your mind, but that's what it's like right now. So... >> It is, yeah. >> And the people who take advantage of that are winning, right? So it's like, that's the key. >> Yeah, I know. I mean, even in my own career, right, I've moved between different companies. And I remember, when I joined Google in particular, which is where I worked at previously, I was very impressed with their internal observability tools. And I'm certain, I haven't worked at Amazon. I'm certainly, I just assume inside of Amazon they're excellent as well, so a lot of the large cloud firms these days. But it was so refreshing going from an organization where if we had some outage or something went wrong, there were like a very small set of people who could actually understand what was going on. And then you would just have to manually dive through logs and correlate requests manually between services. It's very challenging. And so, when things went wrong, they went wrong for a long, long time. And so, the companies that understood this even in the past are already very successful as a result. I think now, the rest of the industry is really in the midst of adopting these observability practices and the tools that are required to implement them, because you're right. Otherwise your development velocity slows down. Now you're getting out competed by your competition. And then, when you have a problem, it blows up for ages. And once again, your competition can take advantage of it. >> And, can you just summarize the observability piece relative to the OpenTelemetry? Where is that going to go? Where do you see that evolving? >> Sure. >> I see open source is growing like crazy, we all know that. >> Of course. >> But OpenTelemetry in particular and open source, 'cause this is a big hot area. >> Yes. So to set the stage for people, OpenTelemetry, unlocks observability in many ways. As I mentioned earlier, OpenTelemetry is how you capture data out of your application. It doesn't process it. It's not a replacement for something like Amazon CloudWatch or any Splunk's products, but it's how we get the data out of your system, which is a remarkably difficult problem. I won't dive into it today, but, those who work in this space are very aware. That's why this project exists and it's so big, that actually extracting information, metrics, logs, distributed traces, profiles, everything else, from your applications and from your infrastructure is very, very difficult. So for OpenTelemetry, where it's going is just continually getting better at extracting more types of data from more sources, and doing that more effectively for people in a more standardized way. That will unlock firms like Splunk, firms, like Amazon and others to better process this data. In terms of where that's going, the sky's the limit, right? Like, everyone's familiar with APM, people are familiar with infrastructure monitoring, but there's a lot more capabilities coming there for security analytics, for network performance monitoring, for getting down all the way to single lines of coding your application, how they impact everything. There's just so much power that's coming to the industry right now. I'm really excited to see where things go in the next few years. >> And Danielle, you're in the middle of all the action as a solution architect, really set the stage for their companies and the ISVs, and this is a big, hot area. What are the patterns you're seeing and what are some of the best practices that you're doing will help companies? >> Right. So I think, summarizing our entire conversation, the big things that we're seeing in the market is essentially more and more companies are looking to move to a continuous deployment and a continuous integration environment. And they're looking to innovate faster and spend less time hot patching or hot fixing their environments and they want to spend more time innovating. And so, that you know, the patterns that we're seeing is... What I see and what I actually experience firsthand at re:Invent when I talk to probably over 40 or 50 ISVs, is customers want to know in their environment, where are their changes? Where are their security vulnerabilities? Where are their data changes, and what are customers really experiencing, whether it's latency, poor experience throughout their products, those types of things? So security, data, and observability are just key to all of that experience and that's what we're definitely seeing as patterns, what we're seeing with our customers and also what value our ISVs are providing in that space. >> That's awesome. And the other thing I would observe is that there's more of an integration story going on around joint projects, whether it's open source. >> Absolutely. >> Because this is where we want to get that services connected. And it's mutual beneficial. I mean, this is really >> Exactly. >> whole 'nother, new kind of interoperable cloud scale. >> Yeah, if I could say one thing else there, I think that, a lot of the customers who are trying to move into the cloud now are, maybe not technology forward companies and they really need that solution. And that's very important. I think COVID has pushed a lot of companies into the cloud maybe very quickly. And, that has been something else we've observed in the market. So, solutions and full solutions between ISVs and ISVs, or ISVs and AWS is just becoming more and more common thing that we see. >> And, you mentioned John, in the open source space as well. Like, we're certainly from Amazon to Splunk. So we're talking a lot about those, but there's a lot of other firms involved in projects like OpenTelemetry. And I think it's very endearing, very heartening to see how well they cooperate in this community and how, when their interests are aligned, how effective they can be. And it's been very exciting to work in the space and very pleasant, honestly, to see everything come together with this huge set of customers and partners. >> Yeah. The pleasant surprise of the pandemic has been that people come into the cloud and they like it and they, "Hey, this works," and they double down on it. Then they realize, there's more there and they refactor. So, you're seeing real examples of that. So, this is a great discussion, great success story. Congratulations Morgan, Danielle. >> Thank you. >> Great partnership between Splunk and AWS. We've been following for a long time. And again, this highlights this whole another level of integrating super cloud kind of experience where people are getting more capabilities and doing more together, so great stuff. >> And this is just one facet of that, right? Like, there's all the other connections of Splunk Enterprise, Splunk security analytics products, and others. It's a deep, deep partnership between these firms. >> Yeah. And the companies that innovate and get that new capability are going to have an advantage. And you're seeing... >> Yes. >> Right? >> Agreed. >> And this is awesome, and great stuff, thank you for coming on and sharing that insight. >> Thank you. >> Congratulations Morgan over there at Splunk, great stuff. And Danielle, thanks for coming on and sharing the AWS perspective. >> Thanks for having me. >> And you guys are going to the next level. You moving up to stack as they say, all good stuff for customers. Thanks. >> Thank you. >> Okay. >> Thank you. >> This is season one, episode two of the AWS Partner Showcase. I'm John Furrier with theCUBE. Thanks for watching. (gentle music)

(upbeat music) >> Hello, and welcome back to AWS Startup Showcase, I'm John Furrier, your host. This is the Hero panel, the AWS Heroes. These are folks that have a lot of experience in Open Source, having fun building great projects and commercializing the value and best practices of Open Source innovation. We've got some great guests here. Liz Rice, Chief Open Source Officer, Isovalent. CUBE alumni, great to see you. Brian LeRoux, who is the Co-founder and CTO of begin.com. Erica Windisch who's an Architect for Developer Experience. AWS Hero, also CUBE alumni. Casey Lee, CTO Gaggle. Doing some great stuff in ed tech. Great collection of experts and experienced folks doing some fun stuff, welcome to this conversation this CUBE panel. >> Hi. >> Thanks for having us. >> Hello. >> Let's go down the line. >> I don't normally do this, but since we're remote and we have such great guests, go down the line and talk about why Open Source is important to you guys. What projects are you currently working on? And what's the coolest thing going on there? Liz we'll start with you. >> Okay, so I am very involved in the world of Cloud Native. I'm the chair of the technical oversight committee for the Cloud Native Computing Foundation. So that means I get to see a lot of what's going on across a very broad range of Cloud Native projects. More specifically, Isovalent. I focus on Cilium, which is it's based on a technology called EBPF. That is to me, probably the most exciting technology right now. And then finally, I'm also involved in an organization called OpenUK, which is really pushing for more use of open technologies here in the United Kingdom. So spread around lots of different projects. And I'm in a really fortunate position, I think, to see what's happening with lots of projects and also the commercialization of lots of projects. >> Awesome, Brian what project are you working on? >> Working project these days called Architect. It's a Open Source project built on top of AWSM. It adds a lot of sugar and terseness to the SM experience and just makes it a lot easier to work with and get started. AWS can be a little bit intimidating to people at times. And the Open Source community is stepping up to make some of that bond ramp a little bit easier. And I'm also an Apache member. And so I keep a hairy eyeball on what's going on in that reality all the time. And I've been doing this open-source thing for quite a while, and yeah, I love it. It's a great thing. It's real science. We get to verify each other's work and we get to expand and build on human knowledge. So that's a huge honor to just even be able to do that and I feel stoked to be here so thanks for having me. >> Awesome, yeah, and totally great. Erica, what's your current situation going on here? What's happening? >> Sure, so I am currently working on developer experience of a number of Open Source STKS and CLI components from my current employer. And previously, recently I left New Relic where I was working on integrating with OpenTelemetry, as well as a number of other things. Before that I was a maintainer of Docker and of OpenStack. So I've been in this game for a while as well. And I tend to just put my fingers in a lot of little pies anywhere from DVD players 20 years ago to a lot of this open telemetry and monitoring and various STKs and developer tools is where like Docker and OpenStack and the STKs that I work on now, all very much focusing on developer as the user. >> Yeah, you're always on the wave, Erica great stuff. Casey, what's going on? Do you got some great ed techs happening? What's happening with you? >> Yeah, sure. The primary Open Source project that I'm contributing to right now is ACT. This is a tool I created a couple of years back when GitHub Actions first came out, and my motivation there was I'm just impatient. And that whole commit, push, wait time where you're testing out your pipelines is painful. And so I wanted to build a tool that allowed developers to test out their GitHub Actions workflows locally. And so this tool uses Docker containers to emulate, to get up action environment and gives you fast feedback on those workflows that you're building. Lot of innovation happening at GitHub. And so we're just trying to keep up and continue to replicate those new features functionalities in the local runner. And the biggest challenge I've had with this project is just keeping up with the community. We just passed 20,000 stars, and it'd be it's a normal week to get like 10 PRs. So super excited to announce just yesterday, actually I invited four of the most active contributors to help me with maintaining the project. And so this is like a big deal for me, letting the project go and bringing other people in to help lead it. So, yeah, huge shout out to those folks that have been helping with driving that project. So looking forward to what's next for it. >> Great, we'll make sure the SiliconANGLE riders catch that quote there. Great call out. Let's start, Brian, you made me realize when you mentioned Apache and then you've been watching all the stuff going on, it brings up the question of the evolution of Open Source, and the commercialization trends have been very interesting these days. You're seeing CloudScale really impact also with the growth of code. And Liz, if you remember, the Linux Foundation keeps making projections and they keep blowing past them every year on more and more code and more and more entrance coming in, not just individuals, corporations. So you starting to see Netflix donates something, you got Lyft donate some stuff, becomes a project company forms around it. There's a lot of entrepreneurial activity that's creating this new abstraction layers, new platforms, not just tools. So you start to see a new kickup trajectory with Open Source. You guys want to comment on this because this is going to impact how fast the enterprise will see value here. >> I think a really great example of that is a project called Backstage that's just come out of Spotify. And it's going through the incubation process at the CNCF. And that's why it's front of mind for me right now, 'cause I've been working on the due diligence for that. And the reason why I thought it was interesting in relation to your question is it's spun out of Spotify. It's fully Open Source. They have a ton of different enterprises using it as this developer portal, but they're starting to see some startups emerging offering like a hosted managed version of Backstage or offering services around Backstage or offering commercial plugins into Backstage. And I think it's really fascinating to see those ecosystems building up around a project and different ways that people can. I'm a big believer. You cannot sell the Open Source code, but you can sell other things that create value around Open Source projects. So that's really exciting to see. >> Great point. Anyone else want to weigh in and react to that? Because it's the new model. It's not the old way. I mean, I remember when I was in college, we had the Pirate software. Open Source wasn't around. So you had to deal under the table. Now it's free. But I mean the old way was you had to convince the enterprise, like you've got a hard knit, it builds the community and the community manage the quality of the code. And then you had to build the company to make sure they could support it. Now the companies are actually involved in it, right? And then new startups are forming faster. And the proof points are shorter and highly accelerated for that. I mean, it's a whole new- >> It's a Cambrian explosion, and it's great. It's one of those things that it's challenging for the new developers because they come in and they're like, "Whoa, what is all this stuff that I'm supposed to figure out?" And there's no right answer and there's no wrong answer. There's just tons of it. And I think that there's a desire for us to have one sort of well-known trot and happy path, that audience we're a lot better with a more diverse community, with lots of options, with lots of ways to approach these problems. And I think it's just great. A challenge that we have with all these options and all these Cambrian explosion of projects and all these competing ideas, right now, the sustainability, it's a bit of a tricky question to answer. We know that there's a commercialization aspect that helps us fund these projects, but how we compose the open versus the commercial source is still a bit of a tricky question and a tough one for a lot of folks. >> Erica, would you chime in on that for a second. I want to get your angle on that, this experience and all this code, and I'm a new person, I'm an existing person. Do I get like a blue check mark and verify? I mean, these are questions like, well, how do you navigate? >> Yeah, I think this has been something happening for a while. I mean, back in the early OpenStack days, 2010, for instance, Rackspace Open Sourcing, OpenStack and ANSU Labs and so forth, and then trying, having all these companies forming in creating startups around this. I started at a company called Cloudccaling back in late 2010, and we had some competitors such as Piston and so forth where a lot of the ANSUL Labs people went. But then, the real winners, I think from OpenStack ended up being the enterprises that jumped in. We had Red Hat in particular, as well as HP and IBM jumping in and investing in OpenStack, and really proving out a lot of... not that it was the first time, but this is when we started seeing billions of dollars pouring into Open Source projects and Open Source Foundations, such as the OpenStack Foundation, which proceeded a lot of the things that we now see with the Linux Foundation, which was then created a little bit later. And at the same time, I'm also reflecting a little bit what Brian said because there are projects that don't get funded, that don't get the same attention, but they're also getting used quite significantly. Things like Log4j really bringing this to the spotlight in terms of projects that are used everywhere by everything with significant outsized impacts on the industry that are not getting funded, that aren't flashy enough, that aren't exciting enough because it's just logging, but a vulnerability in it brings every everything and everybody down and has possibly billions of dollars of impact to our industry because nobody wanted to fund this project. >> I think that brings up the commercialization point about maybe bringing a venture capital model in saying, "Hey, that boring little logging thing could be a key ingredient for say solving some observability problems so I think let's put some cash." Again then we'd never seen that before. Now you're starting to see that kind of a real smart investment thesis going into Open Source projects. I mean, Promethease, Crafter, these are projects that turned off companies. This is turning up companies. >> A decade ago, there was no money in Dev tools that I think that's been fully debunked now. They used to be a concept that the venture community believed, but there's just too much evidence to the contrary, the companies like Cash Court, Datadog, the list goes on and on. I think the challenge for the Open Source (indistinct) comes back to foundations and working (indistinct) these developers make this code safe and secure. >> Casey, what's your reaction to all of this? You've got, so a project has gained some traction, got some momentum. There's a lot of mission critical. I won't say white spaces, but the opportunities in the big cloud game happening. And there's a lot of, I won't say too many entrepreneurial, but there's a lot of community action happening that's precommercialization that's getting traction. How does this all develop naturally and then vector in quickly when it hits? >> Yeah, I want to go back to the Log4j topic real quick. I think that it's a great example of an area that we need to do better at. And there was a cool article that Rob Pike wrote describing how to quantify the criticality. I think that's sort of quantifying criticality was the article he wrote on how to use metrics, to determine how valuable, how important a piece of Open Source is to the community. And we really need to highlight that more. We need a way to make it more clear how important this software is, how many people depend on it and how many people are contributing to it. And because right now we all do that. Like if I'm going to evaluate an Open Source software, sure, I'll look at how many stars it has and how many contributors it has. But I got to go through and do all that work myself and come up with. It would be really great if we had an agreed upon method for ranking the criticality of software, but then also the risk, hey, that this is used by a ton of people, but nobody's contributing to it anymore. That's a concern. And that would be great to potential users of that to signal whether or not it makes sense. The Open Source Security Foundation, just getting off the ground, they're doing some work in this space, and I'm really excited to see where they go with that looking at ways to stop score critically. >> Well, this brings up a good point while we've got everyone here, let's take a plug and plug a project you think that's not getting the visibility it needs. Let's go through each of you, point out a project that you think people should be looking at and talking about that might get some free visibility here. Anyone want to highlight projects they think should be focused more on, or that needs a little bit of love? >> I think, I mean, particularly if we're talking about these sort of vulnerability issues, there's a ton of work going on, like in the Secure Software Foundation, other foundations, I think there's work going on in Apache somewhere as well around the bill of material, the software bill of materials, the Secure Software supply chain security, even enumerating your dependencies is not trivial today. So I think there's going to be a ton of people doing really good work on that, as well as the criticality aspect. It's all like that. There's a really great xkcd cartoon with your software project and some really big monolithic lumps. And then, this tiny little piece in a very important point that's maintained by somebody in his bedroom in Montana or something and if you called it out. >> Yeah, you just opened where the next lightening and a bottle comes from. And this is I think the beauty of Open Source is that you get a little collaboration, you get three feet in a cloud of dust going and you get some momentum, and if it's relevant, it rises to the top. I think that's the collective intelligence of Open Source. The question I want to ask that the panel here is when you go into an enterprise, and now that the game is changing with a much more collaborative and involved, what's the story if they say, hey, what's in it for me, how do I manage the Open Source? What's the current best practice? Because there's no doubt I can't ignore it. It's in everything we do. How do I organize around it? How do I build around it to be more efficient and more productive and reduce the risk on vulnerabilities to managing staff, making sure the right teams in place, the right agility and all those things? >> You called it, they got to get skin in the game. They need to be active and involved and donating to a sustainable Open Source project is a great way to start. But if you really want to be active, then you should be committing. You should have a goal for your organization to be contributing back to that project. Maybe not committing code, it could be committing resources into the darks or in the tests, or even tweeting about an Open Source project is contributing to it. And I think a lot of these enterprises could benefit a lot from getting more active with the Open Source Foundations that are out there. >> Liz, you've been actively involved. I know we've talked personally when the CNCF started, which had a great commercial uptake from companies. What do you think the current state-of-the-art kind of equation is has it changed a little bit? Or is it the game still the same? >> Yeah, and in the early days of the CNCF, it was very much dominated by vendors behind the project. And now we're seeing more and more membership from end-user companies, the kind of enterprises that are building their businesses on Cloud Native, but their business is not in itself. That's not there. The infrastructure is not their business. And I think seeing those companies, putting money in, putting time in, as Brian says contributing resources quite often, there's enough money, but finding the talent to do the work and finding people who are prepared to actually chop the wood and carry the water, >> Exactly. >> that it's hard. >> And if enterprises can find peoples to spend time on Open Source projects, help with those chores, it's hugely valuable. And it's one of those the rising tide floats all the boats. We can raise security, we can reduce the amount of dependency on maintain projects collectively. >> I think the business models there, I think one of the things I'll react to and then get your guys' comments is remember which CubeCon it was, it was one of the early ones. And I remember seeing Apple having a booth, but nobody was manning. It was just an Apple booth. They weren't doing anything, but they were recruiting. And I think you saw the transition of a business model where the worry about a big vendor taking over a project and having undue influence over it goes away because I think this idea of participation is also talent, but also committing that talent back into the communities as a model, as a business model, like, okay, hire some great people, but listen, don't screw up the Open Source piece of it 'cause that's a critical. >> Also hire a channel, right? They can use those contributions to source that talent and build the reputation in the communities that they depend on. And so there's really a lot of benefit to the larger organizations that can do this. They'll have a huge pipeline of really qualified engineers right out the gate without having to resort to cheesy whiteboard interviews, which is pretty great. >> Yeah, I agree with a lot of this. One of my concerns is that a lot of these corporations tend to focus very narrowly on certain projects, which they feel that they depend greatly, they'll invest in OpenStack, they'll invest in Docker, they'll invest in some of the CNCF projects. And then these other projects get ignored. Something that I've been a proponent of for a little bit for a while is observability of your dependencies. And I don't think there's quite enough projects and solutions to this. And it sounds maybe from lists, there are some projects that I don't know about, but I also know that there's some startups like Snyk and so forth that help with a little bit of this problem, but I think we need more focus on some of these edges. And I think companies need to do better, both in providing, having some sort of solution for observability of the dependencies, as well as understanding those dependencies and managing them. I've seen companies for instance, depending on software that they actively don't want to use based on a certain criteria that they already set projects, like they'll set a requirement that any project that they use has a code of conduct, but they'll then use projects that don't have codes of conduct. And if they don't have a code of conduct, then employees are prohibited from working on those projects. So you've locked yourself into a place where you're depending on software that you have instructed, your employees are not allowed to contribute to, for certain legal and other reasons. So you need to draw a line in the sand and then recognize that those projects are ones that you don't want to consume, and then not use them, and have observability around these things. >> That's a great point. I think we have 10 minutes left. I want to just shift to a topic that I think is relevant. And that is as Open Source software, software, people develop software, you see under the hood kind of software, SREs developing very quickly in the CloudScale, but also you've got your classic software developers who were writing code. So you have supply chain, software supply chain challenges. You mentioned developer experience around how to code. You have now automation in place. So you've got the development of all these things that are happening. Like I just want to write software. Some people want to get and do infrastructure as code so DevSecOps is here. So how does that look like going forward? How has the future of Open Source going to make the developers just want to code quickly? And the folks who want to tweak the infrastructure a bit more efficient, any views on that? >> At Gaggle, we're using AWS' CDK, exclusively for our infrastructure as code. And it's a great transition for developers instead of writing Yammel or Jason, or even HCL for their infrastructure code, now they're writing code in the language that they're used to Python or JavaScript, and what that's providing is an easier transition for developers into that Infrastructure as code at Gaggle here, but it's also providing an opportunity to provide reusable constructs that some Devs can build on. So if we've got a very opinionated way to deploy a serverless app in a database and do auto-scaling behind and all stuff, we can present that to a developer as a library, and they can just consume it as it is. Maybe that's as deep as they want to go and they're happy with that. But then they want to go deeper into it, they can either use some of the lower level constructs or create PRs to the platform team to have those constructs changed to fit their needs. So it provides a nice on-ramp developers to use the tools and languages they're used to, and then also go deeper as they need. >> That's awesome. Does that mean they're not full stack developers anymore that they're half stack developers they're taking care of for them? >> I don't know either. >> We'll in. >> No, only kidding. Anyway, any other reactions to this whole? I just want to code, make it easy for me, and some people want to get down and dirty under the hood. >> So I think that for me, Docker was always a key part of this. I don't know when DevSecOps was coined exactly, but I was talking with people about it back in 2012. And when I joined Docker, it was a part of that vision for me, was that Docker was applying these security principles by default for your application. It wasn't, I mean, yes, everybody adopted because of the portability and the acceleration of development, but it was for me, the fact that it was limiting what you could do from a security angle by default, and then giving you these tuna balls that you can control it further. You asked about a project that may not get enough recognition is something called DockerSlim, which is designed to optimize your containers and will make them smaller, but it also constraints the security footprint, and we'll remove capabilities from the container. It will help you build security profiles for app armor and the Red Hat one. SELinux. >> SELinux. >> Yeah, and this is something that I think a lot of developers, it's kind of outside of the realm of things that they're really thinking about. So the more that we can automate those processes and make it easier out of the box for users or for... when I say users, I mean, developers, so that it's straightforward and automatic and also giving them the capability of refining it and tuning it as needed, or simply choosing platforms like serverless offerings, which have these security constraints built in out of the box and sometimes maybe less tuneable, but very strong by default. And I think that's a good place for us to be is where we just enforced these things and make you do things in a secure way. >> Yeah, I'm a huge fan of Kubernetes, but it's not the right hammer for every nail. And there are absolutely tons of applications that are better served by something like Lambda where a lot more of that security surface is taken care of for the developer. And I think we will see better tooling around security profiling and making it easier to shrink wrap your applications that there are plenty of products out there that can help you with this in a cloud native environment. But I think for the smaller developer let's say, or an earlier stage company, yeah, it needs to be so much more straightforward. Really does. >> Really an interesting time, 10 years ago, when I was working at Adobe, we used to requisition all these analysts to tell us how many developers there were for the market. And we thought there was about 20 million developers. If GitHub's to be believed, we think there is now around 80 million developers. So both these groups are probably wrong in their numbers, but the takeaway here for me is that we've got a lot of new developers and a lot of these new developers are really struck by a paradox of choice. And they're typically starting on the front end. And so there's a lot of movement in the stack moved towards the front end. We saw that at re:Invent when Amazon was really pushing Amplify 'cause they're seeing this too. It's interesting because this is where folks start. And so a lot of the obstructions are moving in that direction, but maybe not always necessarily totally appropriate. And so finding the right balance for folks is still a work in progress. Like Lambda is a great example. It lets me focus totally on just business logic. I don't have to think about infrastructure pretty much at all. And if I'm newer to the industry, that makes a lot of sense to me. As use cases expand, all of a sudden, reality intervenes, and it might not be appropriate for everything. And so figuring out what those edges are, is still the challenge, I think. >> All right, thank you very much for coming on the CUBE here panel. AWS Heroes, thanks everyone for coming. I really appreciate it, thank you. >> Thank you. >> Thank you. >> Okay. >> Thanks for having me. >> Okay, that's a wrap here back to the program and the awesome startups. Thanks for watching. (upbeat music)

>> Narrator: From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020 Virtual brought to you by Red Hat, the Cloud Native Computing Foundation and ecosystem partners. >> Hi I'm Stu Miniman and this is theCUBE's coverage of KubeCon, CloudNativeCon the 2020 European show of course happening virtually and that has put some unique challenges for the people running the show, really happy to welcome to the program she is one of the co-chairs of this event, and she is also a Principal Software Engineer at Splunk, Constance Caramanolis thank you so much for joining us. >> Hi, thank you for having me, I'm really excited to be here, it's definitely an interesting time. >> Alright, so Constance we know KubeCon it's a great community, robust everybody loves to get together there's some really interesting hallway conversations and so much going on, we've been watching, the four or five years we've been doing theCUBE at this show, just huge explosion of the breadth and depth of the content and of course, great people there. Just, if we could start with a little bit, your background, as I mentioned you're the co-chair, you work for Splunk by way of an acquisition, of Omnition try saying that three times fast, and Omnition you were telling me is a company that was bought really before it came out of stealth, but when it comes to the community itself, how long have you been involved in this community? What kind of led you to being co-chair? >> Yeah, I guess I've been involved with the community since 2017, so, I was at Lyft before Omnition Splunk, and I was lucky enough to be one of the first engineers, on Envoy you might've heard of Envoy, sorry I laugh at my own jokes. (laughing) Like my first exposure to KubeCon and seeing the CNCF community was KubeCon Austin and the thing that I was amazed by was actually you said it the hallway tracks, right? I would just see someone and be like, "Hey, like, I think I've seen your code review can I say hi?" And that started back on me at least a little bit involved in terms of talking to more people then they needed people I would work on a PR or in some of the community meetings and that was my first exposure to the community. And so I was involved in Envoy pretty actively involved in Envoy all the way until from 2016 until mid 2018 and then I switched projects and turning it left and did some other stuff and I came back into CNCF community, in OpenTelemetry as of last year, actually almost exactly a year ago now to work on making tracing, I'm going to say useful and the reason why I say useful is that usually people think of tracing as, not as important as metrics and logs, but there is so much to tracing that we tend to undervalue and that's why I got involved with OpenTelemetry and Omnition, because there's some really interesting ways that you could view tracing, use tracing, and you could answer a lot of questions that we have in our day-to-day and so that's kind of that's how I got involved in the second-round community and then ended up getting nominated to be on the co-chair and I obviously said yes, because this is an amazing opportunity to meet more people and have more of that hallway track. >> Alright, so definitely want to talk about OpenTracing, but let's talk about the event first, as we were talking about. >> Yeah. >> That community you always love the speakers, when they finish a session, they get mobbed by people doing questions. When you walk through the expo hall, you go see people so give us a little bit of insight as to how we're trying to replicate that experience, make sure that there's I don't know office hours for the speakers and just places and spaces for people to connect and meet people. >> Yeah, so I will say that like, part of the challenge with KubeCone EU was that it had already been meant to be an in person event and so we're changing it to virtual, isn't going to be as smooth as a KubeCon or we have the China event that's happening in a few weeks or at Boston, right that's still going on, like, those ones are being thought out a lot more as a proper virtual event. So a little bit of the awkwardness of, now everything is going to be online, right? It's like you can't actually shake someone's hand in a hallway but we are definitely trying to be cognizant of when I'm in terms of future load, like probably less content, right. It's harder to sit in front of a screen and listen to everything and so we know that we know we have enough bandwidth we're trying to find, different pieces of software that allow for better Q and A, right? Exactly, like the mobbing after session is go in as a speaker and one as attendee is sometimes like the best part about conferences is you get to like someone might've said something like, "Hey, like this little tidbit "I need to ask you more questions about this." So we're providing software to at least make that as smooth, and I'm putting this in quotation and as you'll be able to tell anyone who's watching as I speak with my hands. Right, so we're definitely trying to provide software to at least make that initial interaction as smooth as possible, maybe as easy as possible we know it's probably going to be a little bit bumpy just because I think it's also our first time, like everyone, every conference is facing this issue so it's going to be really interesting to see how the conference software evolves. It is things that we've talked about in terms of maybe offering their office hours, for that it's still something that like, I think it's going to be really just an open question for all of us, is that how do we maintain that community? And I think maybe we were talking or kind of when I was like planting the seed of a topic beforehand, it's like it's something I think that matters like, how do we actually define community? 'Cause so much of it has been defined off that hallway track or bumping into someone, right? And going into someone's booth and be like, like asking that question there, because it is a lot more less intimidating to ask something in person than is to ask it online when everyone gets to hear your question, right. I know I ask less questions online, I guess maybe one thing I want to say is that for now that am thinking about it is like, if you have a question please ask questions, right? If recording is done, if there's a recording for a talk, the speakers are usually made available online during the session or a bit afterwards, so please ask your questions when things come up, because that's going to be a really good way to, at least have a bit of that question there. And also don't be shy, please, even when I say like in terms of like, when it comes to review, code reviews, but if something's unintuitive or let's say, think about something else, like interact with it, say it or even ask that question on Twitter, if you're brave enough, I wouldn't but I also barely use Twitter, yeah I don't know it's a big open question I don't know what the community is going to look like and if it's going to be harder. >> Yeah, well, one of the things I know every, every time I go to the show conferences, when the keynote when it's always like, okay, "How many people is this your first time at the show?" And you look around and it's somewhere, third or half people attending for the first time. >> Yeah. I know I'm trying to remember if it was year and a half ago, or so there was created a kind of one-on-one track at the show to really help onboard and give people into the show because when the show started out, it was like okay, it was Kubernetes and a couple of other things now you've got the graduated, the incubated, the dozens of sandbox projects out there and then even more projects out there so, cloud-native is quite a broad topic, there is no wrong way where you can start and there's so many paths that you can go on. So any tips or things that we're doing this time, to kind of help broaden and welcome in those new participants? >> Yeah so there's two things, one is actually the one to attract is official for a KubeCon EU so we do have like, there's a few good talks in terms of like, how to approach KubeCon it was meant to originally be for a person but at least helping people in terms of general terms, right? 'Cause sometimes there's so much terminology that it feels like you need to carry, cloud-native dictionary around with you, doing that and giving suggestions there, so that's one of the first talks that's going to be able to watch on KubeCon so I highly suggest that, This is actually a really tough question because a lot of it would have been like, I guess it would have been for me, would have been in person be like, don't be afraid to like, if you see someone that, said something really interesting in a talk you attended, like, even if it's not after the question, just be like, "Hey, I thought what you said was really cool "and I just want to say I appreciate your work." Like expressing that appreciation and just even if it isn't like the most thoughtful question in the world just saying thank you or I appreciate you as a really good way to open things up because the people who are speaking are just as well most people are probably just as scared of going up there and sharing their knowledge as probably or of asking a question. So I think the main takeaway from that is don't be shy, like maybe do a nervous dance to get those jitters out and then after (laughing) and then ask that question or say like, thank you it's really nice to meet you. It's harder to have a virtual coffee, so hopefully they have their own teapot or coffee maker beside them, but offered you that, send an email I think, one thing that is very common and I have a hard time with this is that it's easy to get overwhelmed with how much content there is or you said it's just like, I first feel small and at least if everyone is focusing on Kubernetes, especially like a few years ago, at least and you're like, maybe that there are a lot of people who are really advanced but now that there's so many different people like so many people from all range of expertise in this subject matter experts, and interests that it's okay to be overwhelmed just be like, I need to take a step back because mentally attending like a few talks a day is like, I feel like it's taking like several exams 'cause there's so much information being bombarded on you and you're trying to process it so understand that you can't process it all in one day and that's okay, come back to it, right. It's a great thing is that all of these talks are recorded and so you can watch it another time, and I would say probably just choose like three or four talks that you're really excited about and listen to those, don't need to watch everything because as I said we can't process it all and that's okay and ask questions. >> Some great advice there because right, if we were there in person it was always, attend what you really want to see, are there speakers you want to engage with? Because you can go back and watch on demand that's been one of the great opportunities with the virtual events is you can have access on demand, you can poke and prod, personally I love that a lot of them you can adjust the speed of them so, if it's something that it's kind of an intro talk, I can crank it up to one and a half or 2X speed and get through more content or I can pause it, rewind if I'm not getting it. And the other opportunity is I tell you the last two or three years, when I'm at an event, I try to just spend my time, not looking at my phone, talking to people, but now there's the opportunity, hey, if I can be of help, if anybody in the community has a question or wants to get connected to somebody, we know a lot of people I'm easily reachable on Twitter and I'm not sitting on a plane or in the middle of something that being like, so there is just a great robust community out there, online, and it were great be a part of it. So speaking of projects, you mentioned OpenTelemetry, which is what, your day job works on it's been a really, interesting topic of course for those that don't know the history, there were actually two projects that merged, it was a OpenTracing and OpenCensus created OpenTelemetry, so why don't you bring us up to speed as to where we are with the project, and what people should be looking at at the show and throughout the rest of 2020? >> OpenTelemetry is very exciting, we just did our first beta release so for anyone who's been on the fence of, is OpenTelemetry getting traction, or is it something that you're like at, this is a really great time to want to get involved in OpenTelemetry and start looking into it, if it's as a viable project, but I guess should probably take a step back of what is OpenTelemetry, OpenTelemetry as you mentioned was the merging or the marriage of OpenTracing-OpenCensus, right? It was an acknowledgement that so many engineers were trying to solve the same problem, but as most of us knows, right, we are trying to solve the same problem, but we had two different implementations and we actually ended up having essentially a lot of waste of resources because we're all trying to solve the same problem, but then we're working on two different implementations. So that marriage was to address that because, right it's like if you look at all of the major players, all of the players on OpenTelemetry, right? They have a wide variety of vendor experience, right even as of speaking from the vendor hat, right vendors are really lucky that they get to work with so many customers and they get to see all these different use cases. Then there's also just so many actually end users who are using it and they have very peculiar use cases, too, even with a wide set of other people, they're not going to obviously have that, so OpenTelemetry gets to merge all of those different use cases into one, or I guess not into one, but like into a wide set of implementations, but at least it's maintained by a larger group instead of having two separate. And so the first goal was to unify tracing tracing is really far ahead in terms of implementation,, or several implementations of libraries, like Go, Java, Python, Ruby, like on other languages right now but quite a bit of lists there and there's even a collector too which some people might refer to as an agent, depending on what background they have. And so there's a lot of ways to one, implement tracing and also metrics for your services and also gather that data and manipulate it, right? 'Cause for example, tracings so tracing where it's like you can generate a lot of traces, but sometimes missing data and like the collector is a really great place to add data to that, so going back to the state of OpenTelemetry, OpenTelemetry since we just did a beta release, right, we're getting closer to GA. GA is something that we're tracking for at some point this year, no dates yet but it's something that we're really pushing towards, but we're starting to have a very stable API in terms of tracing a metric was on its way, log was all something we're wrapping up on. It is a really great opportunity to, all the different ways that we are that, we even say like service owners, applications, even business rate that we're trying to collect data and have visibility into our applications, this is a really great way to provide one common framework to generate all that data, to gather all that data and generate all that data. So it was really exciting and I don't know, we just want more users and why we say that is to the earlier point is that the more users that we have who are engaged with community, right if you want to open an issue, have a question if you want to set up a PR please do, like we really want more community engagement. It is a great time to do that because we are just starting to get traction, right? Like hopefully, hopefully in a year or two, like we are one of those really big, big projects right up on a CNCF KubeCon and it's like, let's see how much has grown. And it's a great time to join and help influence a project and so many chances for ownership, I know it's really exciting, the company-- >> Excellent well Constance, it's really exciting >> Yeah. >> Congratulations on the progress there, I'm sure everybody's looking forward to as you said GA later this year, want to give you the final word, yourself and Vicky Cheung as the co-chairs for the event, what's your real goal? What do you hope the takeaway is from this instance of the 2020 European show? Of course, virtual now instead of Amsterdam. I guess like two parts one for the takeaway is that it's probably going to be awkward, right? Especially again going back to the community is that we don't have a lot of that in person things so this will be an awkward interaction, but it's a really great place for us to want to assess what a community means to us and how we interact with the community. So I think it's going to be going into it with an open mindset of just knowing like, don't set the expectations, like any other KubeCon because we just know it won't be right, we can't even have like the after hours, like going out for coffee or drinks and other stuff there so having that there and being open to that being different and then also if you have ideas share it with us, 'cause we want to know how we can make it better, so expect that it's different, but it's still going to provide you with a lot of that content that you've been looking for and we still want to make that as much of a welcoming experience for you, so know that we're doing our best and we're open to feedback and we're here for you. >> Excellent, well Constance thank you so much for the work that you and the team have been doing on. absolutely, one of the events that we always look forward to, thanks so much for joining us. >> Thank you for having me. >> Alright, lots more coverage of theCUBE at KubeCon-Cloud Native on Europe 2020, I'm Stu Miniman and thanks for watching. (soft music)

>> Announcer: From New York, it's theCUBE, covering Escape/19. (upbeat music) >> Hello, welcome back to theCUBE coverage here in New York City for the inaugural multicloud event called Escape/19. This is a unique event where industry leaders are coming together to discuss and have conversations around what is multicloud? What does it even mean? How it will be laid out. It's really a foundational set of conversations and talks around it. Our next guest is Spoons, known as Spoons. That's not his real name (laughs), that's his nickname. He's a co-founder and CTO of LightStep, a CUBE alumni of the past. I've interviewed them at KubeCon. Spoons, thanks for coming on. >> Pleasure to be here. >> So first of all, your company really has a lot of tech jobs, we've interviewed your partner Ben before on theCUBE. So much is going on in microservices, you can't keep it straight these days. So, take a minute to give an update on what's going on with LightStep real quick, and why you're here. >> Yeah, I think what we're really trying to see is it's not just microservices, it's different cloud vendors, different third-party vendors that are really adding to the complexity. And that complexity really comes in the form of depth. I think people that are adopting microservices really feel it immediately. But for everyone else it's a bit of a boiling frog situation, it comes on slowly. And I think where LightStep fits in, is offering a simple solution for observing those systems, for understanding what's happening. >> So, multicloud, a conversation which I've called out on theCUBE as bullshit in the past because, we have people kind of spinning it up and hyping it up. I mean I recognize that people have multiple clouds, but there's no multiclouding going on. >> Yeah. >> Per se, but-- >> Yeah, we see a little bit with our customers. It's something where I think they think about it as a way to mitigate risks, it's a way for them to manage costs as well, so. Well, Multi-Vendor, I'm old enough to remember back in the '80s and '90s, where you didn't want just IBM, or you didn't want just DEC, you wanted multiple vendors in there because more inter genius is better. Better IT. So, now we're seeing that with cloud, this is not B.S., this is real. So, this is where I see multicloud being a foundational. How do you see the architecture of enterprises whether small, medium, growing, either born in the cloud, cloud negative, or hybrid IT, hybrid dev, building their own stacks. How should they be thinking about architecting for multicloud? >> Yeah so I think that's one of the choices they have to make. And a lot of what I think they're trying to do is really allow teams to work more independently. So, that might be that they can make their own choices about a cloud, about vendors. It might be that they make their own choices about languages, frameworks, things like that. As they do that they're building up this depth and what that means is that there's a heterogeneity to that system. And really the problem there is that you've got the responsibility for the whole stack. You've got responsibility for everything from your service all the way down, those will all impact your performance. You only got control over your service itself. And so, managing that tension is really where the pain comes in for a lot of developers. >> You know, I got to ask you a question. You're multiple degrees in computer science, entrepreneur, you're in the business, it's certainly a very rapid wave, it's really strong, and more waves are coming, bigger waves. Observability, network management becomes observability, configuration management becomes automation. RPA is the hottest trend, automating everything. So, a lot of action going on with cloud scale, enterprises are trying to vector in and figure that out. Observability has become such a hot area. And we kind of missed it, I mean, we covered it, but we, I missed that whole break out. Whoa, what is this? A whole new category. What's going on? >> I think a lot of people miss it. I think it's easy to think about the orchestration about the automation as the most important thing 'cause that's sort of in the critical path. You have to have that to keep going. And it's easy to kind of think that your monitoring tools from you know, 10, 20 years ago are still working. And I think, what we realized while we were at Google and what we brought to LightStep is that they're not working anymore, that you've really got to re-think, and you've got to put in context that allows you to see that whole stack and not just think about individual machines, individual processes, but really understand it from the user's point of view, from your customer's point of view. >> And I mean you start out you see tracing as a feature, but observability is now almost its own practice. How should we think about holistically? How should people think holistically about observability from a technical standpoint? >> Yeah so really of course you're going to need some logging, you're going to need metrics, but you really need those things to be put in context. You need to understand how they're affecting individual users, individual or segmented users, and so tracing is really the backbone of that context. It allows you to understand how a particular transaction passes through that system. If you don't have that, you're just going to get buried in this sea of data whether that's logs or metrics or whatever. Tracing is really the thing that allows you to understand what's important to filter, to aggregate, and to really hone in on what can-- >> So that rabbit hole, or that net, or the drowning in that you said, I forget how you said it, it was nice, is essentially a rabbit hole, you can almost get stuck down there. >> Absolutely, absolutely. >> So you're getting much more real-time, and you also said, you know, the contextual. So when I think of contextual I'm thinking about I have to be integrated to the app and/or have access to data. >> Yeah. So how does that work? >> Yeah so, really data comes from a lot of different sources and you need to get a way to integrate those things that can come from machine layer, from the infrastructure layer, but from the application itself as well. We've partnered with some others to put together OpenTelemetry, which is an open standard for getting the data out of the application. This comes on the heels of open tracing and a couple of other things, but that's really an open standard that allows application developers, allows framework developers to really open that spigot and get the data out of the application. >> Just to get your personal thoughts on the industry. I have a lot of conversations with folks around, we're the control plane for data. I mean, can there ever be a control plane? Is Kubernetes going to be that? I guess abstraction, where everyone kind of has their own little land grab of control plane? 'Cause data horizontal scalability makes sense. >> Yeah there's a lot of different kinds of data and not all data is equally valuable. So the way that you think about data that's driving your revenue, that's one thing, and the way that you're thinking about debugging your application, that's another thing. I think you probably need more than one tool to handle that. It's just not going to be cost-effective for you. >> It's all in the level of context right there. >> Daniel: Exactly, exactly, yeah, yeah. >> So thinking about contextual and having integration points is probably a good starting point for someone who's kind of thinking about re-assembling for multicloud. >> Yep, yep. >> All right so what do you think about this conference, multicloud first inaugural, kind of true multicloud conference, about multicloud only? >> Yeah a lot of great people here, it's exciting. >> Thanks for coming, I appreciate you Spoon. Any updates, give a plug for LightStep. Take a quick second to explain what you guys are looking for, what you do, and give an update. >> Yeah so LightStep, simple observability for Deep Systems. Deep Systems come about through things like microservices, but we have a lot of customers that are still working on a monolith or just stepping away from monolithic architecture and really observability means not just logs, not just metrics, but really providing that context through things like tracing, that allow you to release faster, get those features out there, and at the same time reduce mean time resolution, reduce mean-time-to-innocence, right? Really making sure that your teams are able to understand who's at fault and who can fix the problems that you're seeing in production. >> And you guys recruiting, looking for people? >> Always recruiting on the engineering side, design, product, go to market, all of those things. >> Everyone's hiring, it's hard to get people these days. >> It is, it is. >> Lot of open jobs out there. >> Thanks for coming on and sharing your insights. See you around the neighborhood in Silicon Valley. We'll see you at KubeCon. >> Great, thanks, thanks for having me. >> It's CUBE coverage here. I'm John Furrier, we're in New York City for the first inaugural conference, Escape/19. This is the first industry gathering where the leaders of people who are making things happen are having conversations and talks around what is multicloud and laying down that foundation and add room for more solutions. I'm John Furrier, thanks for watching. (upbeat music)

>> 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)

>> Live from Barcelona, Spain, it's theCUBE! Covering KubeCon and CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation, and ecosystem partners. >> Welcome back. This is theCUBE's live coverage of KubeCon, CloudNativeCon 2019 here in Barcelona, Spain. 7,700 here in attendance, here about all the Cloud Native technologies. I'm Stu Miniman; my cohost to the two days of coverage is Corey Quinn. And to help us break down what's happening in this ecosystem, we've brought in Jason Bloomberg, who's the president at Intellyx. Jason, thanks so much for joining us. >> It's great to be here. >> All right. There's probably some things in the keynote I want to talk about, but I also want to get your general impression of the show and beyond the show, just the ecosystem here. Brian Liles came out this morning. He did not sing or rap for us this morning like he did yesterday. He did remind us that the dinners in Barcelona meant that people were a little late coming in here because, even once you've got through all of your rounds of tapas and everything like that, getting that final check might take a little while. They did eventually filter in, though. Always a fun city here in Barcelona. I found some interesting pieces. Always love some customer studies. Conde Nast talking about what they've done with their digital imprint. CERN, who we're going to have on this program. As a science lover, you want to geek out as to how they're finding the Higgs boson and how things like Kubernetes are helping them there. And digging into things like storage, which I worked at a storage company for 10 years. So, understanding that storage is hard. Well, yeah. When containers came out, I was like, "Oh, god, we just fixed it for virtualization, "and it took us a decade. "How are we going to do it this time?" And they actually quoted a crowd chat that we had in our community. Tim Hawken, of course one of the first Kubernetes guys, was in on that. And we're going to have Tim on this afternoon, too. So, just to set a little context there. Jason, what's your impressions of the show? Anything that has changed in your mind from when you came in here to today? Let's get into it from there. >> Well, this is my second KubeCon. The first one I went to was in Seattle in December. What's interesting from a big picture is really how quickly and broadly KubeCon has been adopted in the enterprise. It's still, in the broader scheme of things, relatively new, but it's really taking its place as the only container orchestrator anybody cares about. It sort of squashed the 20-or-so alternative container orchestrators that had a brief day in the sun. And furthermore, large enterprises are rapidly adopting it. It's remarkable how many of them have adopted it and how broadly, how large the deployment. The Conde Nast example was one. But there are quite a number. So we turned the corner, even though it's relatively immature technology. That's the interesting story as well, that there's still pieces missing. It's sort of like flying an airplane while you're still assembling it, which makes it that much more exciting. >> Yeah, one of the things that has excited me over the last 10 years in tech is how fast it takes me to go from ideation to production, has been shrinking. Big data was: "Let's take the thing that used to take five years "and get it down to 18 months." We all remember ERP deployments and how much money and people you need to throw at that. >> It still takes a lot of money and people. >> Right, because it's ERP. I was talking to one of the booths here, and they were doing an informal poll of, "How many of you are going to have Kubernetes "in production in the next six months?" Not testing it, but in production in the next six months, and it was more than half of the people were going to be ramping it up in that kind of environment. Anything architecturally? What's intriguing you? What's the area that you're digging down to? We know that we are not fully mature, and even though we're in production and huge growth, there's still plenty of work to do. >> An interesting thing about the audience here is it's primarily infrastructure engineers. And the show is aimed at the infrastructure engineers, so it's technical. It's focused on people who code for a living at the infrastructure level, not at the application level. So you have that overall context, and what you end up having, then, is a lot of discussions about the various components. "Here's how we do storage." "Here's how we do this, here's how we do that." And it's all these pieces that people now have to assemble, as opposed to thinking of it overall, from the broader context, which is where I like writing about, in terms of the bigger picture. So the bigger picture is really that Cloud Native, broadly speaking, is a new architectural paradigm. It's more than just an architectural trend. It's set of trends that really change the way we think about architecture. >> One interesting piece about Kubernetes, as well. One of the things we're seeing as we see Kubernetes start to expand out is, unlike serverless, it doesn't necessarily require the same level of, oh, just take everything you've done and spend 18 months rewriting it from scratch, and then it works in this new paradigm in a better way. It's much less of a painful conversion process. We saw in the keynote today that they took WebLogic, of all things, and dropped that into Kubernetes. If you can do it with something as challenging, in some respects, and as monolithic as WebLogic, then almost any other stack you're going to see winds up making some sense. >> Right, you mentioned serverless in contrast with Kubernetes, but actually, serverless is part of this Cloud Native paradigm as well. So it's broader than Kubernetes, although Kubernetes has established itself as the container orchestration platform of choice. But it's really an overall story about how we can leverage the best practices we've learned from cloud computing across the entire enterprise IT landscape, both in the cloud and on premises. And Kubernetes is driving this in large part, but it's bigger picture than the technology itself. That's what's so interesting, because it's so transformative, but people here are thinking about trees, not the forest. >> It's an interesting thing you say there, and I'm curious if you can help our community, Because they look at this, and they're like, "Kubernetes, Kubernetes, Kubernetes." Well, a bunch of the things sit on Kubernetes. As they've tried to say, it's a platform of platforms. It's not the piece. Many of the things can be with Kubernetes but don't have to be. So, the whole observability piece. We heard the merging of the OpenCensus, OpenTracing with OpenTelemetry. You don't have to have Kubernetes for that to be a piece of it. It can be serverless underneath it. It can be all these other pieces. Cloud Native architecture sits on top of it. So when you say Cloud Native architecture, what defines that? What are the pieces? How do I have to do it? Is it just, I have to have meditated properly and had a certain sense of being? What do we have to do to be Cloud Native? >> Well, an interesting way of looking at it is: What we have subtracted from the equation, so what is intentionally missing. Cloud Native is stateless, it is codeless, and it is trustless. Now, not to say that we don't have ways of dealing with state, and of course there's still plenty of code, and we still need trust. But those are architectural principals that really percolate through everything we do. So containers are inherently stateless; they're ephemeral. Kubernetes deals with ephemeral resources that come and go as needed. This is key part of how we achieve the scale we're looking for. So now we have to deal with state in a stateless environment, and we need to do that in a codeless way. By codeless, I mean declarative. Instead of saying, how are we going to do something? Let's write code for that, we're going to say, how are we going to do that? Let's write a configuration file, a YAML file, or some other declarative representation of what we want to do. And Kubernetes is driven this way. It's driven by configuration, which means that you don't need to fork it. You don't need to go in and monkey with the insides to do something with it. It's essentially configurable and extensible, as opposed to customizable. This is a new way of thinking about how to leverage open-source infrastructure software. In the past, it was open-source. Let's go in an monkey with the code, because that's one of the benefits of open-source. Nobody wants to do that now, because it's declaratively-driven, and it's configurable. >> Okay, I hear what you're saying, and I like what you're saying. But one of the things that people say here is everyone's a little bit different, and it is not one solution. There's lots of different paths, and that's what's causing a little bit of confusion as to which service mesh, or do I have a couple of pieces that overlap. And every deployment that I see of this is slightly different, so how do I have my cake and eat it, too? >> Well, you mentioned that Kubernetes is a platform of platforms, and there's little discussion of what we're actually doing with the Kubernetes here at the show. Occasionally, there's some talk about AI, and there's some talk about a few other things, but it's really up to the users of Kubernetes, who are now the development teams in the enterprises, to figure out what they want to do with it and, as such, figure out what capabilities they require. Depending upon what applications you're running and the business use cases, you may need certain things more than others. Because AI is very different from websites, it's very different from other things you might be running. So that's part of the benefit of a platform of platforms, is it's inherently configurable. You can pick and choose the capabilities you want without having to go into Kubernetes and fork it. We don't want 12 different Kubernetes that are incompatible with each other, but we're perfectly okay with different flavors that are all based on the same, fundamental, identical code base. >> We take a look at this entire conference, and it really comes across as, yes, it's KubeCon and CloudNativeCon. We look at the, I think, 36 projects that are now being managed by this. But if we look at the conversations of what's happening here, it's very clear that the focus of this show is Kubernetes and friends, where it tends to be taking the limelight of a lot of this. One of the challenges you start seeing as soon as you start moving up the stack, out through the rest of the stack, rather, and seeing what all of these Cloud Native technologies are is, increasingly, they're starting to be defined by what they aren't. I mean, you have the old saw of, serverless runs on servers, and other incredibly unhelpful sentiments. And we talk about what things aren't more so than we do what they are. And what about capabilities story? I don't have an answer for this. I think it's one of those areas where language is hard, and defining what these things are is incredibly difficult. But I see what you're saying. We absolutely are seeing a transformative moment. And one of the strangest things about it, to me at least, is the enthusiasm with which we're seeing large enterprises, that you don't generally think of as being particularly agile or fast-moving, are demonstrating otherwise. They're diving into this in fascinating ways. It's really been enlightening to have conversations for the last couple of days with companies that are embracing this new paradigm. >> Right. Well, in our perspective at Intellyx, we're focusing on digital transformation in the enterprise, which really means putting the customer first and having a customer-driven transformation of IT, as well as the organization itself. And it's hard to think in those terms, in customer-facing terms, when you're only talking about IT infrastructure. Be that as it may, it's still all customer-driven. And this is sometimes the missing piece, is how do we connect what we're doing on the infrastructure side with what customers require from these companies that are implementing it? Often, that missing piece centers on the workload. Because, from the infrastructure perspective, we have a notion of a workload, and we want workload portability. And portability is one of the key benefits of Kubernetes. It gives us a lot of flexibility in terms of scalability and deployment options, as well as resilience and other benefits. But the workload also represents the applications we're putting in front of our end users, whether they're employees or end customers. So that's they key piece that is like the keystone that ties the digital story, that is the customer-facing, technology-driven, technology-empowered story, with the IT infrastructure stories. How do we support the flexibility, scalability, resilience of the workloads that the business needs to meet its business goals? >> Yeah, I'm really glad you brought up that digital transformation piece, because I have two questions, and I want to make sure I'm allowing you to cover both of them. One is, the outcome we from people as well: "I need to be faster, and I need to be agile." But at the same point, which pieces should I, as an enterprise, really need to manage? Many of these pieces, shouldn't I just be able to consume it as a managed service? Because I don't need to worry about all of those pieces. The Google presentation this morning about storage was: You have two options. Path one is: we'll take care of all of that for you. Path two is: here's the level of turtles that you're going to go all the way down, and we all know how complicated storage is, and it's got to work. If I lose my state, if I lose my pieces there, I'm probably out of business or at least in really big trouble. The second piece on that, you talked about the application. And digital transformation. Speed's great and everything, but we've said at Wikibon that the thing that will differentiate the traditional companies and the digitally transformed is data will drive your business. You will have data, it will add value of business, and I don't feel that story has come out yet. Do you see that as the end result from this? And apologies for having two big, complex questions here for you. >> Well, data are core to the digital transformation story, and it's also an essential part of the Kubernetes story. Although, from the infrastructure perspective, we're really thinking more about compute than about data. But of course, everything boils down to the data. That is definitely always a key part of the story. And you're talking about the different options. You could run it yourself or run it as a managed service. This is a key part of the story as well, is that it's not about making a single choice. It's about having options, and this is part of the modern cloud storage. It's not just about, "Okay, we'll put everything in one public cloud." It's about having multiple public clouds, private clouds, on-premises virtualization, as well as legacy environments. This is what you call hybrid IT. Having an abstracted collection of environments that supports workload portability in order to meet the business needs for the infrastructure. And that workload portability, in the context of multiple clouds, that is becoming increasingly dependent on Kubernetes as an essential element of the infrastructure. So Kubernetes is not the be-all and end-all, but it's become an essentially necessary part of the infrastructure, to make this whole vision of hybrid IT and digital transformation work. >> For now. I mean, I maintain that, five years from now, no one is going to care about Kubernetes. And there's two ways that goes. Either it dries up, blows away, and something else replaces it, which I don't find likely, or, more likely, it slips beneath the surface of awareness for most people. >> I would agree, yeah. >> The same way that we're not sitting here, having an in-depth conversation about which distribution of Linux, or what Linux kernel or virtual memory manager we're working with. That stuff has all slipped under the surface, to the point where there are people who care tremendously about this, but you don't need to employ them at every company. And most companies don't even have to think about it. I think Kubernetes is heading that direction. >> Yeah, it looks like it. Obviously, things continue to evolve. Yeah, Linux is a good example. TCP/IP as well. I remember the network protocol wars of the early 90s, before the web came along, and it was, "Are we going to use Banyan VINES, "are we going to use NetWare?" Remember NetWare? "Or are we going to use TCP/IP or Token Ring?" Yeah! >> Thank you. >> We could use GDP, but I don't get it. >> Come on, KOBOL's coming back, we're going to bring back Token Ring, too. >> KOBOL never went away. Token Ring, though, it's long gone. >> I am disappointed in Corey, here, for not asking the question about portability. The concern we have, as you say: okay, I put Kubernetes in here because I want portability. Do I end up with least-common-denominator cloud? I'm making a decision that I'm not going to go deep on some of the pieces, because nice as the IPI lets things through, but we understand if I need to work across multiple environments, I'm usually making a trade-off there. What do you hear from customers? Are they aware that they're doing this? Is this a challenge for people, not getting the full benefit out of whichever primary or whichever clouds they are using? >> Well, portability is not just one thing. It's actually a set of capabilities, depending upon what you are trying to accomplish. So for instance, you may want to simply support backing up your workload, so you want to be able to move it from here to there, to back it up. Or you may want to leverage different public clouds, because different public clouds have different strengths. There may be some portability there. Or you may be doing cloud migration, where you're trying to move from on-premises to cloud, so it's kind of a one-time portability. So there could be a number of reasons why portability is important, and that could impact what it means to you, to move something from here to there. And why, how often you're going to do it, how important it is, whether it's a one-to-many kind of thing, or it's a one-to-one kind of thing. It really depends on what you're trying to accomplish. >> Jason, last thing real quick. What research do you see coming out of this? What follow-up? What should people be looking for from Intellyx in this space in the near future? >> Well, we continue to focus on hybrid IT, which include Kubernetes, as well as some of the interesting trends. One of the interesting stories is how Kubernetes is increasingly being deployed on the edge. And there's a very interesting story there with edge computing, because the telcos are, in large part, driving that, because of their 5G roll-outs. So we have this interesting confluence of disruptive trends. We have 5G, we have edge computing, we have Kubernetes, and it's also a key use case for OpenStack, as well. So it's like all of these interesting trends are converging to meet a new class of challenges. And AI is part of that story as well, because we want to run AI at the edge, as well. That's the sort of thing we do at Intellyx, is try to take multiple disruptive trends and show the big picture overall. And for my articles for SiliconANGLE, that's what I'm doing as well, so stay tuned for those. >> All right. Jason Bloomberg, thank you for helping us break down what we're doing in this environment. And as you said, actually, some people said OpenStack is dead. Look, it's alive and well in the Telco space and actually merging into a lot of these environments. Nothing ever dies in IT, and theCUBE always keeps rolling throughout all the shows. For Corey Quinn, I'm Stu Miniman. We have a full-packed day of interviews here, so be sure to stay with us. And thank you for watching theCUBE. (upbeat techno 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)