 Welcome, everyone, to this talk about 10 years of DevOps that are being today by Karthik Gaikwad. We're glad to have him join us today. Without further delay, I hand it over to you, Karthik. Thanks, Hari. And thank you, everybody, for coming to my talk. Good evening. This is a quick talk on 10 years of DevOps. See? So quick agenda. We'll go through a history of DevOps, some of the significance of that, what the evolution has been, so kind of where we are today. And then the most important part of this talk is five practical learnings that you can take back to your own work or your own place of work, so you can kind of use some ideas that I have in here. So my name is Karthik Gaikwad. I am the head of cloud-native engineering at a company called Verica that does chaos engineering for Kubernetes and also for Kafka, so kind of interested in that space. My history is I used to work at a lot of large enterprises, a lot of startups as well. Been in industry for a while, and I just like to build things, so that's kind of where I come from. And I also like to teach and build community. So I live in Austin, Texas, and I help run DevOps Days Austin container days at our local meetup called Cloud Austin. I'm also the chair for the all-day DevOps track, for the cloud-native track for the all-day DevOps conference, and you might have seen my LinkedIn Learning author or LinkedIn Learning stuff at Learning Kubernetes. And so let's get into the heart of things, right? Let's do a quick history of DevOps. Most folks have probably heard of this before, but DevOps kind of began in 2008 at the Agile conference where Andrew Clay Shaffer was talking about this idea of Agile infrastructure. And Patrick Debois attended the birds of feather, and he was really interested in understanding what Andrew's thoughts were. And then sure enough, it's a random thing that you kind of do at the conference, and so Andrew didn't come to that. But later on, they talked at the conference, and they were really interested in the ideas of operations and development topics and how they kind of come together. Also, in 2009, John Olsba had the famous 10 Deploys for Day of Presentation at Flickr, and everybody in the audience was really kind of wondering, like, wow, they're actually deploying an application to production, not just one time every day, but 10 times. That's pretty amazing. But what is DevOps really? So there's many definitions. Everybody argues about a definition, but a practical one that I really like is DevOps is the practice of operations and development engineers participating together in the entire service lifecycle from design through development process, and then finally, production support. So this is from the Agile Admin blog, the thing for what is DevOps. The other way people really like to describe DevOps is using the pillars. So I think Botchical Loop on Twitter came up with this, which is the idea of comms or clams, culture, automation, lean measurement, and sharing. The five different pillars of it. And at least like when 10 years ago when this was pitched, that was the intention. That was where people were coming from. That was the mindset. But what has it really evolved to today is probably what we're more interested in. And so today, if you kind of look at DevOps in general, out of the five pillars, it feels like automation and measurement are the two most primary things that everybody talks about when they say DevOps. You ask somebody, oh, you're DevOps engineer, what do you do? Oh, I work on the automation part. So I use puppet or I use terraform or something. And then the other thing they might say is we are very heavily into measuring all the things. And so out of the five pillars, automation and measurement have definitely gone past culture, lean, and sharing. So a question that also comes up is like, how come everything seems like I thought the whole point of all of this was culture, what happened along the way? And so I put some Dilbert comics in here because I know it's Dilbert as old school, but I still like to read Dilbert a lot. And so we're all engineers. And DevOps is more of an engineering thing than a business thing at this point. And so ideas of automation, ideas of measurement are easier problems to solve than people problem. So this thing talks about why did the pick a vendor or whatever. But just from an engineering mindset, it ends up being an easier thing to solve. Also, organization culture is hard to quantify. So you might work at different companies. And every company has a different kind of culture from a large-scale organization kind of thing or large-scale organization. So you're not only trying to influence one person, you're trying to influence a whole organization. So it ends up being a tricky kind of problem to solve. And sometimes when we're faced with hard problems, we try and pick battles that we can win. And so a battle of automation and measurement might be a simpler battle to take on versus trying to challenge a organizational culture, you might not know where to start and how to go about that. And also change is hard, right? So we are all wanting change in our organizations. And we're all wanting to do things in a different way. But actually getting to that way might be really difficult. There's a lot of inertia. There's a lot of processes that might have been put into place for one reason and could have evolved into something completely different and now no one really likes it. But regardless of all the reasons, the way to change might end up actually becoming pretty hard to do. So to summarize, our DevOps definition has changed. And we now kind of focus on specific subset of colors. And one thing, and this might be a personal opinion, but I think one of the problems that we have forgotten is that with the idea of DevOps, there was operations and development coming together and working hand in hand. And it's more of a people problem than really an alignment kind of issue. So this is, I put the slide in here as a joke, kind of slide, but today like most companies are trying to sell you like a solution for DevOps. So it's DevOps in a box, basically. So where do we go from here? I've been in industry for a little while and a lot of folks in the past, you know, and there's no harm in this, you know, where do we start? Because in the US, most companies might be doing, having this idea of DevOps and, you know, might be doing it in a specific way, but the world is not just US centric, it's the whole world. And some parts of the world is to try to understand, you know, okay, where do we start from a transformation point of view and you know, where do we start? So let's talk about that real quick. A couple of recommendations that I give is, you know, first, if you're coming from an engineering perspective or if you're on the business side and trying to understand what, how engineering is kind of doing things on their end, you know, talk to the business folks. So, you know, your companies, you know, I might really like Kubernetes, right? But my company is not a Kubernetes company, it's actually doing something else. So business is not stopped. So it's important to understand the business perspective of all of the engineering stuff that we do. It might be very different and then the business always wants to go faster. So one thing that they look for for a partner from the engineering side is like, hey, can we actually push code out faster? So, you know, from the Dora state of the, state of DevOps report from last year, you know, companies that were high performing or 46 times more had 46 times more frequent code employees. And, you know, they were 2700 times faster to recover from instance and things like that. All of those things need engineering kind of work, but they're actually, you know, business initiatives and they're partnered with business and they're not like an isolated thing. Also, if you're, you know, trying to, if you're on the engineering side and you're trying to like come up with a modernization strategy, DevOps should be one of the plays that you have from a modernization perspective. So I put this chart in here, you know, when I first started in industry, Agile was really big. We still built, you know, three tier applications. Like for me it was three tier, but it's really end tier. Virtual servers were a thing. And then actually my first company that I started at, we had our own data centers worldwide. You know, today, from a development point of view, we're talking about DevOps. We are talking about microservice from an application point of view. We're talking about containers and packaging things inside of containers when we're shipping products. And most of the world has started to evolve to cloud if not already evolved from an infrastructure point of view. So if you're thinking about, well, where do I, you know, bring DevOps into this picture? It kind of falls into not just the DevOps portion over here but really all of the things across the right. So, you know, you do need to kind of have a strategy to go into microservices to, you know, run containers or even go to the cloud. It's very different from running infrastructure in your own data center. So to kind of like summarize the last two points that I've made, it's really all about alignment. So it's important to have alignment between the technical folks in your organization and the business folks in your organization because I made this mistake really early on where from a technical point of view, we were like, okay, yeah, we should really use DevOps because we need to be able to deploy, you know, multiple times in a day, make that easy and all of that. And then we delivered a solution but the business was like, well, we don't release. Daily, we release once every three years. So I'm really confused why you guys spent all this time to be able to do that, you know. So that's kind of less learned for me personally and also alignment from a technical team perspective because from a technical point of view, all of us have really good ideas and we want to do things in specific ways. So it's important to bring alignment between internally in your team and even in your like organization. So, you know, when I worked at large enterprises like Oracle, we had to bring alignment not just in my technical team but also in our whole like cloud division. So that's alignment stuff is really important. And don't forget that at its heart, DevOps is a people problem. So in order to effectively introduce DevOps into your organization, you need to keep your teams actually working together. So I put this picture of, you know, this is actually an interesting story to read about folks, the Amish folks actually building a house. Like everybody has their own tasks and they're kind of working on, you know, building a house like the Roofer guys know exactly how to build a roof. The guys inside know how to build, you know, the side of the house and some of the guys that are doing the framing are really good at framing but they're kind of all working together in order to, you know, build that house in a timely manner. So let's take a quick stab at kind of where DevOps is today, what we're going from a future trends perspective. One of the things that I think we hear a lot today is, you know, DevOps is becoming, we're not hiring DevOps engineers, we're hiring SREs and it feels like we took some paint, we had this DevOps poster, we repainted it and made it SRE but really SRE is a subset of DevOps. So, you know, make sure that if you're in an organization and you had operations people and you're trying to rebrand, you know, you might rebrand into SRE that's totally okay but make sure you're actually thinking about the entire comms life cycle. So, you know, it's culture automation, measurement sharing, SRE in this perspective might be the importance of it is, you know, available to the latency performance, et cetera. But, you know, the mindset has to be kind of a DevOps mindset. Cloud native is also becoming a big thing. You know, I'm kind of been squarely in this for the last, I think five or six years now but, you know, it's a new paradigm that's a cloud native computing foundation is kind of the, you know, kind of the stewardess of a bunch of different projects. But, you know, if you're trying to break it down most of it is kind of based on Kubernetes and container technology. It has a really rich landscape and a huge community if you've ever been to KubeCon. I know KubeCon India happened earlier this year. Does one last year as well. And I think there was, you know, 3,000 people or something came to that. But the drawback of having a big community is it can become, you know, very complicated to navigate. So, this is actually the old chart for all of the different projects in the CNCF and different products in the CNCF. It's barely hard to read. Whenever I look at this, you know, I turn into my two-year-old who screams a lot. And so I think the analogy is like, yeah, it's impossible to read everything in here. So it is kind of like a scary thought kind of coming into it. There are some easy ways we can talk more about that in my, I have another presentation coming up in a couple of days and we'll talk more about making this a little bit more digestible. But, you know, it's a journey. Serverless is also becoming a big thing. There are some companies that have gone directly from cloud-native or instead of cloud-native, they skipped over into serverless. So it's a brand new execution model where if you're just running everything in the cloud, the provider manages your resources and you are responsible for just your code. And also observability is becoming a big thing too where this is more applications that become more distributed. So in the past, everything would run machine. Now you have like applications kind of distributed, you know, all over. So the idea of observability is to understand like system behavior from system outputs. So inputs and outputs. So, you know, how well the internal states of the system can be inferred from, you know, external outputs. So this is kind of like an idea that's come along, it's come a long way, but it's required because we're going into a more distributed world these days. And also, yeah, like we, that's a new era in testing security and database. It feels like everybody is shifting left and trying to do the thing that DevOps did a few years ago. So there's like new ideas and Dev Test Ops and Dev Psych Ops and, you know, Dev DV Ops. My only recommendation that's on this is, you know, there's, these are groups that historically were outside looking in. So instead of saying, oh no, this, you know, Dev Psych Ops is a terrible idea, don't do it. And, you know, that might be DevOps itself, like welcome them in and try and figure out how you can align together. So let's do five key takeaways. I think I have a minute left. So I think it'll work pretty well. So these are, these are my opinions and like five takeaways from this presentation. I would really recommend, you know, to me DevOps is all about collaboration. So make sure you understand what the other side is doing in your company. So we're all partners in this. So it's not like one person is kind of working on something specific. Understand your business. They eventually actually pay you what they pay you. So you, it's important for you to actually understand what your business is doing. We're not, you know, just there to maintain a specific instance of Vox. It's important that you're, you know, you're actually responsible for your business. If you're a technical person, use architecture to your advantage. Sometimes when you were deep into these squabbles inside of our companies, you know, you can actually bring out an architecture diagram and try and get everybody aligned. I use this trick a lot in, you know, where I work. How does this map back to architecture? It works out really well. Always be learning. One thing about, you know, or like I put the corollary in here or you might have to get it, find a new job. Once you stop learning, it feels like a part of you stops doing things. So always be learning like DevOps, cloud native, all those things have like new ideas coming into place. So it gives you a greater opportunity to be learning new things or how to improve on process. And finally, you know, be empathetic, especially with this pandemic right now, you know, work from home and, you know, people having kids and everything. I feel like technology will always be there, but people might not. So it's important to be empathetic to your teammates, your organization, the folks that you work with, folks you work for. Because I feel like we're kind of all solving problems together, so it's important to understand the human aspect of things. So I think that's the presentation that I had. Thanks again, Karthik. This was very, very useful.