Hi, my name is Maddie Stratton and I'm a staff developer advocate here at Pulumi, and I am so excited to be a part of Devsecops here at Conf 42. We're going to take a little bit to talk about the journey from DevOps to cloud engineering, and I appreciate you taking a little time to walk down this path and maybe see how things might have changed over the years. And with that in mind, before we talk about anything new, I want to talk a little, but by looking back, let's take a little bit of a journey to see how we got to where we are. And maybe that'll help inform what we could do differently if we kind of think back at velocity 2009, Paul Hammond and John Allspa gave a talk called ten deploys a day DevOps ops cooperation at Flickr. And this was granted 2009. This was fairly revolutionary and as best we understand it, from unearthing the Arcana, this tweet from Andrew Clay Schaefer, who Andrew was watching this talk is the first known use of the term DevOps. Is that important? Probably not, except that it kind of came, but of this talk. And likewise, what also happened in 2009, 2009 was a pretty big year for all this stuff in 2009 was also when Dave Farley and Judge Humble published the book continuous Delivery, which is still users today when we talk about these things. So that was 2009. And then also, finally, Gary Groover published the practices approach to large scale agile development. This book also came out in 2009, and there was a book about DevOps. They just didn't call it that. And so 2009 was really an inflection point. Another thing that happened in 2009 at that velocity conference, after seeing Paul and John's talk about Flickr, Andrew Schaefer, who tweeted that he proposed a birds of a feather session to say, like we talk about agile system administration. And one person came to that birds of a feather session, not including Andrew. And that person was a guy named Patrick Dubois. And later on, Patrick and Andrew connected and they created an event in Ghent in Belgium called DevOps Days. And the reason that it was called DevOps Days is agile system administration was too long a name for a conference. So if you want to know why we call it DevOps, that's really why. But I think it was kind of exciting when we think about this first DevOps days, it took place in Ghent. If we take a look at some of the talks that were given there, those could take place at this conference today. So weve been talking about the same stuff for a while. The other thing that when we've looked at how there's been this growth in the DevOps community, and so much of it comes from these types of community events, and DevOps comes from the practitioners, from the people that do that, one thing I think is really interesting is in 2019, to celebrate the 10th anniversary of the first DevOps days, we did a DevOps Days in Ghent. And the day before we had a day Zero was an organizer day, where people who organized DevOps days all over the world came together to have a little unconference to learn from each other. So the reason I bring this up is there weve more people attending that organizer day than attended the very first DevOps days in 2009. So the movement has really grown, and we can see that over the years. And why do I bring this up? Why am I talking about DevOps days? It's not just because I'm the global chair of DevOps Days, and I think it's a pretty great conference, but it's about these communities, right? These ideas that we think about when we think about DevOps, they came from the practitioners. Now talking about ideas, we, of course, should talk about definitions, because that's fun. So Donovan Brown at Microsoft has defined DevOps as the union of people, process and products to enable continuous delivery of value to our end users. And I kind of am into this definition and this explanation of it. And again, the reason we're talking about definitions is I want to kind of get us on the same page. So you know where I'm coming from. And we're talking in a context when we talk about where everything went terribly, terribly wrong. But yeah, DevOps is about the people, the process, and the products. It's a bunch of, you know, put, put Andrew in a corner a couple years ago and said, andrew, I need you to give me a definition of DevOps. Andrew is the one who first tweeted about it and has done a lot of other things, but under duress. This was the definition Andrew gave me. And you see that software and human are equivalent in this, which I think is really, really key. And of know, I asked Twitter, what is DevOps? Not because if we know what something isn't, maybe we can reason about what it is. Hard to say, hard to say. But one thing that's been fairly commonly accepted when we talk about DevOps is this idea of columns. You might have heard of this before, and this is an acronym. This is simply representing some of the principles that we think about with DevOps. And it's comms and stands for culture, automation, lean measurement and sharing. Now, the order of the letters is not significant other than it spells a word. So if you want to call it clams, you could, or smolk. But we all sort of say columns. The reason I say the order doesn't matter is every one of these things is equally important. And I'm going to break these apart a little bit and talk about them in the modern thought around cloud engineering. So I want to dig into them just for a second so we know what we're talking about and how we compare these tenants. So when we think about culture, this is sometimes maybe shortcut is the squishy people stuff, but really it's about how your organization or how your team operates and how your humans interact. And the thing to remember about this is, like Lloyd Taylor said, is you can't directly change culture, but you can change behavior. And behavior becomes a culture. Your culture is really an expression of the behaviors, and those behaviors come from incentives, among other things. So you can't just sort of sit down as a leader, as a CIO and say, I'm going to change the culture. This is now our culture, right? You have to influence the behaviors, and the behaviors are expressed as the culture. When we think about those things and then automation, this is the one that everybody knows, right? When we think about DevOps, we think about automation tools and process automation and configuration management and all that fun stuff. And the reason that this matters though, besides that, it's fun for some, value of the word fun is, as Jez and David said, in continuous delivery. He said, if you ask experts to do boring and repetitive but technically demanding tasks, this is the surest way to get it screwed up, short of depriving them of sleep. So what we're trying to do here, again, to move at the velocity that we need to, we need to be redirecting our focus on the things that require our creativity and our human adaptive capacity versus things that can be automated. But automation isn't all of it. It's one of five things. And then we talk about lean. This was introduced first when we talked about in 2010, and John Willis and Damon Edwards first came up with Cams. And then Jez Humble proposed shortly thereafter to add l for lean. When we think about kind of lean manufacturing principles, and understandably, this is not a one to one match, right? You can't run your software organization the same way that you run an automotive plant. But there are some ideas that come from the lean movement that are really interesting to us. And one especially there's several that come in because lean is about reducing waste, right? So one of the things that we talk about in lean is this idea of a value stream map, right? And thinking about the value stream. And so if we think about that in a tech standpoint, maybe it's from idea to getting in front of a user, or as John Willis would say, commit the cycle from commit to cash. We talk about cycle times. This is all part of that value stream, but it's all the parts that go into that. And this is not a whole talk about value stream mapping. Steve Pereira, who's at Steve elsewhere on Twitter, has great content about value stream mapping, and I'll be dropping some resource links in the resources for this presentation at the end too, if you want to learn more about that. But that's really when we're thinking about how are we looking at ways that we can reduce waste in the process and look at the entire gestalt of everything and see where these things happen. And then we think about measurement. Measuring is really, really key because if we're talking about continuous improvement, how do we know that we're improving? And oftentimes when we think about the measures in this perspective, it's not that there's a certain number. So this is where we kind of think about things like okrs and v two moms and KPIs and stuff. That's not necessarily the be all and end all of measurement. It can also just be, is the needle moving? And is that interesting? They're not necessarily goals or targets to hit, but they're just ways for us to get an understanding both from pure performance of the technology part, but also how are we actually doing with stuff? And then finally, the s stands for sharing. And this has a lot to do with just a matter of getting both. As far as sharing information in a lot of kind of pathological or bureaucratic organizations versus performant ones, there's a lot of information hoarding, because either it can be when I have this information and someone else doesn't, then that protects my value. There's also, at a senior level of management, this common idea of need to know. The reality is, what needs to be kept from people from need to know is usually a lot smaller than you think, but it's kind of a form of risk aversion. But the reality is that the more information we have, the better we can do our jobs. But also sharing is not just about that. Sharing is also sharing practices and information. One really interesting thing when we think about post incident reviews, so when J Paul Reed did his thesis on how post mortems are done in large. Actually, one thing he found that I thought was really interesting is the larger the organization, the less likely teams were to share the results of their post incident reviews outside of their team, which perhaps ironically, the larger the organization, the more necessary because of interdependencies. So there's a lot of work we can do on sharing. Okay, so these sound like some like, okay, you're like, this is cool. This is like a revolution. This is like a cool way to not be jerks to each other maybe, and move the needle and really be effective and drive all this stuff. And these were the principles that weve been talking about in the DevOps movement since 2010, right? That's calms came out in 2010. And even if you look in 2009, these ideas were all there. Weve been talking about this for well nigh twelve years at this point. Right. But we've been doing a lot of talking. But what happened, that doesn't sound like what is happening in the discord is actually going on these days. Right? So we kind of have this thing where it's like it's all about automation. When you talk about DevOps or DevOps teams and DevOps engineers, they're automation engineers. And by the way, I have long since stopped fighting about and being, you're not going to get me sitting here saying that, don't call yourself a DevOps engineer or anything like that, because you know what? I'll tell you two reasons why I don't fight that fight. Number one, most of the people who have the title DevOps engineer didn't give that title themselves. So if I'm out here on Twitter talking crap about people with the title DevOps engineer, the only person that's hurting is the people with those titles and not the people who came up with them. So I don't do that. And number two, the title DevOps engineer gets you 20% to 30% more money. So go get paid. I'm all for it. But that said, we've gotten into this thing where DevOps means automation. DevOps is scripting, DevOps is template DevOps. And remember, the a is just part of, that's one of five, that's maybe one fifth of DevOps. But it's really become about automation, right? Or it's about Kubernetes, right? Someone actually, I saw a tweet the other day that said, are there any conferences that aren't just talks about kubernetes? And yes, there are, but DevOps all the things is not container orchestrating all the things, or Kubernetes all the things. But you might feel like that's where DevOps equals kubernetes quite often is where we go, or thankfully, this is kind of fall off a little bit that it's not about culture. Years ago, there was a very short lived movement for enterprise DevOps. And one of the kind of loudest voices in that movement used to say the culture part of DevOps didn't apply to the enterprise. That, quote, culture was for yogurt. We know this to not be true, but there still is this thing where it's like, well, DevOps is the engineering part. There's no people parts of this. It's not about how we do the work. And I kind of have some bad news for you, right, which is DevOps is being sold to you. That's where we are right now. And as someone has said before, you can buy DevOps, but I can definitely sell it to you by that. That was me. I'm the one that said that. But I feel like I've reached the point that I can quote myself in my own talks. I think I get some kind of cloud leader badge for that. I'll check on that later. But that's the thing. We're trying to do a little better though, right? So we're like, all right, we had DevOps, we kind of talked about DevOps, and this is about the wall of confusion, all this stuff. But then we got devsecops. Now we're talking about, I mean, this is the Devsecops event. So is that portmanteau a little better? We got security shoved in there now, but that's not. We have to be more inclusive. What about the business? Everybody is part of the business, our business goal. So do we have biz DevOps? But wait. But then we took security up and, oh, you know what? We need some serverless DevOps because we do DevOps differently when serverless is involved. Or maybe let's make sure we really have a big tent. We've got our devsec DB ops ops because our DB ops people are different than our other ops people. It's a different kind of ops thing. I don't know. And then of course, we have to DevOps our DevOps. That's the thing. Like what? First of all, I love DevOps and the name is great, but it's really unfortunate because we feel like we need to express everything through it. And what this goes to illustrate, if there's nothing else, now that we're kind of gone through this history. What have we learned here is that words are hard because we're trying to express an idea using a short amount of time. So nuance gets lost in these words. But don't worry, I have more words for you because that will certainly help. And what I want to talk about now for the next little bit is this idea of cloud engineering and cloud engineering. One of the ways to think about this is it's employing standard software engineering practices across, whether it's your infrastructure, it's your app, Dev, it's your compliance. And this sounds familiar, maybe, right? This sound a little bit like DevOps, like software engineers years from web ops people and security people learn from software engineers. And it sounds familiar, right? Weren't we trying to say this before it became all this other stuff? Because in this sort of cloud first world, right, we compose our things out of cloud resources of some kind, right? And we build infrastructure platforms upon them. And that's where we throw our applications. Maybe we don't throw them, we deploy them. That's nicer than throwing things. And then we have to keep them running with our policies or our uppercase or lowercase compliance, right? The things that we expect. And this is looking pretty familiar. So when we kind of break these things down, when I sort of talk, but these, from DevOps to cloud engineering, building the deploying and managing are sort of three ways I like to slice them up, right? So if we think about build. So build sort of might sound like this is just the writing code part of all of this, but it's about creating the services and infrastructure that provide, well, really what our customers and our constituents and our users need. And like I said, we use cloud resources to build these applications, then the services and the infrastructure, maybe that's a shared services platform. So you have a single consistent experience across multiple teams. Again, it depends on who you are, right? And sort of when we think about what these are, we talked about maybe this is composed of shared services platforms. When we think about reusable infrastructure components, especially when we think about where you're not recreating the whole thing and it's not as simple as just Ruby's dry thing, don't repeat yourself. But about having something that's, that's sort of understood by a domain expert and then that's able to be reused, it's building blocks. Hey, this is like how software works, right? So why can't we do that with our infrastructure too? It kind of works. And then we can leverage the ecosystem around those frameworks and tools. So that's one of the advantages. If you're thinking about tooling that's using common programming language, that maybe you're writing this stuff in typescript instead of a bespoke DSL or something like that, you have all of the ecosystem of go or python or whatever language that stuff is in, from ides to testing tools to just common practices. So a lot of this is about sharing and stuff, right? Okay. So what I'm going to do here is kind of take this build id. I'm going to do this for each of our build and deploy and manage and apply how each of the tenets of columns might apply to that and see how we can kind of do the layering, right? Like how do these connect, use that common language. So if we think about the culture part around build, this is where we talk about focusing on our differentiator, right? When we're using reusable shared things, whether they're shared within our organization or shared with the ecosystem, our organization, our company, we have a thing that makes us different, right? And I got news for you. Unless you are like Circle CI or GitLab or GitHub or someone, it's not that you're super good at building pipelines, right? I used to do some work where I had customers that were in North America, in the public sector, in the US, and I used to say like, are you the US department of continuous delivery? No, that's not what you do. Right. So we want to focus on the differentiator, right? And then the culture part is a common development experience. So not only, it doesn't mean that every single team in your whole organization is using the exact same thing, but it does help with that. Empathy across when we're having similar experiences drives the empathy, right? So when an automation perspective, these are things like reusable components help us automate and rebuild. And this, again, we're leveraging that ecosystem and all the automation that already exists within that. We don't have to build new stuff. And this is helping avoid bespoke implementations, right? How many times you get somewhere and you're like, well, let me take three months to figure out how we do things here versus like, oh, this is common within the existing industry or even within my organization when we think about the principles of lean, right? Again, we're focusing on value in this idea, those differentiators. It does help with efficiency, as a loaded word. It helps with sort of a waste reduction. But also when we think about continuous improvement as part of that, it becomes part of our cycle of how we're building these services and saying where is this kind of coming in from a measurement perspective is consistency breeds visibility. And this is a common theme you're going to see repeated throughout the rest of this talk is when we're doing things in a similar way, doesn't mean the same way for everything, but when we're doing things consistently, we have visibility into where they might differ, and then what needs to be changed. And then from the sharing perspective, literally the reusable components. Right? So if I have libraries, I have things like that can reuse. And just the ecosystem promotes sharing outside, which is again, that rising tide raises all boats. And we can learn from existing practices both within the larger ecosystem, but also just within other parts of our organization. Hit the wrong arrow key. Sorry about that. Okay, let's talk about the deploy part, right? I mean, it doesn't count until it's in production. That's for real, right? Our code and our infrastructure don't really give any value until they're in front of our customers and users. But we want to do this quality constant and highly efficient. If it takes us too long or too many manual steps, we don't have the velocity to get new features to our customers or also restore service when this happens. So the thing is, when we apply software engineering practices to our deployment process, we can ensure that we ship the same way every time. And it's pretty common. We talk continuous delivery came out in 2009. Continuous integration and continuous delivery practices applied to our application software is fairly common practices now. But we can use those same principles with our infrastructure. So that means that new and changed infrastructure resources, they can meet our quality controls and we can track and understand, especially when we're sort of chasing down that what changed problem, right? And the value of automation, our deployment, it's not just about providing tests that make sure that we do the steps the same way every time. Regardless of how experienced you are, every one of us is capable of missing a step or making an error. It's just possible it can happen, right? And so then we think about checklists, and I'm going to talk about checklists a bit. But the great thing about checklists, when I love checklists, is they're even better when a human defines them and they're run by software. The power of a checklist is defining the steps, not they're actually running it. So the automation can express our checklists in code, code that can be tested, reviewed and managed. When we kind of think about these ideas, right? We said it's the same way every time. I mean, every time. Here's sort of a clue. Like if you have an emergency brake glass. Oh my God. We don't follow the process when there's an emergency. There's two things that tells me. Number one is that your process is too slow. And number two, it means everything is now an emergency. And we have quality and security checks. So security is just another aspect of quality when this comes in. And again, like I said, let's automate those checklists. So, if we think about how the deploy pieces apply to the ideas of columns. So from a culture perspective, having this idea right, it doesn't count unless it's in prod. Like we want to ship, and we want to ship frequently, so that we can get information. And we are looking at this as small batches of changes. And this iterative development idea, we are not doing these big bang releases because it's much, much harder to understand not only what changed if something is going wrong, but if something is going right, why did that something start going right? Iteration helps us with that which enables for our continuous improvement, employment improvement. Cool. All right, so when we think about the automation side of that, right, we think about these CI CD pipelines. It means we're putting everything through some pipeline. It doesn't have to be an elaborate pipeline. Your first pipelines can be, they run no tests. That's the way it's giving us kind of our glide path and our muscle memory to, that's how we make changes. And then we can start layering these automated checks into there where these come in. And checklists are great. I love mia checklist. So let's automate them, right? Don't automate their creation. That requires the human creativity and expertise. But you don't have to tick all the boxes yourself. The robots can do that. So these ideas around deployment, these are enabling that fast. The way we think about it in cloud engineering, this is enabling fast feedback, which helps us see what's happening in our value stream, right? And it's giving visibility into that entire supply chain of where all these places go. And we can find those bottlenecks. So, if we think about the idea around theory of constraints, the theory of constraints says that any optimization we make in a process that is not the largest bottleneck will actually make things worse. So we need to know where those bottlenecks are. And again, from a measure, it's that visibility, right? So we're seeing more things, more information is exposed to us that we are then capturing. We can think about that cycle time, that value stream, and it gives us something to understand. Again, there's no magic number. Just because the cycle time at this organization is this doesn't mean that's what's right for you, but you need to know what's right for you and are you hitting it. And again, it's not just about speed, right? It's about the effective velocity. And from the sharing perspective, right, it's information that is being shared. If we have, weve sharing a common approach to our pipelines. From a shape perspective, weve doing less duplicate work and it just makes it so much easier. What changed? Because you never know who needs to touch a thing, right? Or who might be being involved in an incident or something like that. So it's giving us that understanding of like here's what happened here. And finally the final sort of tenant or phase, or I don't really want to call it a phase. Part of cloud engineering is manage, right? So we can get our stuff into production and in front of people. But that's not the end. Our customers are constantly using our services and applications and we have to manage these resources when they're in use. And from a managed perspective, it's just sort of making sure that everything is happening the way we expect it to or that we require. And as it applies to our applications and services, the visibility across all of our infrastructure allows everyone on our team, regardless of their role, to have a common understanding of what's going on. So I'm sure something that, I mean, we're here at Devsecops, I'm sure you've all heard security is everyone's job. Well, it's easy to say what that means in the world of cloud engineering is that we consider security and compliance. And I talk about lowercase and uppercase compliance, so uppercase is regulatory policies and lowercase is your organizational policies. But we consider security and compliance to be closely integrated into our work. Said before, security is just another aspect of quality. So if we treat our policy as code, just like we treat infrastructure as code, our infrastructure as software, this is a powerful idea because if we express them as code rather than prose in a document, then we can apply these policy checks both before and after we deploy our services and our infrastructure. This also kind of extends that common vocabulary for collaboration across the teams, regardless of where you sit in the chart. The other thing that I like to think about from a managed perspective is that we need controls in place to allow who can make changes and what they can change. I mean, you're like, yeah, maddie, I know, right? But why? Okay, it's not just playing defense, because we trust our team members to want to do the right thing, but we need guardrails and controls to ensure that they are set up to do so. And this means we need visibility into all the changes that occur, treating our infrastructure just like we do our source code in version control. Thinking about versioning our actual infrastructure, not just versioning the code that deploys our infrastructure. And the thing about having capability, intentionality around fine grained access controls actually helps make our team members more successful because they have more faith and more trust. Right? So again, we think about the visibility, security being everyone's job. I love thinking about a common vocabulary because all of that stuff drives empathy. And the controls and processes enable and enhance, not just protect, right? So taking us through the last run through columns here, from a manage perspective, using common code, common principles around this really enables collaboration across your, whether it's software development, whether it's operations, whether it's compliance, information security, devsecops, whoever, we're all collaborating in a way that gets us consistent. And again, remember, guardrails actually enable confidence. And this increases a common understanding across disciplines, which is really what the empathy part that we talk about so much in culture of DevOps is. That's really what we mean is just have a common understanding, see where everyone's coming from and what their context is. Right? Sharing context. Here's the thing about the automation part of all this. Computers can't lie, right? Tell me how many audits I've been a part of as a sysadmin for several decades, where the audit was, they asked me questions. They're like, maddie, every time you deployed this software, did you do x, y, and z? I'm like, sure I did. Why not? You're just trusting me, not saying that I would lie on purpose. I might misremember. But the other thing, again, the gates put in place that are automated, can't get it. Come on, just this one time. Do me a favor. My boss is on my back, right? And then the process and checks in there enable that trust. And our policy goes from vague to understandable, right? Instead of it just sort of being, well, what did you remember we talked about how words are hard? Okay. All right, cool. So from a lean perspective, this helps us determine what improvements we need to make to help increase our safety. And then we're expressing these value stream changes in code so we see what's going on with them. From a measurement perspective, this gives us visibility into current policy. I've heard that infrastructure is code is executable documentation policy as code is executable documentation of your policy. So it's much, much easier. It's not like, okay, well, this is referenced in subsection five, stroke z of this PDF on this sharepoint that you don't have access to or whatever. It's like, it's right there. Cool. And it lets us get an instant view of our current state of compliance. This is really important. It helps us see when our policy and value collide. And it doesn't mean that value always trumps policy or vice versa, but we want to know when that's happening so we can make an appropriate decision. And finally, the sharing just comes from that shared vocabulary and also being able to utilize success patterns wherever those might lie and then sharing that learning. Right? So when things happen, we're going to learn something from it. We want to be able to share that within our organization for people that might not have been directly involved in the learning opportunity. So when we think about what DevOps started as and what maybe still a lot of people hope and dream that it will continue to be. But compared to what it is, when we think about that, we think about these ideas of cloud engineering, this is my ask to you, which is, let's take DevOps back. Let's make it what it's always supposed to have been about. We all are clamoring for this, and maybe we'll call it cloud engineering this time away. Either way, what I want to make sure we focus on is getting back to these core principles. That is my challenge to you. It's been my real pleasure to be a part of this event. You can find me on Twitter at Matt Stratton. All these slides and supporting resources are available at speaking Matty stratton.com. So I've got some supporting links, some additional reading if you're interested. I have a podcast called Arrested DevOps. And if you like kind of silly online game shows about tech, you might want to tune into DevOps party games, which is another thing that I have there. So thank you very much. Go ahead and hit me up on Twitter if you've got any questions, any thoughts on how we can really keep moving things forward. Thank you.