With over 40 million downloads, I'd like you to please rise and welcome to the stage, Adam Jacob.

I like this everybody gets a standing ovation thing. Super awesome. It was a trick I figured out last year that if I asked you to stand up at the beginning and then again at the end, I was guaranteed a standing ovation. So that's my thing now. I haven't figured out actually how I'm going to get you to stand up at the end of this one because the transition is where you'll see.

But hopefully we can work it out. Let's start maybe. Okay, well before I actually kick off the full talk, it's been 10 years for me since I started this thing that now is Chef, which is awesome.

How many of you have worked at the same job for 10 years? Right, me and that guy. Who's Joshua Timmerman who worked with me 10 years ago? Okay, so I just want to say thank you to all of you who have given me this incredible opportunity to do this thing and to have this thing that we just made up.

We were literally just making it up. And you keep making it up with us every day and it's so great and I'm so appreciative of it. Before I get all the way going, I have a couple of things I want to do. One person in particular I want to thank because I feel like ChefConf has become this moment where we all get to come together and really feel how connected we are

as a community, all the incredible music, the incredible show that gets put on for you. Carolyn Beck has really been amazing. So thank you, Carolyn, for all that you have done

and for the incredible show that you put on for all these people. Okay, let's do a keynote. You guys want to have a keynote? Was that cool? I mean, otherwise I'm just going to hang out and talk to you about whatever comes up to mind, which could be cool but probably won't be. Okay, I think over and over again through the keynotes from Barry

to the awesome keynote from SAP, the Capital One video, all of those things, Forrester, the pace of change in our world is only getting faster. All of the technology, all of the things that are going on, the culture changes, everything is just speeding up and ramping up.

And I really want to talk about what the future of that enterprise looks like. We keep talking about digital transformation and I want people to understand what is it that we're transforming into exactly. And so we talked about it as outcome-oriented. Barry did earlier today. And beneath it, he had this little thing in parentheses and it said application-centric. I don't know if you guys saw that.

And for me, the application-centric part of this is where we start to get into the technical rubber that meets the outcome-oriented road. As an organization, we're really trying to figure out how can we shift to this world where we think first about the applications and what they provide to our users and then second about everything else. And right now, our enterprises are a lot like this bowl of soup.

You have a lot of different technology that you have built up over the years that makes sort of this delicious chunky stew, right? Things like data centers, infrastructure as a service, you have containers, you have microservices, you did client-server and now you did service-oriented architecture because client-server sucked and then you did REST

because service-oriented architectures were for suckers, right? And all this change that's happening in the industry is just like stirring up your soup bowl with a spoon, you know? It's not like you actually get rid of all the pieces. My analogy breaks down because you could eat the ones you didn't like first, but no one does that. So the truth is you have all this stuff and it's still wrapped up inside of your organization.

And the enterprise that wins, that becomes one of those digital attackers that we talked about earlier, that's the enterprise that learns how to shift its focus and learns how to shift with those changing tides and learns how to incorporate all of those things that you have done over the last 20 years into one truly delicious stew. But in general, when we talk about our own technology strategy,

we tend to reach for technology strategy. We go, things are changing. Well, what's the new hotness? And then I'll just adopt that and everything will be cool. And it's sort of like this. This is the Howland pulverizer and Jordan's pulverizer. These are ore pulverizers.

So they crush coal or iron or whatever. And the Howland pulverizer and the Jordan pulverizer were created about a year apart sometime in the 1800s. I only know this because I thought the picture was cool and then I was like, I have to find out the story behind the picture, so I have no idea if this is a complete lie. So you've got to go with me because I'm not an expert on frickin' ore pulverizers.

But they were a couple years apart. And there was actually, I think, a very dramatic conversation about the future of ore pulverizing in this era where it was unclear which one of these was going to be the dominant ore pulverizer. And it was this big technological shift

that was happening in that industry where they were getting 10x improvements in ore pulverization and it was really transforming the energy industry as we knew it in the 1800s. And you can think about this like the same conversations we used to have about rest versus service-oriented architecture, right? Like, you could have 100x improvement if only you used this thing.

And the truth is, just like these ore pulverizers, no technology actually saves us in the end, right? It's not like we adopt a technology and then all of our problems are solved and we never have to adopt another technology ever again. And so our enterprises right now, they feel a lot like this water tower, right? They're this collection of technology, this collection of culture that is kind of utilitarian and also invaluable, right?

If you live in this town and that water tower goes away, you don't have water to drink and you are mad. You were like, what the hell happened to my water tower, right? And you don't really expect that your water tower is going to shift and change and grow with the technology times. You're just like, how about fresh water

with no ore in it, you know? And, you know, look, we can dress it up and make it fun. We put Christmas lights on it, like they did with this. I don't know if you guys can see the Christmas lights, but there's Christmas lights on this water tower. And the thing we have to become, though, is this. We have to figure out how we go from being these incredibly valuable enterprises

that run the fabric of our lives. You run all of the business that does everything in the world. How do you also figure out how to go to space? How do you become these innovative, adaptable, agile organizations that are customer-centric and software-led, business-driven and cross-functional and move at a high velocity and are safe and compliant? And the difficulty here is magnified

because we don't just have to get one enterprise to space, which, for the record, is what the large web companies had to do. They didn't have to get each other to space. They were like, I'm Facebook. I got myself to space. Just do what I did. Space is easy, right? But they just had to get themselves to space. No, no, no. We have to get the guys who pulverize ore to space.

