 So here we are in the next podcast for TFI, and today we are going to talk to Julian Dunn from Chef. Chef concept is coming up next week. Unfortunately, I won't be able to attend it. So we are, you know, talking to understand, first of all, what are the major announcements coming out and what is going to the focus of the conference. So Julian, please quickly tell us what do you do at Chef. Yeah, absolutely. So I'm Julian Dunn. I'm director of product marketing here at Chef. And so obviously I work with media and analysts and things like that and talking about our products. But I have a technical background. My previous role at Chef was in product management. So it's funny, I've only been doing this job for about six months or so. So a lot of the things that I said in motion when I was the product manager, I'm now able to announce as on the product marketing side. So I know a lot about that stuff and swap people who had asked me questions about that. Awesome. So let's start with what is what's going on with Chef these days when the whole market is kind of evolving, transforming. We see a lot of new buzzwords, but sometimes they're just buzzword repackaging. And sometimes they try to solve the real problem. So can you just quickly talk about the kind of evolution of market and where Chef fits in? Yeah, yeah, absolutely swap. And as a technical guy, I try to market to folks that are also technical. So you can have all these buzzword salad and containers and all this stuff. But look, I try to get direct to the point what's going on in the ecosystem. Chef as a company, folks might know us from previous days from more of an infrastructure automation company that was our original product. But over the last few years, we've been expanding that portfolio to first in the compliance angle. Because that's a real pain point for customers. And then recently expanding that into application automation, which is also a huge pain point for customers. How do you get software out there and delivered into the real world? Now, why do we start doing those things? I mean, one is motivated by market forces. As I mentioned before, you don't have user problems. People have pain point around that, particularly application delivery doing delivering apps one way instead of 15 different ways for each technology generation. But also, you know, more critically and fundamentally is because we saw people. The reason we knew we had to go and solve those problems is because we're starting to use Chef the tool to try and solve them and starting to get frustrated at those things. Because at the end of the day, Chef is a framework. And it's really Chef the tool, I mean, is a framework is really easy for folks to try and adapt it to other use cases. And they don't necessarily fit terribly well, particularly around checking for compliance and things. Well, here's an example of compliance. Why doesn't it fit terribly well? Because the types of people that need to do security compliance are not necessarily programmers or systems administrators. Often they're security engineers, penetration testers. Sometimes they're like compliance officers or infosec, high level infosec people, and they understand high level policy and things like that. But they don't necessarily know how to like write Ruby or even shell scripts, regular expressions and things like that. So trying to jam a tool, a configuration management infrastructure automation tool into a use case like that, you can pull it off. Sometimes if you have people, if you have more technically oriented people trying to do it, but to scale it broadly to the world and to people who are actually trying to use it to solve these problems is not really the right approach. So if you think about our enterprise, our architecture now, and I'm not sharing the screen right now because we're doing a podcast here and Swap, I don't know if you can actually see a video, but our reference architecture now is really about, let's make sure infrastructure automation has its place and Chef, we believe, is still the best product for doing that. But let's make sure that we're clearly delineating. If you're going to do compliance, you should be using InSpec because it's much more natural and easier to read and write language for those personas that I mentioned before. And then for application automation, application delivery, let's make sure people are using a product that's really solving problems for application developers and putting the application first because that's where all the business value is. So why are we trying to apply sort of sysadmin oriented tools to application developer problems? Let's go to how application developers behave and problems that they need to solve and make it really centered around applications. And then you can kind of think of the enterprise platform that's sitting on top of that. All these tools throw off an incredible amount of data and insights about what's going on for each of these areas. You have all this data. You're going to want to use it operationally for yourself to help, well, really just to help improve your DevOps process and help improve your company's ability to ship software really, really quickly. So you have all this stuff. Enterprise platform is really, on top of that data, allows you to collaborate, all those different groups to collaborate and see how each person's change in their particular domain area affects other folks. So that's basically how all the parts fit together. If I had to sort of look at this enterprise architecture diagram that we have described to you. Right. And I kind of, if you look at in general, if you look at any business, unless and until you are in a business of providing a kind of infrastructure, why should your developers waste all the resources in infrastructure when the real value comes from the applications that you're building? Right. So, you know, so that's the, I mean, if the whole evolution is all the way from, you know, one application running on the server to all the, sorry, machine to all the way to either serverless or whatever, the whole idea is so that to abstract everything else, whether it's pricing or human resource and just focus on the applications. So that is the trend that is going on there. Yeah, exactly. And our observation is look the way in which people are building systems to support those developers is almost thinking about it wrong. I mean, even if you think about the way OpenStack came about or even some of the patterns that I see, we try to warn, I mean, we're part of the CNCF, right? So we have a voice in there trying to warn people away from making the similar mistakes that no one developing Kubernetes is like, look, the system isn't for you as an operations person. The system isn't for you as a system administrator. Nobody goes in there and it's like, gee, what I'd like to do is to build some servers today for no reason. You know, I mean, it's all there to support a business, to support an application. You need to put in interfaces that help that developer really what are they trying to do? They're trying to move that workload into production and they're trying to coordinate and orchestrate that release of that workload with other stuff that's going on, particularly in complex microservice architectures where you have a lot of dependencies. And we still see in those worlds a very naive approach to release management for that stuff, right? You know, just it's still very much focused around, hey, how do I get this package from point A to point B? And not about how they actually coordinate and orchestrate that release without taking down the other components that are dependent. You know, it's just very, very primitive still. And so that's some of the capabilities that we'll bring to the table with Habitat and augmenting the platforms like Kubernetes to allow for what our viewpoint about auto release orchestration should be. Right. So what are the new additions that you're making to Chef or other components to ensure that as the focus is shifting from infrastructure to application so that you actually help customers and users? Yeah, absolutely. I mean, Chef is a long track record of working with enterprises and a lot of credibility there. And one of those things is, you know, which the benefits you get out of that relationship is that you really get to see the pain and the things that they're trying to solve for. And particularly, you know, narrow it down from an application to major use cases that we see enterprises struggling with. And by the way, you know, this is all couched in there. They're struggling with this in the context of your digital natives that are that are nipping at their heels. What we term and you'll, you won't be here to hear this next week's swap. You know, what Barry is going to talk about is these enterprises are being challenged by what we call the Fang companies, you know, Facebook's, Apple's, Amazon, Netflix, Google, who have one way of delivering applications. And that's what makes them really fast. Now, meanwhile, the Fortune 1000 Fortune 500 companies that are struggling to innovate partly because they have, well, you know, they have a lot of legacy. And that's that, of course, is something that's sort of unavoidable if you're a 50 year company. It's more than just the legacy. And legacy is a little bit of a pejorative term. It's more just they have applications that are written older style that still have business value. But the point is they have 15 different ways of doing this, 15 different ways of getting those apps to production. And that's one of the things that's slowing them down. And that's one of the use cases that we found really valuable for Habitat, which is how do I lift shift and modernize those legacy apps and move them into more flexible environments that allow me to manage things better. Look, if you just image that stuff and throw old apps into a container, you haven't actually improved anything. Sure, you made it so that it can run in Docker running Kubernetes. But if you haven't improved this manageability and also if you haven't improved how you actually are releasing that application, then you're just owning 15 different container workflows again. So anyway, so Habitat has, you know, that's one major use case. The reason I'm giving you all this context is the product announcements around this stuff are directly attached to this use case. So number one is legacy app lift shift and modernize. Number two is with these customers, you see, they're all excited about Kubernetes and containers and they are all in. They wanted that to be the future. But if you look at the depth of container deployment in the enterprise, 75% of enterprises have fewer than 100 containers deployed in production or 100 services even. And relative to their entire application portfolio, and it's been a couple of years, right? Relative to their entire application portfolio, that's still a small fraction. So clearly there's something blocking them being able to move this to production. And again, it's even in this container world, not having a single workflow and a single way to do this is blocking. Okay, so, you know, they look ahead and they're like, all right, so now I have three different application teams deploying things to containers in three different ways. What am I going to do when I have all my application portfolio, a large fraction of my application portfolio deploying to production? Am I going to have 16 Kubernetes clusters with 16 different ways of deploying? And so they're starting to go back to the drawing board and scratch their head. So Habitat is another thing that can help with that is build containers one way, deploy them one way. It doesn't matter if they're the newest, hottest microservice architecture type application written to go or whatever, or if it's your oldest legacy software, it's one way to get to a more manageable cloud platform. So into the announcements section, for the legacy modernization use case, what we have heard from customers, and we kind of knew this going in when we built Habitat two years ago. And I was the original product manager on Habitat, so I've been with the projects since the very beginning. But we always knew that we were going to need to bring this technology behind the firewall, because if you're looking at legacy apps, where are they running, running in some of these data sets, they probably have business critical data, they can't be out in the cloud. And when we launched Habitat, that's a SaaS originally, a public SaaS, we always knew that we were going to need to build this. So that's something that we're announcing at ChefCon next week, is the ability to have Habitat capabilities behind the firewall. We'll be working with about 10 early access customers on-brain, that's life. Now on the other side, on cloud adoption, container adoption, you know, it's really important, and Swap, I'm sure you know, right, paying attention to the CNCF diagram, it's like 3,000 pixels wide, like everybody has got their tool and stuff, you can barely read it. But the point is that people have already their favorite approaches and their favorite tools and orchestrators and things like that. But what we've always been is a company that is really integrated with other folks, like we will go and meet and deliver value no matter what your infrastructure choices are. You know, if you want to be using Kubernetes, you want to be using Cloud Foundry, DCOS, whatever, you want to use the Helm package manager, that's no problem. All these things are things that Habitat will plug into. So some of the announcements around accelerating adoption of containers is we have a Kubernetes operator for Habitat that we've refreshed. So if you know about the operator concept swap, it's really about, hey, you have a sidecar that manages the operations for your application. And the story is up until this point, which is kind of painful for developers, is look, if you want to do that, you've got to write your own operator. And the developer looks at that and says, so now you're making me write an operator for every app that I have that's important, and now I own two apps for every app, or I own an extra app for every business app. That's a pretty big burden or pretty big ask of me. So the Habitat operator, because Habitat has a built-in management interface, the Habitat operator allows you to use the same operator for all your apps without you having to own any operator. So that's one value add that we're augmenting the value in Kubernetes. Another example, so we have a Helm package exporter, as I mentioned before, we want to use Helm in addition to that. Open Service Broker integration is also something that we're announcing. Open Service Broker is something that originated in the Cloud Foundry world, which is really a way for you to create and manage services that aren't running inside or request, actually, through kind of a service cataloged interface, create a request services that aren't living on the Cloud Foundry cluster and present it as a unified API to the person that's interacting with Cloud Foundry so that they don't actually need to know, again, it's being developer-centric. They don't need or know or want to care whether or not that database is running on CF or off CF. And so Open Service Broker is a protocol as well, so we want to be there as well. Because not every workload is appropriate for a containerized universe. Stateful apps with a lot of data that need large data stores or queues or things like that, sometimes for performance reasons or just data management reasons, are not necessarily appropriate to run in a containerized environment. But you want to interact with it through a common API, so something like Open Service Broker allows you to do that as well. And finally, just like with many of our other products, like Habitat spends off a lot of data about what's in those applications, what the runtime state is, how are things changing in the system and if you want to be able to tap that data stream and use it in systems that they are already familiar with Splunk. So we're announcing a Splunk integration next week to start to surface some of this data in Splunk apps and dashboards and things like that for customers. Right. I will go back to the announcements. One thing that I do want to ask you, as you mentioned, the lift-and-shift model, what happens is that the refactoring or it's a very expensive process. It's expensive in terms of human resources, expensive in terms of cost. At the same time, when you are doing it, your application is still running, you are still serving customers. And you do want to be able to add new features as needed because you don't do it overnight. It takes months or whatever. So how do you enable customers? Like for example, as you rightly mentioned, you can just put everything in a container but you have 15 containers which are still kind of legacy application containerized. So what approach do you take to enable those customers to successfully do the lift-and-shift model without affecting their operations at the same time not incurring huge cost? Yeah, absolutely. So it really comes down to like you're talking about avoiding downtime for when you're migrating those applications to a different environment and things like that. So what are you getting at? I mean, I'm talking just overall, you know, it is an expensive process, no matter expense in a way with the downtime or in the developer resources or getting people to rewrite all those applications. How do you ease the question that makes sense? I think applications have been really it comes down to, for us, it comes down to a way of packaging problem. This is where it's like people don't believe us when we talk about this or we've proven it. I mean, you have to kind of see the technology in action to see it work but it's like if you can package, if you can start with, let's talk about like how people have built apps in the past or built the supporting structure to support those apps in the past. What you do is traditionally you would have bought a server, you put an OS on it, you install a bunch of OS libraries and user land, then you install some libraries or like, you know, JRE or this kind of stuff to support that application. And then finally you put that application on top. And the trouble with doing things that way is that there's no clear delineation between where the business app ends and where, and sort of where the rest of the support structure begins because actually what ends up happening is all that stuff is so tightly bound together in the sort of what we call this triangle that that is actually the artifact that you're trying to move around. And this, you know, point of fact is why customers, you go to enterprise customers and you're like, what is the oldest operating system running? Yeah, you're running 2008, a lot of hands go up. You're running 2003, some cheapish hands go up in 2000 and T, you know, maybe some folks are still doing that, right? Because of that model, this whole thing, including sometimes the server, which people are carting from data center to data center, there's the artifact that you're actually doing. So you can actually repackage a lot of these applications. If you start with the app itself and I start to think, if there's a way I can describe the dependency tree, that app and start walking down the stack, then it allows me to actually kind of invert the triangle and extract that app and the entire set of its dependencies from the operating system and from the user land. And now this thing becomes a portable product. And that's what Habitat technology allows you to do, which seems a little inconceivable, but if it works, it's possible, we've proven it. You know, we won't be here to hear some of these customer stories next week, but here's a real-life example working with a major car manufacturer here in the United States. And they had an old app written in Borland, Delphi. Do you remember that technology? The late 1990s, early 2000s. It was written in Portuguese, right? They contracted some Portuguese developers. So the source code is all in Portuguese. The application is all in Portuguese. There's no way that English-speaking developers are ever going to be able to refactor it and look at this app in any other way, because developers are along God. But this app is still extremely valuable for them. And so we were able to... This is Windows app, by the way. And so, by the way, Habitat works on Windows. So they're able to describe this app and its dependencies and extract it from whatever operating system and all the stuff that they're running, Windows 2000, here, here, here, and take the stuff. And then they can decide, now is this thing appropriate for me to run on a container? Or is it appropriate for me to run on, let's say, HPE synergy equipment in my hyperconverged stack, or maybe my VMware, or whatever, and freeze them from the infrastructure choices that they were bound to before and allows them to move that workload around to wherever they think is an appropriate target. Right. Yeah, thank you. Yeah, it makes perfect sense now. Okay, now I'll go back to the announcement part. Yeah, I explained really well. And I wish I could see the demo and I wish I could talk to partners. So next year, I'll make sure somehow that... Because those are the stories that we are really interested in how people are actually using it, how it actually works. Maybe we can plan a demo also, podcast next time, you know, where we can just have a kind of demo over. Now, going back to the announcement, out of all these announcements, which one do you see? I mean, of course, you cannot pick your favorite baby. But out of all those announcements, which one do you think is the most critical one? That's what I'm more interested in. You know, I think most of the... Well, let me just touch on... I didn't touch on Automate 2.0 as an announcement. I'm talking about Habitat announcements. But, you know, one of the reasons it's 2.0, as you see, is because we basically rebuilt that platform around that. And we're eating our own dog food too, eating our own chiming, whatever your favorite metaphor is. You know, it's what we realized as we had Automate 2.0 as about two years old at this point. And initially, it was sort of a monolith application that was very much centered around just infrastructure automation. As we started to layer in the enterprise features for compliance, and then now we're starting to look at application automations, habitat data, we're like, look, we're outgrowing this monolith model where it's like an elastic band ball where you just keep adding more elastics to it. And it can't support either the business. You know, technically, it's hard to iterate on that. But it also doesn't... It's not really aligned with your strategy, which I think is an important lesson for folks. But your architecture matters a lot because it actually should map directly to what your product strategy is. What we're building here is a data-driven platform that needs to be flexible enough for us to build additional experiences on top of our version of data. So 2.0, completely written, microservice architecture can go under the hood with a real public API. And then on top of that, the visualizations and things like that, which have all been rewritten and are very powerful for actual operational analytics and debugging, are all invoking that API. So why does this matter to customers? Number one is built with Habitat under the hood itself, which allows for us to show how this kind of continuous delivery will work in practice for them, even with a complicated on-premise microservice architecture with a lot of dependencies. We believe that we can actually upgrade customers on-premise very, very quickly, which has been generally as a pain point for on-premise enterprise software. It's almost like we're able to bring what really is like we're able to bring SaaS-like capabilities, which is all they ever wanted into the enterprise behind the firewall. So that's really, really exciting. Number two, having this real public API allows for us to pull off really interesting integrations now. So for example, we're announcing an integration with ServiceNow next week, because customers are like, look, I have ServiceNow. You're generating all this operational data and alerts and things like this for failures. Can you just open tickets in ServiceNow for me? And by the way, the other problem I have is I have this CMDB, which is never up to date because it's only like Bob in accounting who updates it whenever there's a new server and always had a date. So you have all the live inventory, so can you just populate and update my CMDB? So if we didn't have this public API and get the front-end consumption layer was balanced so tightly to the data layer, like it is in 1x, we wouldn't be able to pull off stuff. That's another key thing I'm excited about. And then number three, as I mentioned before, having a front-end that's accessible, supports modern browsers, has what some of our largest customers are running upwards of 70,000, 80,000, sometimes more nodes against Automate. And at that point, it doesn't become a technical scalability problem. I mean, your data stores can handle that. It becomes a cognitive scalability problem, like firing events from 70,000 machines at you that are generating data points every 10 or 15 minutes. You need a way to be able to drill quickly into what's failing, be able to prioritize. It's not just about what's failing. It's like, what's important for me to address right now, and in order to be able to do that, I need good visualizations and good query language in the interface, which is like, there's a rich query language now built into that UI, allows me to drill right into those areas of failure and find out what's going wrong so I can fix things. So that's what Automate 2 for us is really, really powerful. And that's the thing I guess I would say I'm really excited about, probably the most excited about that. Awesome. Anything else you would like to talk about? I think we have kind of covered some core topics. Well, we should talk about Chef Workstation, which is something that fills a gap in our product portfolio. In the past, if you were part of the initial cohort, the early cohort of folks that were doing infrastructure automation, and you knew this was something that you wanted to do, then Chef was great for you. But it was maybe a higher friction than necessary. You had to set up a server in order to use Chef. You have to go out there and write a recipe, do some other stuff, figure out what a recipe even is, how do I actually do that. It's a difficult interface to go and consume community content today without this kind of a thing. And so for a later cohort, look, this kind of automation has been around for over a decade. So it's okay if you're a later adopter, that's fine. But what we realize is that the persona of the later adopters is slightly different in the sense that they maybe don't know that they want to do this yet. And so they don't want to spend a lot of time learning and learning a big language and all this stuff. And maybe they're even skeptical. Sometimes they're skeptical. They're like, what benefits does this bring for me beyond the shell scripts or power shell scripts or even me clicking around with a mouse and a GUI? And so we want to make it so it's a completely friction-free experience for folks to be able to get started with Chef. And so that's what we're doing in introducing Chef Workstation. And Chef Workstation is really two things. Number one, it's the single desktop and laptop experience for Chef, and that allows us the foundation to be able to improve on that. So you can kind of analyze it to the way Docker for the desktop used to be. I don't know if you remember I played with Docker before, but Docker on the desktop used to be, hey, what we need to do is to install VirtualBox and install Docker and then do all this stuff. And then finally you're able to get started with Docker. And they had this similar issue, which is, look, if I'm not sure that I like Docker, just let me download one thing and get started. And that's where Docker decided they went ahead and built Docker for Mac. Docker for Windows is one of the experience to get from Docker without any of that hypervisor. I'm going to knit all the stuff together. So it's exactly the same thing that we're doing with Chef Workstation. That's number one. By the way, the product manager on Chef Workstation is the same fellow that worked on Docker for Mac and Docker for Windows to solve this problem. That's why I bring it up. Number two, in Chef Workstation is this new capability that we're calling target mode, which is basically, look, you just want to experiment and do some ad hoc tasks with Chef. So you don't download anything, no server. You don't have to write a recipe or even know what that looks like. What you want to do is just install Chef Workstation and you have some machines out there that you want to apply automation to. And with one command, you should be able to see how that gives you things. Is it supported across all three platforms, Linux, Mac, OS, and Windows, or only for specific platforms? Yeah, that's right. So at launch it'll be a package that you can download for all those platforms. Anything else you would like to touch upon or we have covered the whole, you know? We've covered most of the announcements. I mean, of course, we're going to enhance the compliance features as well in Chef Automate. I mean, I forget if we briefed you around InSpec 2, things like that a couple months ago as a swap, but InSpec 2 is really bringing compliance beyond VMs to now Cloud APIs, the mode interrogate Cloud APIs. And so that's something, of course, we're incorporating it to Automate 2 as well. And announcing support for Google Cloud Platform as an additional target for Clouds. And then also announcing integration and ability to interrogate Cisco iOS devices and check for compliance around that. We're like, well, what else could we check for compliance? And really we want to have compliance in our view on around compliance spread out to any area where it's needed to be enterprise. And then, of course, there's the usual bevy of partner announcements that touched a little bit on HPE, and you'll see some customer stories next week about how people are using soup to nuts all of our kit to be able to leverage this pile of metal that they have, the HPE synergy, the type of converged stuff. How do you get from that pile of metal to running apps where you use all of our tooling? Chef could provision the stuff and get that ready and allocate your storage and compute, and then InSpec, you want to make sure it's compliant all the time, and then it's habitat to deploy your applications. And I touched on some of the stuff in our partnership with Microsoft, which these things are somewhat, they're already pre-announced at Microsoft to build, but integration with the new AKS, the Azure Kubernetes service, people want to have just the managed Kubernetes service we want to deliver the value and habitat there. And then service now integration, I touched on before. So just a lot of other partners, ISPs and things like that. Yeah, we can wrap up with this. The last question would be that, what are the new and exciting use cases that you are seeing there that you think serve conserved, which can either be challenging for you at the same time creating an opportunity for you? Yeah, new and challenging use cases. I would say that we're basically focused on helping those enterprises that I mentioned before become digital leaders in the way that we call like post-digital transformation, because people have been talking about digital transformation for a long time. The chickens are coming home to roost where you start looking at, the retail landscape and things like that and the banking landscape. We are there to partner with those customers, but at the same time, you'll hear this sort of a little bit in various keynotes as well. The sense of urgency for some of these folks is not necessarily there, but we're here to help as trusted partners, not just software vendors, but as partners to try and say, look, you've got to get on board and figure out how you're going to move really, really quickly, or it's going to be painful for you in the future. What you not only need to do is to deal with all the stuff that you have today, but you need to figure out how to innovate and create compelling experiences for people and be just as innovative and experimental as those digital media companies. That is incredibly challenging in and of itself. We think about banks that have been around for 100 years and have certain approaches up until this point, but still are not recognizing that this is really digital experiences that's a disruptive change for them, so those are the major challenges that will work on. Thanks a lot, Julian, for talking to me today and hopefully we'll catch up with you again next time and have a great conference. I'm sorry that I'll be missing it, but I'll be covering it remotely and you'll be getting all the stories and news from Chef Cons. So once again, Julian, thanks a lot for your time today.