(electronic music) >> Announcer: Live from Austin, Texas, it's theCUBE, covering DockercCon 2017. Brought to you by Docker and support from Asseco System Partners. >> Welcome back to theCUBE, I'm Stu Mittleman, with my co-host, Jim Kobielus. 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 Ducy, who is Director of Product Marketing at Chef Software. Not a chef. Maybe you might-- >> Not a chef, although I do cook at home (laughing). >> Maybe in Chef. Not a puppeteer. >> Not a puppeteer. >> But you work for Chef Software. So thank you so much for joining us. >> Yes, thanks for having me. >> Alright, 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 Inspect, 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 for them. My passion's always kind of been open source communities, an 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 (laughing). 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 I'm sure I wouldn't be the first one that woke up next to a goat in Amsterdam (laughing). 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. >> Umm-hmm. >> So how's Docker doing? What interested you in the keynote? How do you as an individual in Chef see what's going on in the Docker ecosystem? And what do you think? >> Yeah. >> Yeah. >> So we've been put in a little bit of an interesting position as Chef, the company. And 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 a 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 why co-worker draw 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're 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 have this fun little thing. They have this 8-bit video game playing. >> Right. >> And it was like they were collecting coins and they were leveling up, but they kept hitting lots of bombs (laughing) 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 (laughing) and I will get past everything, but, Boy, I'm going to have lots of bombs going off and things-- >> Sure. >> And things that I'll have to deal with, and there were lots of fun little comments that they threw out there. It's like, Checking documentation. Oh, documentation says you don't have documentation. (laughing) So just fun stuff like that. But it's challenging. 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. >> Umm-hmm. >> A lot of the ecosystem helps to solidify that about you here. >> 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 there's the security aspects of it is focused on what vulnerabilities are in your container. >> Yeah. >> 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 in config files. Am I disabling versions of ISOCELL that's no longer a best practice anymore because it's actually broken. And then there's other aspects around how do you 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 malconfiguration of the application, so-- >> Right. >> If you take a container from one environment to another environment and kind of work it through a lifecycle. There are things at runtime that you have to change in its configuration to make it run in that particular environment. >> Right. >> So it's all of those little knobs that you still have to turn. And that's why-- >> The entire DevOps lifecycle essentially there's all those little knobs and... >> There's all these little knobs and this has always been a little bit of a frustration for me, in that PaaS 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. >> Right. >> Michael, we've seen the cloud providers and some of the other open source providers kind of chipping away. 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 platforms. >> Umm-hmm. >> 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... A 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-- >> Yeah. >> 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. We're taking source code, building that source code, and then deploying that source code to production. >> Yeah, and it's interesting, it sounds... We talk about Docker. They very much started out in the developer world, and then they're kind of moving to kind of the Op side more. >> Umm-hmm. >> And to the enterprise side more. You're almost going-- >> Michael: And we're kind of-- >> A little bit in reverse, huh. >> Yeah, going a little bit in reverse, yeah. >> 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 are you seeing in your customer base? >> Sure. >> Who do you sell to in that aspect? Yeah, I'm just curiosity at 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 BMs or machines that they have to manage, right. And 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 in containers or PaaS. But when you're actually having to go and persist data in something like Red-S are Mongo or MySQL, that's a whole other area of concern that you have to worry about. So what we've actually had started to do is the core team that actually works on Habitat has a very, very big background in distributive systems. So what we've started to do is bake a lot of that foundational ideas about how you effectively run large-scale distributive 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 distributive 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. >> Umm-hmm, 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. >> Umm-hmm. >> 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're not able to get around, right. And if you look at some people's recommendations, so Pivotal, for example, recommends running persistent services on BMs, right. If you look at the Google approach or the Cuber-netee's 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. (laughing) And they're also hedging on the fact that you'll probably never be good enough to run it like Google. >> Yeah, yeah. >> So, kind of building that expertise of running those distributive systems in an effective way is kind of the area in 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, the big theme this morning was really about scalability. When you talked to customers, what does scale mean to them? What are the limitations they're having? I loved when you talked about what you're doing with Habitat. Helping customers, so that they don't have to have the expertise to build distributive systems because that's the software challenge of our time-- >> Yeah. >> Is moving to that. What we talk at Wicky-bon, it's moving from the old enterprise where it was like kind of baked in the hardware to a distributive, where the software model, anything had failed, there's no single point of failure, I can scale. >> Yeah. >> What do you think? >> Well, to kind of paraphrase our CTO, Adam Jacob, he always likes to say ignore scaling problems because you don't have a scaling problem. (laughing) 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 at actually building an application that people want to use, and worry about the scaling problem when the scaling problem comes up, 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 ChefConf. >> Yes. >> What can people expect? Give us a compare and contrast to kind of the communities, the type of people that attend. I expect we'll see more shorts because it's going to be a little bit warmer and more humid here in Austin (laughing). >> Yes, so we're back at Austin for the second ChefConf in Austin. We were here also last year. We were in Austin in July last year. >> Ooooh. >> Which was not a fun experience (laughing). The air conditioning was very nice. The pool was also very nice. (laughing) 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 a lot... Nine talks on Habitat. We have a lot of talks from the Chef community about running actual systems in production in a lot of real world experience, which is something that we always try and hover 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 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 distributive systems. >> Alright, well, Michael Ducy, happy to welcoming you into the ranks of theCUBE alumni, finally. >> Yes, finally, thank you very much. >> And thank you for sharing all the updates with us. And thank you for watching theCUBE. (electronic music) >> I remember...