Right? You guys with me in the analogy? It's a tough problem. It's harder than the problem that Facebook and Google and those guys faced, which I don't mean to trivialize. It's incredibly difficult. But it's not like we stop being water towers, you know? We're on this digital journey. We have to transform.

We're going to become this amazing new thing. But how do we do that? How exactly are we going to get to space? So first I want to start by talking about how cute this bear is. Right? This is such a cute bear. And I think he feels about that tree like the enterprise feels about space. He's like, ah, I made it.

Okay, so step one. We have to learn from each other, right? I know this sounds trite to start with learning, but it's true. We have to talk to each other. We have to come to places like ChefConf, and we have to talk about our experiences as enterprises, as people. We have to talk about new technology. We have to learn from the big web. We have to learn to adapt that learning to our business.

So when we hear a talk by someone from Facebook, when I get up on stage and make bear jokes about space, you have to figure out how that's going to apply to what you do, right? I was talking to a guy who works in oil. He runs a mid-sized oil company, which means it's like worth $5 billion in a couple trillion dollar industry, which I thought was hilarious.

But yes, there are such things, I guess. Texas. What do you know? Oil. And they're taking all this technology learning, and they're figuring out how exactly are they going to improve the nature of their business. And then finally, from that adaptation, they're going to grow new capabilities on top of their existing and future technology base, right?

Those old words, those things that are in that bowl of soup, they don't go away. They live on inside of our organizations and inside of our enterprises, and our job is to figure out how do we adapt that technology to grow all of what we do forward as an industry. Because I think the enterprise of the future is the one that adapts gracefully to new technology, right?

That actually can, when something new comes along, incorporate it into its DNA without having to actually fundamentally rethink everything about who it is. Right now, I think it's kind of like we're stuck in the surf. Is anybody a surfer? Do you go surfing? I've only surfed a few times. My wife surfs a lot. And when you fall off of a surfboard and you're in the surf,

you get tumbled around, and it's really nerve-wracking. And every time it happens to me, I'm like, oh, my God, I'm going to die. And then I don't die, you know, and it's cool, and I'm treading water, and then another wave hits me, and I'm once again like, oh, I'm going to die. And then eventually you sort of come out the other side. And I think right now most of us are in the surf, and maybe a few of us are treading water, catching our breath.

But as organizations, we're not really swimming yet. We haven't really reached the stage where we're going to compete for advantage, which is a thing you have to remember. Like, we're all going to transform, right? And if we all transform on the same platform, and it's just about a technology transition, well, where is our competitive advantage between the other people who also do what you do?

There's a trick question there. You don't have any, right? So what is the thing that's going to make you better? And the one thing we know is that change is inevitable. There will be new technology coming tomorrow. So it's just if all we wind up with is another word in the soup, right? If all you do is adopt Habitat, if all you do is adopt Kubernetes, and you say you digitally transformed yourself,

well, I think we've missed the opportunity to really make the transformative difference that we could make in our industries and in our companies and in our lives. And I told this story last year about a man on a horse, and there's this man, he's on a horse, and he's riding toward a crossroads, and he sees his friend off in the distance, and his friend notices him coming,

and the horse is riding up to the crossroads, and the man standing at the crossroads shouts up at his friend, and he says, hey, where are you going? And the man on the horse goes, I don't know, ask the horse, right? And the horse here is technology, right? And right now for most of us, we're just along for the ride.

And the enterprise of the future is the one that figures out how to ride that horse, who figures out how when a horse gets tired, when some technology doesn't work for it anymore, how to swap it out for another horse without having to fundamentally teach itself how to ride horses again, right? Hey, Adam. Yeah, Derek, I'm doing a keynote.

Yeah, but the horse, the horse, I've got to speak to this. What's that? This is transformative. Cloud computing won Preakness. Oh, my God. There's a horse, and its name is cloud computing, and it won the Preakness. It won the Preakness. Oh, my God. Well, then, I guess this analogy is over because it's done. Cloud computing knows how to ride the horse.

So AWS can leave the building. Scott Wiltemuth was going to come up, give a talk. He doesn't need to anymore. They're already riding the transformative. Okay, enough of that. Hey, Scott, you can still come out. It's cool. Okay, so I think in order to do this,

we need to stop thinking so much about the technology. Barry talked about this with those two triangles, right, where he was talking about shifting from thinking about infrastructure and then maybe outcomes to the other direction. And I think about this as focusing on behavior, where if we can let the way that we want to interact and the outcomes we desire drive the design of our enterprises

and our technology initiatives, then what we wind up with are capabilities that allow us to do things like ship software, manage our infrastructure, stay compliant. And those things, they'll stay consistent no matter what the technology is that we're using under the hood, right? Why is it that we have to reinvent how to do a health check

every time we get a new technology platform? Why is it we have to reinvent how we stay compliant every time we add a new component to the stack? And what we need is this common language amongst ourselves culturally and technically so we can think about the pattern of behavior that allows us to build reliable systems that will allow us to build this enterprise of the future. And way back in the early days of computing,

a very smart man said this. The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. This man was Alan Kay. He was the inventor of object-oriented programming, Smalltalk, and GUIs. And what he was talking about, I think, is that it's much more about the messages

that we communicate in our systems than it is about the design of any individual component. And the next enterprise that wins is the one that can shift that implementation, right? Where the messages, the behavior between us, that stays consistent. Our language doesn't change. But our technology can swap in and out. And I'm going to talk a bunch more about this tomorrow. So, hang on.

