DevOps and Its Friends -- Talk about other "Ops" (Part 1) - Weekly Sharing

Summary : The term DevOps is not unique when IT comes to combining software development and IT operations. For many, DevOps lays the foundation for good processes, including automation, across teams. But to improve the methodology, teams can adopt one or more of the following significant approaches -- since most of the approaches considered are tweaks to achieve a "better" DevOps culture.

DevOps combines agile development concepts with IT operations and simplifies the process of developing and deploying applications in the cloud, resulting in a significantly shorter development life cycle. That's why DevOps is famous as a development method.

Even today, DevOps is at the heart of most optimization pipelines. Continuous delivery becomes the norm, not the goal. Application development is iterative, with new updates pushed to the cloud, replacing part of the entire environment with Zero Down. Even extensive updates are easier to manage, thanks to DevOps.

However, the term DevOps is not unique when IT comes to combining software development and IT operations. There are many variations, subtypes, and conceptual modifications widely adopted by different software development teams. For many, DevOps lays the foundation for good processes, including automation, across teams. But to improve the methodology, teams can adopt one or more of the following significant approaches -- since most of the approaches considered are tweaks to achieve a "better" DevOps culture.

So, what are the other "Ops" to consider? How do they compare to DevOps?

DevOps vs. NoOps

The approach behind NoOps is to automate the IT infrastructure in a way that does not require an internal team to operate. In this approach, all maintenance and similar tasks for the operations team are fully automated, meaning no manual intervention in the process is required.

The intent of NoOps is similar to DevOps in that it focuses on fully automating tools and infrastructure to improve software deployment. However, it focuses less on agile and process management because it assumes that developers have automated tools and processes and don't need to know the nuts and bolts of how to use them.

To achieve this goal, part of the approach "alleviates" all infrastructure concerns for developers, thereby getting more value out of cloud computing. As with DevOps, this prevents them from performing time-consuming tasks that involve all interactions with the IT operations team on infrastructure issues.

In NoOps, developers don't have to worry about resources and their distribution because that's where the cloud comes in. After the product is complete, the cloud provider will run further operations, monitoring, and maintenance. The NoOps model uses continuous integration techniques to focus solely on application development.

When organizations started choosing NoOps, many thought this would be the end of DevOps. But in reality, DevOps has evolved, and NoOps is not a foolproof process, although it speeds up the deployment process. I would caution against adopting NoOps in isolation, as it lacks process and team management, and open communication generally leads to better results and productivity.

DevOps vs. DevSecOps

Given the names of the two approaches, it is easy to believe that there is one significant difference between the two approaches: the integration of security into the pipeline. However, I think they are the same concept. If DevOps reduces work-in-progress (WIP), the natural progression is to improve security in the pipeline further. This can be useful if you need to upgrade or elevate your organization's security concerns for multiple factors.

DevSecOps takes the traditional DevOps approach and adds additional security checks, code validation, and in-depth testing to the workflow. DevSecOps integrates security from the beginning of the process, rather than making it an issue at the end of the cycle.

There are similarities and similar main advantages. Both DevOps and DevSecOps allow greater automation of CI/CD pipelines. As long as speed and delivery are at the top of the priority list, DevOps and DevSecOps will continue to leverage automation in different parts of the workflow.

Both also rely on processes that run continuously with the help of communication and collaboration. Team communication is a critical part of maintaining agility and speed of delivery. Collaboration between developers, security experts, and operations is also critical.

DevOps vs. GitOps

GitOps is another popular offshoot of DevOps that has received much attention over the past year. As the name suggests, GitOps is more focused on using Git to automate the rest of the continuous delivery pipeline. With Git as the sole source of data, GitOps is considered more robust and manageable in the long run.

Source: Liquibase

Arguably, there are some potential advantages to implementing GitOps. For starters, every developer is familiar with Git and pull requests, so integrating GitOps to speed up delivery is a simple process that doesn't require mastery of complex tools or constant workflow changes.

GitOps is also backed by some of the best cloud services on the market. Tools like AWS CodePipeline and AWS CodeBuild are designed to use Git tools, which means the process of automatically building updates, testing for errors, reviewing code, and pushing updates into production is easy to implement.

GitOps also provides a detailed set of auditing tools and the ability to roll back updates at any time. This is because Git is the primary source of each update, which means that the entire pipeline can also rely on Git logs for simple audits. However, since Git is the only source of facts, it is necessary to secure the Git repository sufficiently to avoid unnecessary commits or requests.

In short, GitOps is a subset of DevOps designed to take advantage of Git's powerful strengths. As a result, most GitOps workflows rely heavily on Kubernetes as their primary containerized run-time.