 Next, I have the privilege of introducing Brendan O'Leary, Staff Developer Evangelist at GitLab. Brendan is a career technologist with a wide range of experience. He's worked in all types of roles from product and engineering to sales and marketing, and he spent time in the trenches as a DevOps practitioner, solving the same types of challenges that you all solve every day. One of my claims to fame is that Brendan and I actually joined GitLab on the same day in October 2017. So we both just celebrated our four-year anniversary of being part of the GitLab team. And what I can say in the last four years of working with Brendan is the thing that I have appreciated most about him is not his expansive knowledge and experience about technology, but it's been his expansive heart. Brendan is always human first in everything he does. So even as Brendan talks about technology, he always does it with deep empathy for the people using that technology. In this talk, Brendan will show us how we have entered the era of platforms, what that means for us and what you and I can do to navigate the current technology landscape. Today, you've already heard a lot about the evolution of DevOps from DIY to the DevOps platform. But what do we mean by platform? And does it only impact DevOps or is it broader than that? Well, that's what I want to talk about today. As developers, we can sometimes overuse words and platform is definitely no exception to that rule. We often talk about the platform we're building or how we hope our users will see our product as a platform. And what we mean in all of these instances is we expect our users to be able to use what we build as something greater than the sum of all the parts. And when we talk about an internal platform, we often mean the sum of all those tools that we use to deliver software. What you might think of as the traditional SDLC software development lifecycle or DevOps tool chain. We've often strung together these pieces and tools into a semblance of a platform. That's what we heard William talking about at the start of our day about, you know, those DIY DevOps platforms. And those platforms come with two significant challenges. First, they aren't integrated. To be a platform to really have something greater than the sum of its parts, someone must perfectly integrate those parts together. Even at GitLab, we didn't see this at first. When GitLab was young, GitLab CI came around simply because our co-founder, DZ, was tired of the effort it took to keep all the servers that were building and releasing GitLab then watered. And GitLab and GitLab CI were separate products at first. Our leadership team intentionally had it that way. And it wasn't until they were challenged by a newcomer to the open source project, Camille, who also wrote the GitLab runner and eventually came to work for us that they even considered putting the two together. They're separate tools, they said. They're as perfectly integrated as two separate tools can be. And you should have many sharp tools and things like that. But in the end, Camille was convincing and we took a leap. Integrating the tools into a single application. And once they were in that single application, the advantages of a truly integrated platform like single authentication stack, a single project, setup, installation path, data store and project flow, as well as all the emergent benefits of the DevOps platform became possible. As great as those things seem, integration isn't even the biggest challenge that comes when you don't have a single DevOps platform. The biggest challenge is one that any business or economic student can name for you. And it's called opportunity cost. When I think about opportunity cost, a couple of clear examples come to mind. The most personal one is represented best by a dining room table. So a few years ago, our family was growing a lot. We had four kids under the age of seven. And yes, that's too many kids. When I pointed this out to my wife, she aptly told me that it was a little late to come to that realization. And I said, yes, dear, I know, I'm just stating a fact. It's too many kids. Well, that's a whole other story. Anyway, with the family growing, we're quickly outgrowing the current townhome we were living in. And we needed to find more space. We were fortunate to find the house we're in now, the one I've been working in for the past four years while I've been at GitLab and the one that we brought our fourth home to. Now, being that the house was a lot bigger, it came with a lot more room and rooms than we had before. And I guess that seems obvious. But for a young family, we didn't have a whole bunch of furniture. And so many rooms, heck, maybe even a few still, had little to no furniture in them. The most obvious kind of gaping hole was in the dining room. We didn't have a dining room table. And we typically ate at the kitchen table. But a dining room is kind of well designed for a table. Luckily, I consider myself as much an amateur aspiring carpenter as I do an amateur aspiring software engineer. So I told my wife of my grand plans to source some local wood from a tree that would otherwise go to waste and mill it down myself, let it dry, and build a fantastic farmhouse table out of that was, you know, of our really my dreams. The best laid plans, though. Flash forward a few months. Having, of course, made zero progress on the DIY front, we walked into a furniture store looking for outdoor furniture. And there it was, the exact table that I had had in my mind. And it was on sale. So I had a choice to make. Do I buy this table for probably the same that it would cost me in getting a nice lumber and parts and for sure less than all the time it would take for me to build it? Or do I dig in my heels and say, no, I'm going to build our own family room table and I'm going to build it better than anyone else could? Well, I guess you can tell from this picture and what I just said that, you know, what choice I made. And I love that table almost as much as I have if I had made it myself. And instead of spending time in my workshop, probably doing a lot of, you know, using a lot of choice words and hurting my thumb with a hammer at some point. Now I get to spend time at this table with my kids. My daughter loves to build puzzles on it and my five-year-old loves to draw. And when the whole family is in town, well, it also has this great built-in leaf system that I definitely wouldn't have been able to pull off myself. And so we expand it and it fits everyone around it. And that was the opportunity costs that I chose to, you know, make a decision about and not spend that time building it myself. And maybe that kind of opportunity cost seems, you know, maybe obvious to a lot of people. I know if you asked my wife, she would tell you it was very obvious. But there's a lot of these costs that we allow to happen outside of kind of a, you know, cut and dry decision, sorry, a little lumber pun there, as, you know, building or buying that table. And that's what I want to talk about. So I have another example, actually from my experience as a software professional that I want to give as the second example of this opportunity cost. So early in my career, I helped run product and engineering at a small medical software company. It was at the time of, you know, great consolidation in medicine. And so we had this huge opportunity to really bring a solution to market. We had great product market fit. We lived in a very tight vertical. It was in women's imaging within radiology. But to take advantage, we had to constantly outpace our competition. And in terms of innovation, we at that time were the market reader. And the rest of the market was trying to keep up with us. And so we wanted to hold on to that lead. Anyway, one day I'm walking back to my office from the CEO's office. I don't remember what the meeting was about, but I do remember what happened on the way back to mine. In between our offices was a server room. You remember those little dark rooms that we used to, you know, pump full of AC and all of our individual office buildings. Oh, and office buildings, I'm sure you remember those before remote work. Okay, that is a whole different story. But anyway, I'm walking past the server room and I noticed the doors propped open. It's basically never a good sign if the server room doors propped open. And as I'm going past, I turn my head to the left to see what's going on in there. And just across the room from me at that little work desk, you know, is in the room, is one of our top engineers with a screwdriver in a server. That engineer was working on one of the few critical path new products that we were trying to bring to market at the time. A first of its kind electronic patient questionnaire on this newly released device called an iPad. And here they were with a server on their lap and a screwdriver in that server. That server happened to be the RedMind server. It was the tool we used to track project progress, bugs, feature requests, et cetera. And it had a hard drive go bad as, you know, spinning disk hard drives are want to do. Since it wasn't working, they didn't know what to work on next. So the thing they were working on was fixing the RedMind server. It was at that moment that I had a real epiphany about the opportunity costs of hosting and running our own development tools. And right there and then I decided to go out and spend money on this other new thing called the cloud. It was still very new at the time. And we were going to move as much as possible out of that server room. Heck, at the time, I think we even still had an email server in there. But I didn't want our lead engineer putting screwdrivers into servers anymore. I knew there had to be a better way. As William said, my name is Brendan O'Leary and for those who don't know me, I've spent most of my career looking for that better way. From my start in product and engineering management and that medical software company to working with the US Department of Defense and US Special Operations Command on this DevOps thing to my time at GitLab where I've had a number of different roles. I've always been passionate about developer tooling and enabling developers to do their best work. At GitLab, I've been fortunate enough to have spent time working directly with customers, helping to build a professional services organization to help our customers get the full value out of GitLab. And then I spent some time as a product manager looking after the very part of the product that made me fall in love with GitLab at first, CI or continuous integration and our GitLab runner. And most recently, I've been privileged to work as a developer evangelist and to speak to people like yourselves and spend time in our community and other communities, understanding the real problems stopping developers from being as efficient and effective as they want to be. And when we think about that, about enabling developers to do their best work, I think we have to think about our own return on investment. And I don't just mean in a strictly business sense, though I guess this talk might double as an economics lecture with all the economics terms I'm using. But also developers and software professionals want to work on things that matter and see the results and return from their labors. And what we find when we end up spending our time on things outside of our core value proposition to our users, like our DevOps tooling, is when we find that those returns diminish quite quickly. So sure, putting no effort into your DevOps tools or practices isn't gonna get you to be very successful. But by the same token, it's not a linear growth path to say that the more effort and time you spend acquiring, integrating and utilizing lots of different tools or even building tools of your own will always pay off. Eventually, that kind of work faces the law of diminishing returns where even a little more effort doesn't give quite the same output or return as the last bit did. And eventually, you fall off the cliff where your teams are getting less value out of the time they're putting into dealing with tools than you're actually getting out of those tools. And it's important to understand what that means. If your team is less effective because they have to spend time on a tool chain or finding data in various systems and syncing it up, then your stakeholders are who are gonna really suffer. What you really wanna do is have happy users, happy stakeholders. My wife, very happy to have a functional dining room table and even happier that she didn't have to take care of four kids by herself for a month of Sundays while I built one. And that's true of every tool and platform we choose to use. It's not only true for the DevOps tool chain and the tools you use there. It's true for other platforms like Kubernetes. In the end, cloud native technology is only as valuable to us as the value it allows us to show our stakeholders and users. That's the actual goal. The actual goal, a table to eat at, value delivered to our users, a stable environment for our application to scale in, that is what's important. And that is what we have to focus on. The goal of Kubernetes or any technology isn't that, or at least it shouldn't be, to use technology for the sake of technology. Oh well, you know, that's what they do in Silicon Valley, isn't a great way to run your business or your technology organization. In fact, technology for the sake of technology is never a great idea. Just ask anyone in a post-apocalyptic movie with technology taken over or anyone in an episode of Black Mirror. The goal of use in technology then is to enable you to get to your goals more efficiently. The explosion of the distributed systems can be hard or impossible to manage without a structured way to deploy and control how those systems interact with one another. And we wanna be able to provide elastic compute. Long gone are the days of, well, how many servers do we need to do this? In the world of microservices, those services can and must scale up and down to meet demand without human intervention. Without problems like those to solve for in order to make your stakeholders happy, maybe Kubernetes might not be the right fit. I know, it's probably a bad thing to say at KubeCon, but it's true. And a similar environment exists for DevOps. The goal of DevOps, which is over 10 years old now, was not just to invent a new word that put development and operations together. It wasn't just to create a new role for people to go around and be able to say, I'm a DevOps now. The goal was to solve the problem of a lack of coordination between developers and operators. And that problem at its core was a problem because it was limiting teams ability to deliver better software faster, to be efficient, to outpace their competition and secure their environments, all while making their users and stakeholders happy. The goal of DevOps was never to acquire as many tools as we possibly could. That can be fun. Again, if we go back to my carpentry story, of course I like getting new and exciting tools. But it's the ones that I actually put to use to solve problems, to fix something my wife or my kids have been asking me to fix. Those are the ones that are actually valuable outside of just the tool itself. So when we're thinking about solving these problems, about bringing together operators and developers, we have to remember the overall goal and we have to factor in the opportunity cost. For developers, that might be the difference between delivering on new products or new features or putting a screwdriver in a server. And for operators, it might be the difference between working on MTTR or the mean time to recover a service when it has a problem or increase the organization's ability to deploy frequently or putting a screwdriver in a server. And before you say it, no, it's not always screwdrivers in a server. But believe you me, every minute your team spends clicking around the AWS console is just the modern day equivalent of putting a screwdriver in a server. This kind of thinking, this focus on results, doesn't just help your users, it helps everyone. Individual contributors on your teams want to work on new features. They want to work on system stability and true SRE level tasks. And your engineering management. They want people working on those things too, not spending time messing with their tools. To put this type of thinking into action though, we have to force ourselves to take a step back and change our focus. We have to focus on what's really important. And what is really important? The thing that everyone in our value chain wants us to be thinking about. The thing that our users of our products our management, our board members, our shareholders want us to be thinking about and spending time on is differentiated work. We want to free up our best engineers to work on the hardest problems. The problems that are really gonna make a difference for you and your business or your organization. And when we do that, we'll enable our organizations to move faster. And when we can move faster, we'll be able to respond to market changing and changing conditions faster. And in today's world, where software has eaten the world many times over, having the right platform means being able to respond to the market quickly. And that is what allows all of us to win. So okay, you say, I'm in Brendan, I get it. But what is really needed? What are the things that I should go back with to my team after this day is over? Or maybe after the weeks over, if you're staying for the whole conference. Well, I think it's a focus on three key areas. The three key goals at the end of any discussion around platforms and why we choose the platforms we do. Each of these aspects drive discussion around those platforms, whether it be your DevOps platform of choice or the platform you choose to deploy your code to like Kubernetes or some sort of serverless platform. First, it's operational efficiency. You want your team working on the most important issues, not doing the busy, undifferentiated work of trying to connect systems together or understand what the status of something is or what's next to work on or when should I expect this change to be getting approved or how's it going through the dozen different dashboards that tell me that kind of different status. What teams really need to work as a team in this DevOps methodology together is an efficient platform to use for all collaboration and communication, a single source of truth. And once they have that, teams can now work in parallel, not serial. Feedback is delivered faster and the wait time is reduced greatly. And those benefits, coupled with a focus on automation for things like testing and deployment and security will allow your team to deliver better software faster. And finally, while it may seem antithetical to the idea of speeding up the time of delivery, you will also be able to reduce your security and compliance risk. The surface area of your platform versus a wide variety of tools all administered by different teams with a different set of security practices will be greatly reduced. It will be cleaner and easier for your teams to ensure compliance, especially if you work in a regulated industry that requires strict compliance or audit capabilities. And on top of that, independent research has shown that this increase in velocity doesn't actually have to come at the cost of security or stability. Once you've decided to focus in on these capabilities, there are four key metrics you should be measuring to understand the impact your changes are having on the teams and the software you deliver. A seven plus year research effort from Dora, the DevOps Research and Assessment Group, has been examining what separates teams who excel at delivering better software faster from teams who struggle to keep pace. They have found just four key measurements that both correlate to higher performance and have predictive relationships with not only software delivery performance, but also overall organizational performance against those organization's goals. The data shows that focusing on the enabling capabilities that allow organizations to measure and improve these four metrics is directly attributable to the ability for organizations to improve overall. And that includes areas like revenue or other goals, as well as human factors like job satisfaction. The first two metrics, lead time and deployment frequency, consider the effectiveness and efficiency of the software development process. These provide insight into the speed of software delivery, how quickly teams can get changes into production. Often I like to think about it as this, if I had one line of code that I knew needed to be changed, how long would it take me to get that into our production environment? And how many steps does that single line of code have to go through to get there? The other two metrics change failure rate and mean time to restore, as we said often referred to as MTTR, speak to the second half of the pie, stability. How reliable are those changes that are coming into production? How often do those changes result in production instability? And since that number is unfortunately never gonna be zero, how long does it take to restore services when something does go wrong? These four metrics, which seem pretty simple on their face, can accurately measure a team's overall software delivery and operational performance. And measuring them in a way that we can set about improving them requires a tightly integrated system, a DevOps platform, where all the data is available in a single data store. And that's just it. That level of integration, that level of insight, that level of impact, that is what you should expect from your platforms. And it is this ever increasing desire to move software to market faster that has ushered in this era of platforms. The platform shift is one we've been seeing for some time and I'd expect it to continue well into this decade. As software has grown to eat the world, we've all been racing to catch up and make sure we have systems to meet ever increasing requirements and demand. But too often, we focus only on the engineering side of software engineering. You know, the amazing things we can do with code. We understand that a lot of our problems can be solved with code. But in the end, it's not just the code that counts. What really counts, the ethos of DevOps really is bringing together people, processes and tools and aligning those three dimensions to a common goal. And that kind of alignment, the alignment that brings with it the ability to really deliver for our users, our customers, our stakeholders, that isn't something that comes easily. It requires a concerted effort that is much larger than the actual code that implements a feature or fixes a bug. And when it comes to the tools and process part of the people process tools equation, the only way to bring both and align them together, the tools and the processes of our teams towards the same goal, towards value delivery, is to incorporate both into a single platform. Whether that's Kubernetes or another platform to deploy our code to, or it's a DevOps platform to create, build, test and deploy that code from, those who choose the platform approach will outpace the rest of the industry every time. But that alignment of process and tools doesn't come at the cost of not understanding the people who are involved. In fact, I would say it's the people that is probably the most important part of people process and tools. And I don't think I'd be alone in that thinking. Platforms enable teams to do their best work together, to collaborate without boundaries, to aim for and achieve results together, to work efficiency efficiently without wasted time, to bring together diverse sets of skills and include everyone in the process to foster a sense of belonging. They allow you to iterate quickly, moving to where you need to be, not where you thought you should be six months ago. And the best platforms do this all by enabling transparency, being as open about as much as possible and bringing the threshold for collaboration lower and lower. It all reminds me of a scene in the first episode of Halt & Catch Fire, which is a drama about building the computers in the late 70s and 80s. There's a visionary idealistic product manager, his name's Joe, and he's trying to give inch to a hardened engineer, Gordon, to sign up for what they're gonna build together. It's very reminiscent of another company founded around that time, but I'm sure AMC would say they're not related. Either way, the closing argument for this project sums up nicely how I like to think about software development. Joe says computers aren't the thing. They're the thing that gets you to the thing. And later, in closing the series, another character, Donna, calls back to that line and adds, the project gets us to the people. And that summarizes fairly nicely for me what makes both Kubernetes as a development platform and GitLab as the development DevOps platform even more special. Both are built on the foundations of open source and drawing people from all over the world to collaborate together on the very tools that they are gonna use to then go and build something bigger. In this way, open source allows us to work together, no longer siloed building our own little platforms out of bubble gum and bash scripts, so many bash scripts, but bringing all of our ideas and creativity to bear on the problem and all of our collective experiences and expertise as well. And that's what keeps me around and what makes me so proud to be a part of the cloud native community and a part of the GitLab community. And at GitLab, we're very particular about how we use certain words. Since I work for GitLab, I'm a team member. We don't use the term GitLab'er there. And that's because we reserve the term GitLab'er for more than just our team, but for the whole community of users, contributors and customers. The project gets us to the people. Thank you so much. I'm glad you chose to spend some time with us. GitLab team members and GitLab'ers alike today. And I hope you learned something. I'll be around, commit at KubeCon today, and I'll be around at KubeCon all week, both in LA and online if you're joining virtually. Please come say hi. Thanks again and stay safe.