And we think that there's really three foundational automation behaviors that you need to have in order for this system to really be great. There's probably more, but I'm willing to talk about these three because they're the place that I have product. Yeah, okay. Number one.

Infrastructure. I think this one's the best understood. And it's where Chef lives, right? Infrastructure as a service, configuration management, all of these things. It's the one that is what we understand best. And like Barry said, just because we understand it best doesn't mean it's not important. If the infrastructure sucks, everything sucks. So, obviously, Chef fits here. We've built the most reliable systems

in the most difficult infrastructures over the last ten years. And much of the cloud migration happened because of and with Chef. And I couldn't be prouder of all of that work. The next is security. And this is about how we validate that change in our environments and how we can continuously adapt and integrate new technologies

while still certifying that we remain safe and secure and compliant. And I think that SAP NS2 talk was amazing at illustrating just how complex this can be and how much we need technology in order to keep that true, even as we adapt new things. And then finally, application automation. This is about how we build, deploy, and manage our applications. And this is the one that I think

we understand the least. As people, as an industry, we're still really trying to think about what the right abstraction is here and what is the right way to think about how we build and deploy and manage applications in a way that will allow an enterprise to be able to manage its existing estate and also all of the estate that it's moving to the cloud and also to the thing that we haven't thought of that's going to matter in two years.

Long-term, I think this is probably the most valuable of the abstractions. When we get it right, it's really, I think, going to unlock all of that value in the enterprise that will allow them to really figure out how to get themselves up into space. And obviously, we believe Habitat is the best way to do that. It's by far the best way, I think, right now to move your existing software not only to the cloud but also into containers

and hopefully whatever the thing is that comes next. And we'll talk a bunch more about Habitat. And all of this is leading up to this phrase that I'm sure you're getting tired of hearing by now, which is continuous automation. When we build an enterprise that has this right behavior, that understands how to ride that horse, that can evolve and adapt its technology strategy, it starts to use innovation to its advantage, right? It starts to see technology

not as disruptive to its business but instead as an accelerant on top of it. And that's the goal. Can we actually build this organization that can continuously innovate and continuously automate what it's doing? And so if you want to understand Chef's strategy, if you want to know why we're here and what we're doing and where we're going in the future, this is it. We're here to learn with you

about what those patterns of behavior really are. What is that common language that we need to unearth together in order to really build an organization that is the future of the enterprise, that actually transforms itself into something fundamentally different than it was before. And it's not about a single technology choice. It's about building that first enterprise that can really adapt new technology

at the same pace, maybe faster, than the big web can. Okay, I have a bunch more time to talk to you guys tomorrow about all of this stuff, and I promise we'll go deep into how I think we can build that future of the enterprise. But for now, I sort of want to put the philosophy down for a second and instead talk about all the cool things

that we have built for you in the last year. So number one, we heard a bunch about how speed and releasing and shipping every day was a critical component of being a good and agile and fast software company. I'm proud to say we released 771 times in the last ten months since the last Chef conference.

That's more than twice a day, which I think is probably obvious if you can do basic arithmetic, but I think it's a really great talking point. And that's across all of our different product lines. We're releasing the unstable channels all the time across Chef, across Automate, the supermarket, Habitat, InSpec. I'm really proud of that number

and of the teams that made it happen. So let's talk about Chef for a second. I think the big things for Chef this year were about stability. They were about quality of life improvements. Chef 13 has more resources included in the bag. It's safer, it has fewer rough edges, and it's easier to get started with. You can see all of those improvements in the Learn Chef material, all kinds of great things.

The Chef DK2, which I think really has pointed the way for a lot of folks to think about shipping all of the developer tools that make you productive with your automation software. Test kitchens had great improvements, all kinds of stuff. Tomorrow you can hear more about this on the main stage from Tom May. There's more Chef talks happening, obviously, at ChefConf than I can relate to you, but I hope you check them out.

InSpec this year was really about coverage. It was about expanding the coverage of everything in your world. So can we go out and test everything? Can we test containers, APIs, operating systems, applications? How can we really get to a place where that continuous compliance is happening

not just on operating systems, but on everything we need? We've released a couple of really great features where you can use InSpec to vet your AWS APIs or vet vSphere, right? And I think that's a very exciting direction that really shows you what the future of InSpec really is. And then we have programs like DevSec where we're publishing a bunch of security baselines

that you can just get going with right now to see if you're meeting best practices. There's a lot of InSpec talks. Christoph will be joining me on stage. He's one of the original authors of InSpec. And there's a great talk that Victoria and Hannah are giving at 2.30, so if you want to know more about what the basics of InSpec are, come to that. Habitat this year was really about making things easier.

It's about smoothing out that production cliff. If you were here last year, you heard us talk about this difficulty curve that ramps up really high as you get closer to production. And we've put a lot of work into making Habitat easy to use and easy to adopt. One big piece of work there is what we call scaffolding. And so that allows you to have maybe six lines of code

that describe the stack that your application is in and what you want to call it. And then from there, we can automatically build you a Habitat package that's ready to run that you can export and run in any environment. There's a build service that we've built and launched. You're going to see a bunch more about that. There's nothing I want more than to tell you how cool this is, but you have to wait like five minutes-ish.

But it's awesome! So it's also about adding more and more software into Habitat. So things like Kafka, Cassandra, Postgres have packages that are already built and ready to go for you. You'll hear more about Habitat tomorrow from Jamie Windsor. He's also doing a Getting Started talk at 1.30

