 Live from San Francisco, California. Extracting the signal from the noise. It's theCUBE, covering DockerCon 2015. Brought to you by SiliconANGLE Media. With special thanks to Docker. Now your hosts, Stu Miniman and Jeff Frick. Hi, Jeff Frick here with theCUBE. We are live in San Francisco at DockerCon 2015. A lot of buzz going on, about 2,000 people. I think four times the number of people they had at DockerCon 2014. Joining me in this next segment, up on my coast, Stu Miniman from Wikibon, and we're excited to welcome into theCUBE Matthew Leventi, software engineer from Lyft. Welcome, Matt. Hey, how's it going? So if there's ever a poster child for alternative business models, you guys have completely disrupted the world and shown that technology and digital disruption isn't just about software. It's about physical goods, physical services and congratulations for all your success. Thank you, thank you. I like working at a company where the tech we do actually influences where people go and how they get there. Yeah, absolutely, so what are you doing here at DockerCon? Well, Lyft, we're an early adopter of Docker and it enables us to crank out features faster and to get product, to get off of engineering's back and deliver actual customer-facing goods. And how long have you guys been using it, kind of, where are you in your kind of adoption because, you know, still relatively new? Well, we started in 2014 and we've been steadily increasing our adoption rate and where we're using it in our system since then, and so far it's been a good ride. Got a lot of good ride benefits out of it, yeah? Yeah, so Matthew, maybe if we step back for a second outside Docker, tell us a little bit about your role inside Lyft, you know, and a little bit about your background in IT. At Lyft, I work on systems engineering, which basically means I help devs be more productive. I do less customer-facing feature work. Before that, I was working at Zenga much of the same thing, building Zenga API, which is again, helping other devs be productive. And a lifetime ago, I used to work at Microsoft as well. Yeah, so, you know, we throw around terms in the industry sometimes, you know, distributed architectures, microservices, you know, building that scale. I mean, you've worked for some companies that are pretty big and grown rather fast. So, you know, how does Docker fit into that equation, you know? I think Docker is great at reducing the barrier entry to building microservice architectures and distributed systems. Basically, most people these days, I know that Facebook is still sort of on the monolithic model, but most people that are starting up, they're doing SOA, once their business requires it, once your dev team reaches a certain size, you really want to keep your devs productive and it's hard to do that in a sort of monolithic app environment. So, what I did at Zenga and what I'm doing now at Lyft is basically trying to get out of the way of devs doing feature work and developing microservices that enable them to ship faster and test things faster. Okay, so why does Docker help your devs, you know, work faster? Well, like, anyone knows it's really hard to run stuff and it's even harder to run stuff that talks to other stuff that needs to be running in parallel. So if you have service A and you're developing on service A and that needs to talk to service B and C and D and E, it's really hard to do that in an isolated way where you can test a change on one service or on two services and have them communicate together and make sure that it works before you push out to prod. Docker, the shipping container metaphor especially, allows you to basically run services in isolated environments and have that service communication be testable before you get to a staging or a prod environment. All right, so Matthew, you know, sometimes we talk about DevOps, so would you guys consider yourself a DevOps house or? I would say Lyft considers every engineer a DevOps engineer in a way. I mean, we very much are on the model of you build it, you run it. There is a DevOps team that really is more of a consulting resource or if you want to do something that we don't support or that's out of the box, you're free to do that, but there's a sort of consultation process with a DevOps team, which is a bit more of a systems engineering group in a way, but it's very much that when you code Python or you code in Go, if you deploy it to production and it doesn't work, you're going to get paged. How do you measure that productivity gain you talked about helping your devs work faster? Do you have metrics that you bring back and does it cause other strains on the systems? I mean, if it's just go faster and go faster, where does the bottleneck move in your system of development? So there's two types of bottleneck and as far as metric goes, the easiest way of measuring it is seeing how quickly a new hire becomes productive. Like we used to go from a world of having a handhold a new hire into our systems where they might commit by the end of their first week to now it's you're in onboarding on Monday morning, you're out of onboarding at 11 a.m., you're expected to commit by like 1 p.m. and you're expected to ship to prod in your first day, your first commit by four or five in the afternoon. Wait, wait, wait, wait, go back to that one more time. That's a pretty phenomenal onboarding rate. So I start in the morning, go through it again. You start in the morning, you get your MacBook Pro at the meeting and we go over the culture and some expectations around how engineering operates and around noon around after lunch, your laptop comes with a Dev environment fully baked and you can use your phone to talk to your laptop to try out new features. So you usually start them off with a couple of Giro tickets and you're expected to just get going on the code base and the Dev environment is set up to not be in your way to do that and if you have problems, you have people that are willing to help you basically get you productive as quickly as possible. There are a lot of people committing and prod on their first day. Compare that to what it was three years ago. Three years ago, we weren't, Lyft didn't exist, but I can compare that. But I mean, you've been in the business of making engineers and developers more efficient for a long, long time. Talk about the impact of being able to do that. That's a phenomenal onboarding speed. I think a lot of times you hear from a developer who'll say, I'm blocked or I'm blocked on this task or I don't know how to do X. Docker enables us to basically standardize a lot of things. So once you learn how one service is developed, you can develop on any of our services. In the past, if Dev switches from team to team, like at Zenga, there were totally different tech stacks depending upon which game team you worked on and that non-homogeneity creates issues where it's hard to move Devs between teams. So Docker makes everything basically the same on the outside. Just you just have to deal with app code differences, which is really where the business logic is and where the business value is. So Matthew, we were talking about the bottlenecks in the system. If everybody's moving so much faster, where are the restraints? So it's restrained a little bit around process. You get a lot of production deploys every day. You want to keep that stable. You want to keep the app secure and the app stable. There's a little bit of a strain there. There's a strain around testing. So we need to test changes in isolation across multiple systems. There's a strain on the tooling there. No one is really doing integration tests across services as a product yet. So we've built basically a CI system that allows us to test commits to different Git repos, to different services in isolation. So you want to test how it changed on service A is going to affect service B. We have test suites that allow you to do that. And that kind of tooling basically enables you to have an assurance before you push the prod that you're not going to break stuff. It's amazing. I mean, we just had Adrian Cockroff is on and talking about older companies, you know, are used to such a much slower pace and the fact that you guys are just, you know, pedal to the metal and continue to get these updates out. You've got productive engineers within a day. I mean, that is really setting a high bar. Well, we have like a- From a software development side. We have a rapidly evolving marketplace. We have a tremendous amount of competition. Engineering really has to be a vehicle for business delivery. And Docker aids us in that, but primarily we use Docker to enable us to be more competitive by shipping product features. At the end of the day, you shouldn't make a decision one way to go with Docker or not to go with Docker. It should affect, it should aid your business in speeding up your development. So, you know, one of the promises of Docker is that I shouldn't have to think too much about, you know, where my infrastructure lives. So, you know, we had up on stage this morning, you had AWS there, you know, Microsoft Azure, IBM Bluemix, there's lots of public clouds that can use it. And we've also got the on-premises environments. I guess, how does, you know, lift look at this and, you know, how do you think about kind of the on-prem versus off-prem discussion? I think like for a company our size, it makes sense to be on a cloud. I think for most companies, it makes sense to be on a cloud. You really have to do a cost-benefit analysis as to whether or not you should go run your own stuff. Whether the expense of that is worthwhile or the expense of hiring people to do that is worthwhile. Our primary business is we want to create rides, we want to create loyal customers and loyal drivers. We want to create a good experience in the car. All of the infrastructure back end is really in aid of that. So, to us, it's how do we solve problems? And if AWS solves distributed systems problems for us, we'll take it. That's great. We're willing to pay for it. So what's next? What are you looking forward to if we run into you here at DockerCon 2016? What are we going to be talking about that changed in a year? I think I'm looking forward to Docker Network. I'm looking forward to better AWS support. I think my number one ask would be for Amazon and Docker to work closer together. To create a better partnership so that Docker is really a first class system in AWS. I think there is obviously a number of cloud providers, Microsoft, Google, Amazon. For where I work right now, it's very important that the relationship between Docker and Amazon stays great. 2016, I would like to see AWS instances inside containers on Docker, the first class citizen with support for all of Amazon products. Yeah, so Matthew, I'm wondering if you could just tease that out and unpack it a little bit for us because Amazon talks about first class citizen, it works in Elastic Beanstalk, they've got the new EC2 service. Is there some services there aren't supported or is there something that, what's lacking, I guess? Well, ECS is still very new. There's a bunch of things that are still sort of in, I think, not there yet. The privileging model for Amazon for IAM roles isn't there. I've heard that it, hopefully it will be soon. There's a number of other ingredients around load balancers and auto-scaling groups that are harder to do in ECS than they are in EC2. And really, we've been built out in prod and AWS in EC2 without containers. And we need Amazon to sort of get going on delivering the long tail of features into ECS before we're gonna fully change over using Docker as something that would be considered in the cloud in AWS. All right, well thanks for something by Matthew. Good insight and it's great, somebody who's been in the business of making developers more efficient for a long, long time and it sounds like you guys are off to the racist. Thank you. Very well. So I'm Jeff Frick here with Stu Miniman. We're at DockerCon 2015 in San Francisco. We'll be back with our next guest after this short break. Thanks for watching.