 Live from Austin, Texas, it's theCUBE. Covering DockerCon 2017, brought to you by Docker and support from its ecosystem partners. Welcome back to theCUBE. I'm Stu Miniman with my co-host, Jim Kubilis. Happy to have on the program. I'm shocked to say, a first-time guest, someone that I've known in the community here for many years, but Michael Ducey, who is director of product marketing at Chef Software. Not a chef. Not a chef, although I do cook and cook at the same time. Not a puppeteer, but you work for Chef Software. So thank you so much for joining us. Yes, thanks for having me. All right, so Michael, for the audience that doesn't know you, I think a lot of people here in the community would know you. I've known you through Twitter for many years. What's your role at Chef? What do you work on? What's your passion? Sure. So right now I do product marketing for our open-source projects. So Chef Software actually has a commercial product, and then we also have three open-source projects that we maintain. The first was the original one that we're named after, which is Chef, which is open-source automation or configuration management. The second one being InSpec, which is all about how do you basically write compliance rules as code. And then third one, as you can see from my shirt, is called Habitat. So Habitat is a new way of thinking about how do you package up automation for your application, and then how can you easily export that application and the automation into something like a container. I've had various roles at Chef, though, over the four years that I've worked with them. My passion's always kind of been open-source communities, and involvement in open-source communities, and helping grow those communities. Yeah, and people send you lots of stuff about goats. People send me lots of stuff about goats. There was a joke that was made at a conference about waking up next to a goat. This was a conference in Amsterdam, which is, you know, I'm sure I wouldn't be the first one that woke up next to a goat in Amsterdam. But since then, the whole goat thing kind of took off after that. Yeah, so Chef, you understand many things about Docker. So one of the things we come in and we talk about, there's Docker, the company, there's Docker, the community. A lot of what was talked about in the keynote today was about open-source. So how's Docker doing? What interested you in the keynote? How do you, as an individual and Chef, see what's going on in the Docker ecosystem? What do you think? Yeah, so we've been put in a little bit of an interesting position as Chef, the company. Not only has Chef, the company, been put in this position, but all of our competitors have as well. So there's been a movement as Docker and containers got more popular, that the idea that configuration management is no longer needed. And from an inside the container perspective, configuration management really isn't needed. But what you do end up realizing is that there's this whole idea of what you need to actually run a container in production effectively that still needs to go into that container. And we kind of call it the learning cliff of containers. And I tweeted out an image about that my coworker drew on a whiteboard. That shows in development you just have Docker and it's really easy, but then when you move it to production, there's this whole other stack of concerns. And Docker or your container runtime is just one of them. And so we've been focusing more on kind of shifting into those ideas of how do you actually run containers effectively in production. What we saw in the keynote today is more of an emphasis on things like security, right? That's definitely been an area that we were interested in, especially from a compliance perspective and doing work around having our open source projects being able to scan containers for compliance. Yeah, it's funny. Before the keynote, they had this fun little thing. They had like this 8-bit video game playing. And it was like, they were collecting coins and they were leveling up, but they kept hitting lots of bombs and things were exploding all the time and everybody was joking online. It was like, oh, it's like putting Docker in production. I will level up and I will get past everything, but boy, I'm going to have lots of bombs going off and things that I'll have to deal with. And there were lots of fun little comments that they threw up there. It's like checking documentation. Oh, documentation says you don't have documentation. So just fun stuff like that. But it's challenging. I mean, Solomon says we want this put in deployment, but as we know, it's not quite there yet. There's lots of things that's where you guys fit in. A lot of the ecosystem helps to solidify that a bunch. Michael, what are those concerns that you allude to? There's security. And what other concerns are there for containers in production that need to be represented in the configuration management portfolio or profile you're describing? Sure. So the security aspects of it is focused on what vulnerabilities are in your container. And there's been some interesting studies recently that showed 24% of the official images are shipping with some sort of a vulnerability. Some of that you have to accept and then also realize, can you do risk mitigation around that vulnerability? There's concerns about how the application is actually configured when you ship it as well. So am I doing things like storing secrets and config files? Am I disabling versions of SSL that's no longer a best practice anymore because it's actually broken? And then there's other aspects around how do you do things like service discovery? How do you do credentials or secrets? And how do you get them into the container securely? There's networking aspects. There's last mile configuration of the application. So if you take a container from one environment to another environment and kind of work it through a life cycle, there are things at runtime that you have to change in its configuration to make it run in that particular environment. So it's all of those little knobs that you still have to turn. And that's why- The entire DevOps life cycle essentially, there's all those little knobs. There's all these little knobs that's always been a little bit of a frustration for me in that past sounds great, platform as a service sounds great and this idea that you can just take this blob and go run it. But what people don't realize is there still are tons of knobs that you have to turn and there are tons of concerns that you have to worry about as an operations person or as a DevOps person or as a developer when you actually are taking that code into production. Michael, we've seen the cloud providers and some of the other open source providers kind of chipping away. I mean, Red Hat bought Ansible. Every time I go to Amazon re-invent or Google, it seems like they're trying to build more things up the stack and into their platform. So what is chef's position here? How do you guys play across all these environments and kind of maintain and grow what you're doing? Yeah, so we've started to take a little bit more of a different focus. And well, not a different focus, different focus for us. Traditionally we focus on infrastructure and operations people. And then as we moved up the stack and DevOps became more popular, we definitely focused on that because that's kind of our bread and butter. But what we started to do with Habitat is focus more on building a developer experience. So how can a developer take their code, easily wrap automation around it and then ship it out into production? And this is the new world for us as coming from the operations side of things and really starting to think about what does the developer tooling look like and the developer experience look like for taking source code, building that source code and then deploying that source code to production. It's interesting. It sounds, you know, to talk about Docker, they very much started out in the developer world and then they're kind of moving to kind of the ops side more and to the enterprise side more. You're almost going a little bit in reverse. Yeah, going a little bit in reverse. Yeah, it's interesting because usually it's like, okay, I start with developers, get them excited and then figure out to monetize. So yeah, what do you see in your customer base is that, you know, who do you sell to in that aspect? You know, yeah, just curious some of the buyers. Well, so traditionally a tool like Chef or even some of our competitors would be bought by what's called the shared services team, right? And that shared services team is going to take that and try and work economies of scale, right? And try and deploy that across all of the different VMs or machines that they have to manage, right? We've seen this shift as we moved more up the stack and as the industry's shifted more up the stack of what the shared services team actually needs to transform themselves into is more of a developer services team. So how can I offer the services that a developer can get via an API to quickly deploy the application services that they need? And when I say application services, I'm thinking about all of the things that you need to actually go and persist the data. The business logic side of things are very easy to do and containers are passed but when you're actually having to go and persist data in something like Redis or Mongo or MySQL, that's a whole other area of concern that you have to worry about. So what we've actually have started to do is the core team that actually works on Habitat has a very, very big background in distributed systems. So what we've started to do is bake a lot of that foundational ideas about how you effectively run large scale distributed systems into Habitat, which makes it very easy to then go and take that developer, take their source code and deploy it using Habitat, using this knowledge that we have from distributed systems. So we actually see it as a benefit that we come from this infrastructure background because we have experience of actually running things in production, right? What do you see as some of the challenges that we still need to face in this kind of container ecosystem? I know one of the questions I have coming in is you talked about stateful applications. We know storage still needs some time to mature. Networking seems to be a little bit further along in what they're doing. What's your take as to what's doing well, what still needs some more work? Yeah, storage is one of those areas that, and persisting data is one of those areas that we are not able to get around, right? And if you look at some people's recommendations, so Pivotal, for example, recommends running persistent services on VMs, right? If you look at the Google approach or the Kubernetes approach, they actually recommend that you use a cloud provider services to go and run those data services for you until you think you're good enough to actually go and run it like Google. And they're also hedging on the fact that you'll probably never be good enough to run it like Google. So kind of building that expertise of running those distributed systems in an effective way is kind of the area and running those persistent data services in a highly scalable way is kind of the big challenge that operations still hasn't figured out. And developers also need work to, need help to help figure that out as well. Yeah, a big theme this morning was really about scalability. When you talk to customers, what does scale mean to them? What are the limitations they're having? I loved that you talked about what you're doing with Habitat, helping customers so that they don't have to have the expertise to build distributed systems. Because I mean, that's the software challenge of our time is moving to that. We talk at Wikibon. Moving from the old enterprise where it was like kind of baked into hardware to a distributed, where the software model, anything can fail, there's no single point of failure, I can scale. What do you think? So kind of paraphrase our CTO, Adam Jacob. He always likes to say ignore scaling problems because you don't have a scaling problem. And you don't have a scaling problem until you have a scaling problem, right? So if you kind of look at where your time's most effectively spent, your time is more effectively spent and actually building an application that people want to use and worry about the scaling problem when the scaling problem comes off, right? And the other thing is that you might never hit that scaling problem. So everyone wants to be the next Uber, everyone wants to be the next Netflix and so forth. And so if you go in as a startup or even a startup inside of a large enterprise trying to do a new application, if you start by trying to solve the scaling problem out the door, then what you end up losing is a lot of development cycles that you could actually be spending on building something that people actually want to use and then worrying about the scaling problem when you hit the scaling problem. So Mike, last question I have for you. A month from now, you're going to be back in Austin. A month from now, I'm going to be back in Austin. So tell us about Chef Comp. What can people expect? Give us a compare contrast as to kind of the communities, the type of people that attend, you know. I expect we'll see more shorts because it's going to be a little bit warmer and more humid here in Austin. Yes. So we're back in Austin for the second Chef Comp in Austin. We were here also last year. We were in Austin in July last year, which was not a fun experience. The air conditioning was very nice. The pool was also very nice. But what you can expect is more practical advice to how to actually run these things in production. We have a lot of talks about Habitat. I think we're going to have about nine talks on Habitat. We have a lot of talks from the Chef community about running actual systems in production and a lot of real world experience, which is something that we always try to cover into our conferences. We also have a day that's going to be focused on our open source community as well. So where our open source community and contributors can get together to talk about problems that they're trying to solve in our open source communities as well. And then on the last day, of course, as every conference does, we're going to have a hack day where you can contribute to open source, our open source, or we can help you get started solving a problem that you have. But there'll be a lot of people there that can answer questions for you about the problems that you're trying to solve in running distributed systems. Michael Ducey, happy to welcome you into the ranks of the CUBE alumni finally. Yes, finally, thank you very much. And thank you for sharing all the updates with us and thank you for watching theCUBE.