right after this. You should check it out. And then finally, our commercial product, Chef Automate. I think it was really about two things this year. So one was power, and the second was clarity. And I think one of the things we really have learned is that when we bring things out to our customers, the focus we need to have is on the jobs that they want to get done. Rather than just visualizing all of the data

and all of the things that are happening inside your environment, what you really need to focus in on is what is that person who is running a systems administrator, running infrastructure, what's the view into that that they need in order to solve the problems that are in front of them right this second? What's the thing that CSO needs to understand their compliance strategy?

And you're going to see a bunch more about this. In fact, rather than talk about it, I think we should show you. Can we show you stuff? Is that cool to do my demo? I know I'm riveting, but let's do some demoing. Demoing's dope. I'd like to welcome out to the stage Seth Falcon and Dominic Richter.

Meanwhile, I'm going to move over here to this little table and I'm going to sit in judgment. So you guys just think about me. I'm over here. Seth, VP of Engineering.

What's going on, Seth? How are you? I'm excellent. How's my demo, Dom? Oh yeah, so screwed. Already? Come on, get it done. So Adam, you were talking about three things, right? You were talking about the three things of, you know, your three things. We're starting with infrastructure.

And we're starting with, and then security. And then application. You got that. And so, you know, like what we're going to demo, we're going to... You're going to show me all three? Turns out, we're going to show you those three things. Oh my God, that's amazing. I know. Are you guys surprised? Are you shocked? Honestly, I am. This is the first time I've seen it, so let's go. Yeah, so... That's why all the banter feels forced

and I keep throwing Seth off his game. So Barry talked about the importance of outcomes and of applications. And I realized I don't have the clicker. Hey, you know who does? Right here. Thank you. What's up, brother? That was probably smart not to just throw it. It was tempting. I did want to, but we would have dropped it. But so applications.

And, you know, it used to be that deploying applications, which is really what we're all here, like that's... These are the outcomes. The outcomes are about deploying applications. And that used to be easy. Like, we used to know all of our servers by name, all three of them. Yeah, Alice, Bob and Charlie. Yeah, I had a workstation.

I worked at a company where they were all named after Transformers. And when you joined the company, you got a new workstation whose name you were not allowed to change that was just the next Transformer in the list. Mine was Repugnus. I got to tell you, as a new hire, that didn't feel cool. So, like, things are more complex now, right? And maybe that's a good thing because no more Repugnus.

But it's okay, right? So things are more complex, but we have automation. And we have things like Chef Automate that help you rein in that complexity and that can remember the names of the servers for you and help you manage your fleet, whether it's three nodes or 30,000, right?

So we're gonna start with infrastructure. Yeah, and we're gonna see, we're gonna sort of get a view of the state of the infrastructure we've built for our demo through Chef Automate, and that's what Dominic is gonna show us for the first part of the demo. All right. So let's drop right into Chef Automate here.

We've got the node state open. This is all of the Chef runs that have been running. And by the way, these are all of the server names. We got you covered. So in here... We should have put one up that was Repugnus. I mean, we tried, but the system rejected it. Yeah, I put that in. All right. So if I go over here, you know, I can filter for the acceptance environment

where all the failed servers are. I put that up. Failed servers? How do we have failed things in our demo? I don't know. Elliot probably screwed it up. One sec. So we can look into this. I can look directly into the server. This is the one with the failures. It's been failing for a while. We can see that on the right-hand side with history, right? It's not just me.

So if I go over here... This is one of the things that I like best. You know, we talked about having to get a view that works for someone in the job they have to do, right? So if your job is fixing infrastructure, you really quickly get into seeing, like, what's going on with the system, how long has it been going on. You get this sort of glimpse on the right-hand side about whether that status is new or old. This one's been failing since we did it. So, you know, it was designed that way.

But we should find out why. Yeah, let's find out why. We're failing this one. So if I click into the error log, we can actually drill down and see what's happening with this system, and then Elliot can go fix it, right? Totally. Elliot will totally fix it. Elliot's sitting behind the screen here doing things. That's why we're talking about him.

He's a great guy. Poor Elliot. Yeah, let's clap for Elliot. One time. Okay, sorry, go on with your demo. The team has been working really hard integrating security and compliance capabilities into Chef Automate. And so with this latest release,

for the first time, you get this view, this single place where you can go to understand the state of your infrastructure as well as to understand whether or not you're adhering to your compliance policies. And so for this next bit, we want to show a little bit of that and show how our demo infrastructure is doing

with respect to security and compliance. That's right. So we did a completely new compliance view within Chef Automate. It's similar to the converge view, obviously. Like, I get a quick high-level summary of how my nodes are doing, all of my Alice's, Bob, and whatever I have running. But I also get, like, historic information. I can look into how long this has been going on,

and as you can see, it's been going on ever since we started this environment. And I can even drill down into what my most failing systems are. So you actually don't have to just look through the nodes. You can identify patterns really, really quickly. I guess this is just happening on Windows. Is it happening on my Linux systems? Is it happening to something else, like development or just the acceptance environment?

And this view is really useful when you're starting out. So you deploy compliance automation across your fleet, and you're gonna find a whole bunch of things that are not what you want them to be. Absolutely. And then you're not sure where you should start. And then you can look here or there, and you know where to start. I love that idea of being able to look

