DevOps vs. Its Predecessors

Software development is a big deal. There's lots of moving parts and variables. We can talk about development models all we want but DevOps really looks to shake things up and improve the entire process end-to-end. Now for me, one of the top considerations in a successful DevOps implementation is culture. The traditional approach to software development has always been risk-averse. We shy away from problems and look to avoid them as much as possible and intuitively that makes sense. But it also limits us in so many ways. With DevOps, the culture is flipped on its head. What we actually want to do is fail early. Now imagine we avoid all our risk items and work on a project for six months. Then at the end of the project, we finally hit a risk item and it blows up the whole project. Now that would be horrible, right? Think of all that lost time and money. Well, what if we hit that risk item in the first few weeks?

Well, we still hit the risk but now we didn't waste so much time and money. Now we can adjust the project based on the new information or we can even cancel it altogether if it's untenable anyways. All before we waste this time and money. And DevOps helps us in lots of other ways too. For example, consider scheduling. Now traditionally with two different groups, one for development and one for operations, scheduling would be quite complicated. One team depends on another. They have separate work backlogs and they aren't very collaborative. And sometimes you even have circular dependencies. So, managing that work across teams can be pretty tricky. Whereas a good DevOps implementation, scheduling is actually much more efficient. We have one team and one backlog. The management group provides DevOps team with the work item and the team can handle that item from beginning to end. So, that includes all the development, the deployment, and any needed back and forth. And all that gets handled internally by one team. In fact, it's much more efficient for the team to do it that way anyways.

That DevOps also helps to optimize development cycles. In fact, with DevOps, you're really optimizing how customers will be able to consume the project as it's being built. In the traditional model where the Dev and Ops teams are separated, there's a tendency to focus on big releases and that's simply because the interaction of the two teams is so inefficient. So, it's better to give a large release task to the Ops team on occasion than it is to give them many small tasks on a frequent basis. The result is that the customer sees a new version of the product every once in a while, in the traditional model. Whereas with DevOps the focus shifts to providing many small releases on a continuous and incremental basis. And that can be achieved because all the inefficiencies of having two groups have been eliminated. So, the DevOps team can produce iterative improvements of the product to the customer continuously.

So, you can probably guess from the benefits that we've gone through about DevOps so far that even task completion is improved through the use of DevOps. Now in the traditional development model, there's very little personal accountability. So, let's imagine a scenario. Let's say that there's a bug in the code that was released. Now 3:00 AM that bug is discovered by a user, who does user call? Well, they call the operations team. The Ops team can then escalate to the Dev team, but probably not until the work day starts. So, the Dev team doesn't feel the pain of that bug having come in at 3:00 AM. However, in the DevOps model, all of the team members accept accountability and they all feel the pain when a bug comes in at 3:00 AM because they can be contacted directly. Now that's an extreme example, but the point is that DevOps removes the separation between Dev and Ops and makes sure that the whole team is accountable. If somebody who's actually doing the development gets a call at 3:00 AM, you can rest assured they're going to increase their quality.

Now another thing I like about DevOps is the positive impact it has on success metrics. Now traditional development uses a cost and capacity model. That's really the only way to gauge success. Basically, what that model does is determine how much work can be done for a particular amount of cash. But because of the arrangements of teams, cutting costs and improving output can only go so far. Enter DevOps. Now with DevOps, we can add flow to the model. Things are much more streamlined and iterative. Suddenly, now we can improve output and suddenly now we can cut costs and that's simply because the team is so much more efficient that the more work is getting done. It's higher quality and it's costing us less to do it. And who can argue with that?

Now any good organization is going to be collecting data about their processes and their outputs. The intent of that data collection is to allow the organization to improve their processes and their outputs. And the traditional development model, the data we tend to use is complex and gathered from several different parties. The Ops folks, the support teams, and so on. This data is then generally all combined into wordy, lengthy documents that can be consumed by whomever is involved in the project. So, this means that we introduce bottlenecks not only in the gathering of that data but also in the consumption of that data. Now with DevOps, the whole process is optimized. Metrics are generally baked into the product because the Dev and Ops teams already understand what's required by the consumers. In fact, most of the time, the DevOps team is the consumer. So, any documentation that's produced is generally relevant to the point and even automated. In many cases, particularly in the cloud, DevOps teams will push metrics to central monitoring services where they can be consumed by anybody in real-time.

And finally, having a good DevOps process can drastically and positively impact your releases. In the traditional development model, releases are a big deal. As I said earlier, the traditional model tends to have large singular releases on an infrequent basis. The development team spends a bunch of time putting together a version of the software with a bunch of new features and then that gets passed on to the Ops team. The Ops team then tests and deploys the software and this requires lots of planning and sometimes even includes downtime. So, having a new release is a big deal for everyone involved. But DevOps solves that problem, particularly if you have a CI/CD implementation.

With DevOps, there's no more separation between Dev and operations. So, that efficiency means that releases can be streamlined and automated and that means that releases can actually be smaller and much more frequent. And that's the most common outcome. With the DevOps team, you'll get a continuous deployment model. So, your customers can see new features gradually over time. Don't believe me? Well, let me ask you this. What version is Google? What version is Facebook?