The Definition of DevOps

From a practical perspective, actually delivering a software project requires two things, development and operations. One of the best ways to organize those two aspects is to utilize what's called DevOps. Historically, there's always been a wedge between development and operations. Developers develop and operations performs all the deployment and operations needs. But with DevOps, these two roles are joined into one. And the result is a collaboration between the two roles, rather than a separation. And what that means is that the organization gets far more efficient software releases. So, let's dive into DevOps a bit. Now before we get fully into what DevOps is, let's talk about what the traditional divide between development and operations has been.

The fact is that development and operations have different objectives in the overall project. Development focuses strictly on developing the product while operations focuses on development and maintenance. They work on the same projects but they have different objectives on those projects. In some cases, that results in the two groups having competing motivations. The development team wants to build something technically sound and easy to work with from a code perspective. And the operations team wants something that's easy to deploy, track, and maintain. And sometimes those two things work in opposition to each other. Something that's beautiful from a code perspective might be difficult to deploy and vice versa. And on top of that, because we're talking about two different teams, there's almost always a literal physical separation between the groups and that can impact communication and any sort of interaction at all.

Now DevOps looks to solve all of those problems and I'll get to that in a second. But before you invoke a DevOps strategy, it's good to consider the environment that allows DevOps to actually be effective. For example, if your organization uses an Agile development model, then DevOps is going to work very well with that. DevOps seeks to combine development and operations, while Agile seeks to increase communication. Both of those objectives work really well together. DevOps is also extremely good for any organization that actually implements a proper continuous integration and continuous delivery or CI/CD strategy. CI/CD is a game changer and I don't think I could ever look back since implementing it myself. And the DevOps model works extremely well with CI/CD. In fact, CI/CD itself is only truly effective if you have a DevOps model. Now, if your organization implements proper IT service management, then DevOps might be a good fit too. IT service management is the process that some IT teams use to deliver IT services to their customers or even users within the same organization.

The main idea of IT service management is that IT is delivered as a service and goes beyond just the basic IT support. So, because IT service management oversees all kinds of technology, DevOps works really well. In this case, the team is developing the IT solutions and delivering and operating on their delivery. Now if you're going to implement DevOps, then you'll definitely need repositories. The most popular repository these days is GIT. Now these repositories are generally used for storing code, but it can also be used to store scripts and such like that. The main thing is that you want to make sure that controlling the versions of whatever it is that you're developing. And lastly, for DevOps to be effective, you'll need some mechanism of incident management. You want to track issues and continuously improve your process.

So, now let's talk about how DevOps can improve your life over traditional deployment methodologies. Remember that the main idea with DevOps is to combine the development and operations teams into a single cohesive unit. Now, one of the biggest benefits to DevOps is that it accelerates your release frequency. Traditionally, the development team creates something and then throws it over the fence to the operations team to deploy. The Ops team is then required to figure out how to deploy and maintain the software. The Dev team might have some documentation or even give some training. But otherwise, the Ops team is on their own. Well, with DevOps, the team becomes one team. So, in reality the same people that are developing the product and are intimately familiar with it are the ones that are deploying and maintaining it. And that creates increased efficiency. And of course, that means that it lowers a risk quite a bit too. There's virtually nothing lost in translation between Dev and Ops because they're one team.

The team knows exactly how the software works, how to deploy it, and how to maintain it. So, deployment risk is all about completely mitigated. The DevOps also empowers developers. In the traditional model, developers create the product and are then completely hands of to the actual deployed system. With DevOps, they're intimate with the deployed software and that gives them a lot of control on how the product will be made and how it should be supported. And of course, DevOps means enhanced collaboration. Now because the Dev team and the Ops team are now one, clearly that relationship is enhanced. But because the team is now one, it also enhances collaboration with other teams. If other teams have questions about the software, they don't get bounced between two teams to get their answer. It means that the single unified DevOps team can collaborate much more efficiently with other teams. And believe it or not, DevOps results in improved security. Thanks to the simplification of the teams. Rather than having two teams that need differential access, we now have one team that requires very specific access.

I can also tell you from my own experience that DevOps results in simply better software. Because the Dev and Ops teams are now one, the team is required to not only understand the development needs, but also the deployment needs. And that results in a higher quality product that's start through the operational needs. Basically, this results in better logging, more metrics, more robustness, and do consideration of other SRE or support needs. Now if you have higher quality and more efficient teams, DevOps can't help but make sure that the organization gets improved business outcomes. With all that risk mitigated and with better communication and with better quality software, you're assured that what gets delivered is just better than if you'd kept the team separate. And a better delivery means a better business outcome, which leads to our last point. If you're producing a better output on a more frequent basis, you know what else you get, happy customers. And happy customers means more business. So, everybody wins.