at what's most high-risk and where, right, and then being able to use that as an evaluation of what I need to do next. That's right. All right. The other thing that's great about this, do you want to show the... Yeah, so we got a second view. Remember those Friday mornings when the auditors finally come in, and they're asking you for how you're doing

on, let's say, PCI, payment card industry? And then you're shoveling for all the systems that you are running, right? You're showing them, I got 40 failed nodes, and I got 60 successful nodes, and they're standing there like, I don't care. Right, they don't care about your nodes. It's a huge number. The thing I really want to know is how I'm doing on the profiles. So how are you doing on PCI? How are you doing on all of your controls?

So we've been running this across the environment, and we can see that we have a lot of controls, which we have written for this today, and only some of them are failing. So this gives us a nice summary as well, historic information over here, as well as, well, you can see we're mostly running the Linux baseline, which is failing. Everything else is succeeding, so that's really, really nice. And we can, again, drill down into the controls

that are failing the most. Across our infrastructure, with a really fast and really awesome view. Right. All these failures in our demo already, I'm feeling judged. Yeah, I know, right? Next year, I'm going to demand no failures. It's not very DevOps-y, though. We'll have a post-mortem. It'll be super awkward.

We'll just do it on stage. I'll sit here like a judge and be like, hmm, tell me again about the timeline. Go on. Yeah. I'm not sure that having me up here was a good idea. It's just exciting. It's super fun. What are you talking about? Yeah, no, it's great.

Obviously. Yeah. These tests, right, with InSpec, one of the things that's really powerful is you can run them on a schedule, just like Chef client, so that you're getting continuous compliance. You're not just testing your infrastructure once or on some ad hoc basis. You're going to know, as soon as something changes, whether you have a problem.

And the other thing that you can do is you can put these tests, because it's compliance as code, that's InSpec for you, you can put it into your workflow. And so Carmen, in her talk with SAP NS2, was a great example of this, where she talked about how the sort of before state

was the development teams and the ops teams doing work and pushing it through and then kind of hitting this wall and this bottleneck with security and repeating the process a few times before realizing that they needed to do something different. And this technology allows just that. So when you move your compliance tests into your workflow, you're going to detect problems earlier,

and it's less expensive to fix, and you're going to enable just that kind of collaboration that Carmen talked about that powers DevSecOps. Might it become continuous? And you can do it continuously. Right. Continuously. There's a theme. All right. You guys got that? Oh, that joke did not land at all.

It's fine. Screw you guys. All right. So we've been talking about infrastructure, and we've been talking about the compliance, but again, coming back to the why. And the why is applications. And so we're going to use a little demo application, and I want to introduce that.

And what we're using, it's a Rails application, and it's called Daphne. And Daphne is an online community. It's a website for people that have type 1 diabetes, and it helps them improve their health. And we're using this app because one of our own engineers, Simon Fisher, wrote this app. So thanks, Simon.

Yay. Okay, so Rails application, Nginx is the front-end upstream proxy. It talks to a Postgres database. And the other thing I guess that's worth mentioning is for a site like this, security is really important because people are logging in

and they're sharing their personal information, they're sharing some health-related things, and so it's really critical for us that we keep them secure. So this is an opportunity where we can talk about that our compliance automation doesn't just apply to infrastructure. You can use it to assess the security of applications.

So let's take a look at that. Right, so as you can see, this site is running on SSL, HTTPS. And that's something that pretty much all of you are confronted with, at least if you're running with credit card information. The deadline has been pushed, but people are still scared of the old SSL stuff that's running in their environments. So let's take a look. We actually have a profile for this ready to go today.

We wrote an InSpec Daphne profile, especially for our Daphne app. And if we go into that, you can see that it's actually checking the SSL configuration of this application for a number of things that you should not have enabled, something like SSL 3, for instance. You should really not be running anymore.

Now, the cool thing is, do you have to write everything yourself? No, you don't. So we got you covered. If you go back here to the profiles, click to the available profiles, we have a few in there you can use. 108. What's going on? That's awesome. Yeah, we got a bit of time on our hand here. From Greenfield to Brownfield,

so you have everything in here. And you can then pick the profile and run it on your notes and run it on your apps. And if I actually go over here, I can see that Daphne is doing all right. It's all green. Wait, just all right? Or is it like, is it passing or failing? It's passing. Okay. Green thumb. Well, blue. Right, blue check marks, passing. Blue check, passing. Okay, so we've got the app in acceptance.

It's in EC2. It's running. Checked on it. Okay, that's good. And we've taken a look at our infrastructure, and that seems good. Seems great, yeah. All right. I like that it's not failing. Not failing is good. Super working. That's an important place to start. Mm-hmm. And we think it's secure.

So I think this is like, I think we're ready to kind of push this out. Push the button. To production. Yeah, let's go to production. Who wants to go to production? Give me a little round of applause. Yeah. What? What? What's going on? Oh, man. I hate you guys. I want my demos to come together.

So we've had this day, right? You've all had this day where things are going according to plan. You think you know what you're going to do for the week, and then a new vulnerability is announced, right? You learn about whether it was Heartbleed or Shell Shock or most recently WannaCry, and you know that you now have this new thing you've got to do.

You've got to figure out whether you're impacted. You've got to know how you're going to test whether what systems are affected and then figure out a plan of prioritizing how you fix it to get yourself safe and protect your customers, right? And what's possible when you've laid the groundwork

