The term DevOps is ubiquitous and is considered a hallmark of a good development program. In this article, I’ll share my personal experiences and observations of why DevOps is important and the cases where it may not be worthwhile.

What is DevOps? How does it differ from DevSecOps?

In its most basic form, DevOps is team which builds the deployment pipeline for software as its being developed. One of the key attributes is it must be automated, i.e., a change is made by a developer and the process deploys the change within minutes.

DevSecOps is adding the “Security” aspect to the DevOps process. A traditional DevOps pipeline may run some automated tests to validate a build before deployment. DevSecOps adds security validation which is most likely going to run some API validation, scan for viruses in 3rd party libraries, etc.

DevOps is the process of automating push-button deployments with some baseline validation. DevSecOps adds the Security validation to the process.

For brevity, I will use the term DevOps for the rest of this article. However, I encourage teams to add the Security component to the pipelines as soon as possible.

It’s important to note that the DevOps process will vary wildly based upon the complexity of the application and its deployment. Building a standalone application with standard packaging will be much easier than deploying a Cloud SaaS with multi-region disaster recovery.

What are the Benefits of DevOps?

To fully understand this, you need the context of how software used to be developed. In the past, there was a build engineer and they would take the source tree and make some form of distribution package. Since the process was complex, developers would not run through the process themselves, they would simply “patch” the baseline. The result was that each developer had their own private version of the software. This made releasing software difficult because you had to reconcile the incompatible changes between the versions.

Before DevOps, developers would have their own version of the “patched” release. DevOps creates a much more coordinated and streamlined process.

Since DevOps is automated, it’s much easier for developers to push a button and stay current with their team. A change in which one developer adversely affects the other members of the team is now caught much sooner!

Another benefit is that deployments are automated which means they are consistent. Customers are able to have a better experience when software is upgraded.

In Cloud environments, you need to control Identity Management, Networking, Compute Resources, etc. Except for very simple applications, it is practically impossible to deploy software without a good deployment pipeline.

DevOps and the Cloud

As noted above, it is impossible to have a modern Cloud Application without a DevOps pipeline. Teams which do not have a good DevOps team end up with very regulated release cycles, e.g., once a month or once a quarter.

Given the rapid rate of change, releasing software on a quarterly basis may no longer be good enough. Moving to a DevOps model allows you release software on a weekly or daily basis.

Having a good DevOps team really enables you to take advantage of the full capabilities of the Cloud. Assuming the software can support it, you can build out highly-available applications across multiple geographic locations and potentially across different Cloud Vendors.

Why doesn’t everyone have a solid DevOps process?

In my opinion, every new software project should have DevOps resources assigned, even if its a part-time role for one team member. Building the automated pipeline as the software is being developed will result in quicker development cycles. Additionally, if you can automate the software and security validation, you will have a process which is very efficient and good quality!

Since people have to be assigned for the project, the DevOps process is a constant cost for the project. It is important to recognize that building an automated pipeline is a skill and takes time, especially when the project begins. This time and cost needs to be accounted for in the planning stages.

For new applications, good DevOps will pay for itself in terms with faster releases of better quality!

The only valid exception for a good DevOps process is when you are working with legacy technologies. Older technologies simply weren’t designed for automation. You can generally automate large parts of the build and deploy for legacy applications, but it’s virtually impossible to get to complete end-to-end automation. A lot of resources will be spent on trying build automation into legacy components.

For legacy applications, there is much higher cost for DevOps. The team will have to decide if the investment is worthwhile depending on the shelf-life of the application.

Looking Forward

As the Cloud evolves and the requirements around uptime and security increase, the software development process will become more complex. DevOps is an important part of managing that complexity.

Over time, we will see DevOps add new components to match the needs of the customer. The current trend, which is here to stay, is to add Security automation. Undoubtedly, we will see more components added to the DevOps process over time.

Welcome to WordPress! This is your first post. Edit or delete it to take the first step in your blogging journey.