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