with compliance automation and infrastructure automation is to address that problem in a really different way, which we get to kind of demonstrate for you. But first we should tell you, I mean, we had this. That was our vulnerability alarm. You guys have one of those? Everybody does. Right. Yeah, we got a new vulnerability called

Camellia Unterschlichmalis. Yeah. That's a European thing. I mean, and before all of you start tweeting, Camellia's actually fine. It's a really nice cipher in the SSL suit, but just for the purposes of today, we have made it break. It's super broken now, just in this room. Also, if ever somebody else breaks this, dibs on the logo.

Also, everybody in the world will have to learn to pronounce Unterschlicht, which I didn't. Unterschlicht. Yeah, see, I didn't do it right. Let's do it together. Super American. All right, so should we write a control for this? Yeah, so we are going to use InSpec, and what Dominic is going to do is edit our profile.

So we have a profile that is testing our demo application. He's going to pull up an editor. I think this is the most risky part of the demo, because what editor is Dominic going to use? Because, so who wants Dominic to use VI? Who wants Dominic to use Emacs? Boo.

So this is how much power I have over the chef for me. There was, like, four Emacs people, and they were like, oh, come on. And I'm like, no, no, you're just wrong. And that's why you're my people and not someone else's. You're mine. It's fine. Yeah, it's fine. All right, so I got the profile in here. We have an InSpec profile ready to go. Also, because I, you know, if you're on stage

and you're typing, your typing speed goes down by half, and you make a lot more errors. So let's just do this. So Dominic prepared a commit, and he's got the control. Oh, he skipped the editor thing. Oh, there we go. Oh, there we go. Let's look for the Camellia control. It is here. We have written a control, give it a nice little title and impact.

We check whether, you know, we're running it on all SSL ports. And then we're just looking for the cipher that's running Camellia down here. And if any node is running that cipher, we're going to, well, not boop the horn, but we're going to just throw an error. I mean, what's so neat about InSpec here is just with so little code, how powerful it is, right?

So with just like that line, it's checking the whole machine. It's going to look at the ports and determine whether SSL is listening and determine whether the cipher is there. It's very compact, fairly easy to read, really powerful. It's really fun to see. Right. So let's archive that up, create the profile in here.

I have a bunch of warnings which we're going to ignore. I know what I'm doing. Safety instructions included. You get to do that when you wrote the software, you know what I mean? You get to be like, yeah, yeah, yeah, yeah, yeah. We'll clean it up. I know this stuff. You don't even know how many of those are there. We're going to go over here, I'll put the new profile. So Dominic's going to upload this profile.

We've added a new control to the profile that tests our application and our infrastructure. He's going to upload it. And when he does so, Chef Automate is going to take over. And the applications and the infrastructure that are subscribed and attached to that profile are going to get retested. And so in just a few minutes, we're going to know whether we're impacted by Camelia Unterschlik.

Nice job. That was awesome. Yeah, I mean, what I think is great about this is that idea of continuous compliance. So simply by updating the profile, everything that needs to be checked gets checked, right? And I just want to like just take a minute here with us as a group and think about how cool that is,

that you didn't have to do anything. There's nothing to trigger, right? You didn't need to go target a thing. Like, it just happened. It's pretty cool. That's right. And if I go to the note state again, the profile has already run. It's really, really fast. The way that we do these tests are running really quickly. And on Daphne, you can now see that we have it failing. If I go to Scan Results, I can open that SSL profile.

And up here, I mean, this is no accident. We have Camelia on top. And you can see that it's failing with a bunch of ciphers that should not be enabled. Yeah, cool. What are we gonna do, though? And we can notify the application team as well. Elliot, yeah. Have that, so, yeah. Hey, Elliot, you can't hear us,

but I think you need a notification. Right, so let's go over. Let's see how the team is doing. We actually got a bunch of notifications in here. Some of them are for the operating system, but we also have a notification for the failure, which we have just been getting, which is now buried in all the operating system notifications. But it informed me that something is going wrong,

that I should be looking at this control, and then hopefully let somebody fix it. Yeah, so look. We went from learning about a new vulnerability... Right. Did you want to try the underscore pronunciation? No, no, I'm good with it. Okay, just leaving you the opportunity.

We learned about a new vulnerability. We created an automated way to test for it, and we applied that test, and we were able to assess our infrastructure and do that all in just a few minutes. And that's really the power of continuous compliance and continuous infrastructure. That's right. But we're not done,

because now we have to fix it, right? We did that scan, and we found out that our demo application is, in fact, vulnerable. So we have a couple of choices. So the vulnerability is in this cipher that is made available by default in OpenSSL. And so one thing that we could do is we could change our configuration of Nginx, our front-end proxy,

and disable the cipher in that spot. Yeah, but that's no fun. Like, I would have to do it in Nginx, Apache, some weird old Java apps that we were running. Yeah, we might forget. It would be a lot of work. Right, the problem with it is that we have to change more applications, and we have to worry also about the new applications we might write,

and we'd have to remember to update the configuration there as well. That would be a bummer. It would. Yeah, you're gonna forget. You couldn't get my demo to not fail, so there's no way you're gonna remember to disable Camilla. Yeah. It's not your fault, though. It's cool. Don't laugh. None of you would do it either.

So what we can do instead is we can patch OpenSSL and sort of fix the problem at the source there and disable the cipher in that spot. And if we do that, then the fix is applied to everything that's using that. So that's simpler, and that feels more correct, so we like that.

