DevOps does more than just combining Agile development concepts with IT operations. DevOps streamlines the process of developing and deploying apps in cloud environments in such a way that it actually shortens the development life cycle by a significant margin. This is why DevOps became very popular as an approach to development.
Even today, DevOps sits at the heart of most optimised pipelines. Continuous delivery becomes the norm rather than a goal to achieve. Apps are developed in iterations and new updates get pushed to the cloud with a partial or entire environment replaced with zero down. Even large multi-part updates are more manageable thanks to DevOps.
As far as combining software development and IT operations go, however, the term DevOps is not alone. There have been many variations and sub genres of DevOps—and modifications of the concept—and they are widely adopted by different software development teams. For many, DevOps lays the foundation for good processes across teams—including automation. But to improve on the methodology, a team may adopt one or more of the main approaches below—as most of these considered are adaptations that attempt to achieve a ‘better’ DevOps Culture.
So, what are the other ‘Ops’ to consider? And how do they compare to DevOps?
The approach behind NoOps is to automate IT infrastructure in a way that negates the need for an in-house team for operational purposes. In this approach, all maintenance and similar tasks of an operations team are fully automated to such a level that means no manual intervention in the process is required.
NoOps has a similar intent 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 as it works on the assumption that if the developers have automated tools and processes, they don’t need to know about the nuts and bolts of how to use them.
To achieve this, part of the approach ‘relieves’ developers of all infrastructural concerns to gain more value from cloud computing. As with DevOps, this is to prevent them from time-consuming tasks that involve all the interactions with an IT operations team over infrastructure issues.
In NoOps, developers should not need to trouble themselves about resources and their distribution, as this is where the cloud steps in. After product completion, the cloud provider will also run further operations, monitoring, and maintenance. The NoOps model uses Continuous Integration techniques to allow developers to focus only on application development.
When organizations began opting into NoOps, many thought that it would be the end of DevOps. But in reality, DevOps has evolved and NoOps is not a fool-proof process, even though it speeds up the deployment process. I would caution against adopting NoOps in isolation because it lacks process and team management, and open communication typically leads to better results and productivity.
From the names of these two approaches, it is easy to believe that the two have one major difference: the integration of security into the pipeline. However, I’d argue they are one and the same concept. If DevOps is the reduction of ‘work in progress’ (WIP), then the natural progression is to bring security further in the pipeline. This approach is mostly useful if you need to promote or elevate the security concern of your organization for a number of factors.
DevSecOps takes the traditional DevOps approach and adds additional security checks, code verifications, and deep testing into the workflow. Rather than having security be an issue at the end of the cycle, DevSecOps integrates security from the beginning of the workflow.
The two have similarities and similar major advantages. Both DevOps and DevSecOps allow for greater automation of the CI/CD pipeline. As long as speed and delivery are at the top of the priority list, DevOps and DevSecOps will continue to leverage automation at different parts of the workflow.
The two also rely on the process being run continuously with the help of communication and collaboration. Team communication is a crucial part of maintaining agility and delivery speed. Collaboration between developers, security specialists, and ops are also crucial.
As mentioned before, the big advantage offered by DevSecOps compared to the more traditional DevOps is its way of shifting security to the left. However, DevSecOps is often slower in delivery. DevSecOps also sacrifices fast testing and short pipelines for better code integrity.
GitOps is another popular branch of DevOps that has been gaining traction this past year. As the name suggests, GitOps focuses more on using Git as a way to automate the rest of the continuous delivery pipeline. With Git as the single source of truth, GitOps is perceived as more robust and more manageable in the long run.
There are, arguably, some potential advantages of implementing GitOps. For starters, every developer is familiar with Git and pull requests, so integrating GitOps as a way to speed up delivery is an easy process. There is no complicated tool to master. Changes to the workflow are not always needed.
GitOps is also supported by some of the best cloud services on the market. Tools like AWS CodePipeline and AWS CodeBuild are designed to work with Git tools, which means automating the process of building an update, testing for errors, reviewing code, and pushing that update to the production environment is very easy to do.
GitOps also offers a detailed set of audit tools and the ability to roll back an update at any point. This is because Git acts as the primary source of every update, which means the entire pipeline can also rely on Git logs for easy audit. However, with Git as the only source of truth, it is necessary to sufficiently fortify your Git repository to avoid unnecessary commits or pull requests.
In simple words, GitOps is a subset of DevOps designed to take advantage of Git’s strong suits. As a result, most GitOps workflows rely heavily on Kubernetes as the primary containerization runtime.
Next, we are going to take a closer look at ITOps. Many developers see ITOps as the more conventional version of DevOps, but it is actually more than that. ITOps is very similar to DevOps in many ways. The approach views software development and IT infrastructure management as one unified pipeline, plus it also tries to improve that pipeline and push for higher agility.
ITOps differs from DevOps in how it manages IT infrastructure. This is where ITOps is actually more traditional in that it is in charge of delivering and maintaining services, applications, and the underlying technologies necessary to run a business. ITOps generally covers job titles including system administrator, network administrator, and your service desk.
Instead of advocating agility and aiming for speed, ITOps focuses more on stability and long-term reliability. IT infrastructure is handled as the foundation of a successful pipeline, so it is not surprising to see the approach be viewed as more rigid when it comes to infrastructure management.
ITOps best practices lean more towards reliable, highly-tested commercial software and solutions for constructing the infrastructure—including hardware as ITOps tends to focus on physical servers and networks. Commercial-off-the-Shelf software or COTS are often found in ITOps pipelines.
The higher rigidity of the approach also means updating infrastructure components is more difficult. ITOps puts stability as the top priority, so quick changes to how the cloud or on-premise environment are configured is not always possible. ITOps does work well though with on-premise deployments of apps and services.
None of this means that ITOps is obsolete. There are industries that rely heavily on ITOps for long-term sustainability, such as banking and the financial industry in general. Fast, sudden changes are not always needed in these industries, which makes ITOps the more logical approach for continuous delivery.
People may think DevOps can’t be realized in these types of environments because they’re not cloud-based. This isn’t the case though, the reduction of WIP and lower siloing can still happen on bare metal.
While ITOps shifts infrastructure towards a more conventional side of the equation, CloudOps does the opposite. Once again, the approach is very similar to DevOps, but with a shift in focus when it comes to infrastructure management. As the name suggests, CloudOps tries to take more advantage of cloud-native features offered by modern service providers like Amazon.
CloudOps takes three things as its primary ingredients: distribution, stateless, and scalability. Distributed development and deployment mean there is no single point of failure. The whole cloud environment becomes more reliable, and uptime can be maintained. At the same time, the ability to go stateless—at least in certain parts of the workflow—is a huge plus for cost-efficiency.
By being stateless, scalability is not an issue. You only pay for the resources you actually use—and for the duration that you use them—so cloud-related overhead costs can be brought down to a minimum with a little fine tuning. Cloud-native applications deployed using the CloudOps approach tend to have good uptime and low latency.
The advantages are further amplified by the level of automation that cloud service providers now offer. Nevertheless, the approach requires resource provisioning to be fully automated, which could mean added complications when it comes to configuring your CI/CD pipeline. You have to get the configuration right in order to fully benefit from CloudOps.
Continuous Integration Ops (CIOps) is the last branch on our list. CIOps require CI operators or administrators to configure the IT infrastructure required to support the new codes before deployment continues. The CI system is designed to run build and tests then deploy at varying levels of sophistication according to the complexity of the pipeline.
Since manual inputs are still required (to ensure that each CI job is configured correctly to deploy to the right location), CIOps offer both advantages and disadvantages. The primary advantage is granular control over the infrastructure itself. Two deployments can have different infrastructure configurations, as opposed to predefined parameters found in approaches like GitOps.
Manual configuration of a cloud environment and the provisioning of resources can make CIOps more suitable for smaller developments; development projects where automation is more of a hassle than a useful instrument. This is why CIOps is commonly found in smaller projects with simpler cloud infrastructure.
However, the major disadvantage here is the very manual concept of this system as you increase the risk of human error. You also need to provide your CI tool of choice (Travis CI and CircleCI are popular) to your API which is a big security risk.
Compared to DevOps, CIOps also lacks a comprehensive audit trail and extra flexibility. The approach focuses on CI rather than CI/CD, so it doesn’t always cover the process from end to end. While it gives developers some flexibility in configuring their cloud infrastructures, it takes a great deal of diligence to run CIOps smoothly over a longer period of time.
As you can see, there are multiple branches and subsets of DevOps, and they are all based on unique approaches and interesting ideas. As far as speeding up your CI/CD cycle, any approach discussed is incredibly useful. Choosing between them is a matter of finding an approach that works best for the kind apps you develop and the cloud infrastructure you use.
That said, DevOps still offers the most comprehensive approach for improving your workflow since it tackles both technical processes synchronously with the adoption of cultural improvements. Both are equally important in a successful transformation. The above approaches tend to focus on the technical side only. Some are even focused on a particular platform, a way to manage infrastructure, or specific tools.
At the end of the day, that is exactly why DevOps is still the most widely implemented approach of them all. It is a tried and tested method of creating an efficient and technically-improved CI/CD pipeline while supporting an environment of innovation and collaboration.
Cherre is the leader in real estate data and insight. We help companies connect and unify their disparate real estate data so they can make faster, smarter decisions. Contact us today to learn more.
Stefan Thorpe▻ VP of Engineering @ Cherre ▻ Cloud Solutions Architect ▻ DevOps Evangelist
Stefan is an IT professional with 20+ years management and hands-on experience providing technical and DevOps solutions to support strategic business objectives.
You’re barraged by real estate data sales pitches every day. Buzzwords like AI, Moneyball, or Bring-Your-Own-Data Visualization layers. But you rarely hear about implementations that drive ROI. That’s because most sales pitches are bullsh*t.
“The World As a Service: A peek into the future technology is creating.”
You won’t want to miss James Whittaker’s keynote at the inaugural Cherre Data Summit on May 19 in NYC: “The World As a Service: A peek into the future technology is creating.”
14 reasons your data project has failed (including reasons you’ve never heard before)
By Raj Bhatti, SVP Client Solutions
Twenty-five years ago was the first time I heard a senior business leader say,
