So what is this DevOps thing anyway?

Here's a typical conversation between a systems engineer and a software engineer that has happened at least once on every company on this planet. Our software engineer goes to our systems engineer and says, "Hey, my app is running really slowly in production. I'm not sure why. Can you see if something's up with the platform?" Our systems engineer says, "Sure, yeah, I'll have a look." Two weeks later, our systems engineer comes back with, "Hey, um, the platform is looking fine, I can't find anything wrong with it. Maybe it's something in your code?" The software engineer replies, say, "okay, yeah, we'll have a look. Thanks." Now this conversation seems innocent enough, but there's actually a lot going on here. The devil's in the details. So this conversation usually doesn't happen between two engineers sitting next to each other. Usually this conversation happens in the form of helpdesk tickets. This can add lots of waiting. Both engineers have a lot going on, both engineers have to be able to find tickets and respond to them, it can just add a lot of slowness. Furthermore, our software engineer knew a lot about their app, enough to know that something was wrong that wasn't coming from their app, but the problem here is that that engineer didn't know anything about the platform that that software is running on. Conversely, our systems engineer knew everything about the infrastructure that's powering their platform, and they knew enough to know that the platform is fine, but they know nothing about the software that's running on it. So, because neither side knows a lot about the other side, usually there's a lot of undocumented work happening behind the scenes to fix things and this usually manifests with some scripts or documentation, or just some commands and knowledge, and some senior engineers head that get run when things go wrong. But the biggest problem here is that neither engineer knew that stuff was going wrong until it was way too late. Unfortunately, this happens all of the time. This happens when existing software just doesn't work as well, or when new software is getting released. So what does this actually mean in real life? What happens after this conversation's over? Well, work that should have taken minutes to do can often take months or even years to accomplish in the most extreme cases. A byproduct of this is that any downtime that happens can grind operations to a halt, because a lot of the tribal knowledge that people rely on to fix things is hard to find. People just don't know about it. And worse, if our senior engineer decides to leave the company or just go on vacation, then everyone is scrambling to figure out what to do next. The net result of this is that production becomes a scary place. No one wants to make changes because no one wants to rock the boat. No one wants to break anything because no one wants to have to scramble and run around trying to figure out how to fix things. What if things were different? Could there be a better way of operating here? What if our engineers shared knowledge that they knew about each other so that they could know about each other's domains? What if they work together when things go wrong instead of communicating with each other through helpdesk tickets? What if they could feed off of each other through this increased knowledge and increase collaboration to do their jobs better? That's what the DevOps ethos is all about. DevOps is all about bringing engineers together by removing silos, improving communication, and documenting everything as code. Even though the name DevOps implies that this culture is just for developers and operators, DevOps can actually be for everyone. It's important to know that DevOps isn't just a job, it's a culture. It's a way of working. It's a way of being. So you can remove silos, improve communication, and document everything in every part of the engineering process and in every part of the business. Here are some common examples of implementations of this. There's been lots of talk over the years about bringing DevOps to security in the form of DevSecOps. There's also been lots of talk about bringing DevOps to product management through ProdOps or finance through FinOps. We've even seen the DevOps culture be embraced by business development in the form of BizOps. Everyone can benefit from working together. There are three big tenets that comprise the DevOps way of being. The first big tenet is having better documentation. DevOps believes that having better documentation leads to better communication. Since you're not relying on tribal knowledge, you're relying on shared knowledge that everybody knows. Better communication can lead to better automation by taking that documentation that we have, taking the more manual grunt work that's a part of it, and automating that stuff away so that people can focus on being the best engineers that they can be. Finally, DevOps believes that all of this can be accomplished through code, because if we can express everything as code, then we have a way of expressing everything in a common language that all engineers and all people within the business can communicate with. In the next video, we're going to learn about Explore California. Explore California is California's premier travel agency, and they're having lots of issues that DevOps can help fix. We're going to take them on a journey to help them embrace all of these things that make companies like Explore California be able to ship better, faster, and more securely.