Oh, great. The downside, though... What's that? We should do that. All right, let's do that. The downside, though, is that now we have to identify all of the software that depends on OpenSSL, and we have to be able to rebuild it and redeploy it and verify it, because when you change the dependencies of your software, you need to do those things.

That's a core thing you have to do, rebuild, and you have to be able to validate that when you've deployed it that you haven't broken it, because you want to know. Right, because you probably did. It's a bummer when things break, and sometimes they do. And so you can see, like, right, sometimes those dependencies are hard,

and if you don't have complete automation, that's an even harder problem, and you can be spending a lot of time and effort to do this. So what would be really great, what I would love to have, is a system that could help us by automatically rebuilding our software for us,

detecting when a dependency like OpenSSL has been rebuilt and has a critical update, and rebuild all of the things that depend on it, and then make it really easy to deploy and revalidate those. Boy, who built a system like that? Do we even have something like that? Does that exist in the world? I don't think so. Oh, my gosh. I think we're at ChefConf. Can anybody guess what it was?

Yeah. Okay, show us. Right. So here's the thing. We built just such a system, and it's Habitat, and Habitat's build service is going to do exactly that. Show me. Yeah. So Dominic is showing us the depot. Yeah, so we got the new build service live.

I can go over here to the depot. We've got the OpenSSL for this demo ready, so the OpenSSL CC demo, ChefConf demo, and it's already been building the latest release under the covers, and as you go in here, you can actually take that latest build, and you can see that it was actually going through

all the steps to build a complete SSL package with everything included for you, and in actuality, you should have seen the logs, and it was so fast that it completed already, so apparently you can build it. One of my favorite things about this idea is that, how many people here have to maintain build slaves for Jenkins? Keeping the software up to date to build your software is super hard,

and one of my favorite things about Habitat is that when you describe how to build your software, you don't have to do that anymore. You can just make a call to this one simple thing that will bring the entire build environment along for the ride, and you never have to build another build node, which is cool. You want to hit another build just for fun? Sure, let's go hit the build again. So I'm going to go back here, and just so we can see this,

in the OpenSSL ChefConf demo app, I can request a new build, and in a few seconds, you're going to see how the build is started in the backend, and that I can actually... Oops, did I click it? I think I did. So while Dominic is demonstrating that part,

just a few basics on this build service, right? What does the build service do? It builds your software. It takes your application code, along with a small configuration file, that's the plan for Habitat, you submit that to the build service, the build service takes that and builds your software, creates a Habitat package, and puts that package in the depot, Habitat's a depot.

But what's neat about this service is that it's smart, and it understands all of the dependencies of your software, and it keeps track of that, so that when it builds a given package, it knows about all of the other packages that depend on it, and it can schedule, then, the rebuild of all of those things that depend on it.

So here's a little animation of what that looks like, right? We rebuild one package, and then we find all of the things that depend on it, and we rebuild those, and then those things might have their own dependencies, and we rebuild those until everything is rebuilt, but in an automated way that you don't have to deal with. And this capability is really powerful because you have this problem

for any technology that you're using. You have this problem if you're doing Rails or Node or Java, and here's a way to solve it in a consistent way with Habitat. Yeah, being able to just have that moment where there's that vulnerability, and then you come into work the next day, and rather than learning about the vulnerability and going through this whole process,

if we can just have the software built for you and show you, when you come in, that we rebuilt it because there was a vulnerability in OpenSSL, and then we've deployed it into acceptance, and then InSpec has validated that it's now safe and secure while you're drinking coffee, and all you have to do is decide to promote it. That's the future of the enterprise that I want to see. That's the human experience that I want.

And one of the software stacks, of course, that we are using is Nginx. As Seth was saying before, we could have gone in and reconfigured Nginx, but actually behind the covers, this rebuild, as a result of OpenSSL rebuilding, we got a completely new Nginx package as well, which depends on SSL, and it has all the updated configuration already included.

Yeah. All right, so, summing up kind of what does this mean, right? When you have this kind of service, you go from a world where you get a notification that your software is vulnerable, there's a new vulnerability, and that you need to spend your day fixing it and chasing down those dependencies. And what this service and what Habitat makes possible

is that you can get a different kind of notification. Instead, you can get informed that, yes, there was a critical vulnerability in software you depend on, but, hey, we rebuilt it for you. We redeployed it into an acceptance environment. You're ready to go, and you can have a better day. Super cool.

So did we show, then, that the app got deployed? Like, are we secure? Well, we can still deploy the app if you want to. We should. We should. Let's get it running. All right. Shall we use... I mean, I heard about containers. They seem to be hot shit at the moment. Oh, sure. Yeah.

Should we deploy it again on containers instead of on AWS? You guys want to see some container love? A little Kubernetes action? Kelsey's in the audience. Kelsey wants to see it on Kubernetes. Let's do it. Kubernetes. All right. Cool. So, look, there we go. Habitat is really the fastest way to take your application

and get it into the cloud and get it into containers. And so what we'll show you, the demo's been running in EC2 on AWS, and what we're going to show you is what it takes to take what we've done and move it into Google's cloud platform. And the bulk of that effort happens, in fact,

with just a single command. Once you've packaged your app with Habitat, it's one command to get a complete Docker container image that has all of your dependencies, everything you need to run and manage the application. That's right. And you get all of the benefits of the rebuild of Habitat's build service

and the traceability of all of that single command had package export, and it's that easy. That I've just been running on here. So you can see the export going on. This is exporting the Habitat package live to Docker, and the only thing that I really needed to do is to run this one command. That's how easy it was.

