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