And so then the next steps, we need to give a special tag to the resulting image, and we'll do this little cooking show style. So we've already built an image. We can let that run, and we'll tag an image. We have to upload it, so we haven't solved magical transportation of bits yet. Cool.

Yeah, we upload it. Push it up to Docker. So that's uploading to Google's private registry. And then the last step is we can start things running. And there it is. We have tagged the image, so we see that the image has been built. We have tagged it in the second step. The last step is we are pushing it up. Obviously, this is a bit of cooking show, so the image is already there.

And now I can actually, kubectl, run that image in my Google Cloud. So I can just hit this one command. Then within a few moments, it has that thing running and deployed. So let's open the proxy, the kubectl proxy, and go to our web server again, and let's open it up to our Kubernetes UI,

and as you can see here, we have got Daphne Online running live that we have just created. So cool. Yeah, right? You can see it from the 11 seconds, by the way. I'm not faking this.

So what does it take, right? We've seen these great advantages that you get when you have your application packaged in Habitat. You've seen the build service and what that can do in terms of dependency management, and you've seen just how easy it is to take your app and put it into containers or move it into a container runtime system with Habitat. But is it hard?

Is it hard to take an app, especially an existing Rails app like this Daphne one that was written before Habitat even existed? What does it take? Well, it turns out what I'm showing you are the six lines of configuration that we needed to package it in Habitat. So we're putting a lot of effort into making it really easy to get started with, and that's both for new applications but also for ones you've already written.

Yeah. Six lines. Come on. That's awesome. So good. Okay, so we've seen some infrastructure. We've seen Chef automate with infrastructure and compliance automation, and we did some InSpec, and we had a vulnerability,

and we fixed the vulnerability. Did we fix the vulnerability? Let's check. Let's check. Expand the profile. See the running profile. 31 controls. Camellia is now out. By the way, we also fixed a couple of the other issues. We wanted to make this more impressive. Nice. A little extra work. Nice work. Thank you. Cool. So we kind of wrapped that arc of our demo,

but there's sort of one more thing that I want to share with you all while we have a couple more minutes. You know, Adam talked about the horse and what it means to be a great enterprise

is to be able to guide that galloping horse of technology. And that what you need to be able to do is to identify the right abstractions and not get too pulled into the implementation details. And what's really exciting for me about what I see in Habitat

and the direction that we're going is that it gives you some of that abstraction, and it's going to allow us to build more on top of that. I kind of think of what we're doing with Habitat as our space program where we're doing this neat stuff out there, and then we're bringing back that technology and innovation and applying that to our infrastructure and compliance automation.

And so what's that going to look like? We have some stuff that we're still working on. So this is... we're kind of sharing, like, a prototype. This is legitimate, pure prototypes. We've put a lot of effort in the last couple years into getting better at UX and better at product design. And so one of the things we've been doing is trying to show our designs to real users to get feedback.

And we've been showing people this design, and the feedback was really good, and I get super excited about it, and so I was like, we got to show it in the demo. And they were like, but it's not real. And I was like, I don't care. And so here we are, and now you have to watch a demo that isn't real, and you can't have it yet, but look at how cool it's going to be. Just go with me.

Yeah, we're going on a little spacewalk looking at some new features, and what's going to be possible is bringing an application-centric view into Chef Automate for managing Habitat applications. And what that gives you is it gives you the unit of management is the application, and you can think about it in those terms.

So if we kind of scroll to the top, we have our Daphne application. We've got it in development and acceptance and production, and this application is our user-facing application. We can drill into it. So let's look into development, and then you can... Like, this is the other thing that you want.

You want to think about how your application is comprised of services, and you want to see those services. So here we have our Rails app, and we have Postgres and Nginx, and for our prototype, we added in some Elasticsearch and get that overview in this way. The other thing that you're seeing, though,

is a codification of some of these common behaviors, right? Adam talked about the behaviors. Like, what are the things you always want to do? You always want a health check. You want a smoke test and, of course, compliance automation. And you want to do those things regardless of the technology that your application is written in and regardless of where you're deploying. So if you're deploying...

Like, because we live in a hybrid world, and so you're going to have some apps that are on-prem, that are in the cloud, that are in container runtimes, but you still want to be able to manage them like this and make sure that these things are happening. And so that's what this makes possible. If we take a look at our acceptance environment, we've got everything is passing and happy there.

And so the sort of last thing that we'll show is when you've packaged with Habitat, the Habitat system is able to take care of the complexity in terms of upgrading and deployment and all of that coordination, and the Habitat supervisor is doing that work for you. And so that means that moving an application and moving changes from one environment,

such as acceptance, to production is as simple as a channel promotion in Habitat's package depot. And what I think is cool about this is you can just hit that with an API. So whatever the thing is you use to drive your infrastructure, you can go ahead and make that call into Habitat, and it will do that channel promotion, and then you'll be able to see the impacts of that here.

So if it's chat ops, if it's Jenkins, it doesn't matter where it is. What we're going to show you is the status of what happened. Yeah. So I just hit the promote button, and as you can see, it all moved from acceptance to production. Right. All right, well, so there's the sneak peek of what's coming in terms of bringing application-centric view into Chef Automate and what's possible with Habitat,

and you should check out the build service, and for sure, Habitat. There's some really great stuff there. Thank you. Thank you so much. Thank you guys so much for running such an awesome demo, for letting us sort of hackle you just a little bit. Thanks a lot.