According to the good and the great, DevOps is the new reality for Operations. I mean everything is now virtual or encapsulated in light-weight containers. It is all about the App! In this article it is intended to have a brief look in to the rise of the movement that is now called DevOps, investigate where it came from, and where it is now and more importantly is it suitable for the future.
Big Dev, Little Ops
Today our view of DevOps is big DEV and little OPS, or to be more precise, people who have more a history of development than day to day operations, the focus is more on using code to deploy infrastructure, than using code to make day one and day two operations simpler. Focus has moved rapidly from making system administration simpler through orchestration and automation to the point where the concept of a virtual machine, container or application have been distilled down to several lines of code. Great examples of tools to help us do that are Terraform, PowerShell, Perl, Ansible, Chef and Puppet.
The venerable old art of System administration is now disparaged with the term Server-Huggers. We now have the concept of pets and cattle and CI/CD (continuous integration/continuous delivery) that are the new terms of the day.
DevOps terminology: – Pets v Cattle.
A Pet is a term give to a server that is nurtured, they may even have pet names, for example Zeus, Apollo, or Micky or Minnie, these machines are hand reared and are nursed back to health when sick. These systems are meant to live a long live with a specific purpose. The monitoring on them is for ailments and any issue will result calling in the vet (third and forth line support staff) to triage and cure them. It’s unthinkable, and even impossible, to tend to pets in an automated way. They’re just too much of a unique snowflake.
This is opposed to the concept of cattle. Here a machine, container or service is seen in an industrial farming sense. With this concept a system is identified by a utilitarian name like GZEW0001001 and not considered in an individual sense. It is part of a homogeneous pot of similar services. When they fail or fall ill they are culled from the herd, destroyed and replaced with a new version of the same service, be that a server, container or application.
Cattle is easier to be handled by automated, industrial systems for repetitive tasks, like feeding, waste disposal or milking.
DevOps terminology: – CI/CD
Continuous integration and continuous deployment (CI/CD) is another DevOps buzz phrase worth investigation.it is commonly identified by an infinity symbol.
The symbol is used to signify the life cycle of continuous improvement in the development cycle of a service, through lessons learned from each stage of the process. Which will ultimately lead to better software/services through each cycle, This also leads onto another phrase that of “Fail Fast – Fail Often”, personally I feel that is a bad phrase as it appears to promote mediocrity, and prefer the extended version “Fail Fast – Learn Fast – Improve Fast”. Code is code: it will have bugs and unintended consequences. The CI/CD cycle allows for quick turn around of deployments and the ability to rapidly correct issues.
CI/CD is the industrial system, analogous to the feeding, waste disposal and milking systems in cattle. CI/CD automate much of the day-to-day of the workloads with little variance among the flock.
But how did we get to DevOps and how were things before?
Now for a brief history lesson. Before the rise of DevOps the prevailing development methodology was called Waterfall. Under waterfall or waterfail as it was euphemistically known, we had major releases approximately every 2 years, these contained the vast majority of new features. Then we had minor releases, where they fixed everything that they had broke with the previous major release. This may sound harsh, but that did seem like the reality to those who worked in Operations.
This obviously leads to a lot of animosity between development teams and those teams that did day zero and onwards operations. many an argument was had about Developers just throwing their half finished code over the fence to the Operations team having to find missing libraries, drivers and even unknown and undocumented tcp ports, just to get the program up and running.
This often led to many long overnight working sessions, and a week of nurse-maiding and triage to keep it from falling over, whilst the developers fixed the issues found in production.
DevOps was an attempt to solve this crisis by merging development and operational teams to prevent the issues caused by the waterfall paradigm. It started with the concept of sprints, a defined set of work easily achievable over a much shorter period of time followed with a period of reflection to soak in the lessons learnt. This was to the benefit of both operations and developers.
This led to what I consider first DevOps revolution, Automation. By automating the process of deployment, it removed the possibility of human error. Virtualization was a key driver for the flexibility and responsiveness of the initial phase of DevOps at the time called automation. This in turn led to the development of software programs like Puppet. and then programming languages such as Terraform, from Hashicorp which codified the deployment of a virtual machine, container or service in a common format across multiple platform. GitHub (now owned by Microsoft) provided a clean and understandable environment for version controlling code and managing different code bases in a project.
Summary
To Sum up, it is safe to say that DevOps as a software delivery paradigm is well and truly ensconced in the industry psyche, but it is also safe to say that the original concept of what DevOps is or was has changed significantly, to those who are still firmly sat in operations it seems that the Developers have hijacked the process and have moved themselves into places that were once the preserve of operations.
However, it is correct to say that things are most definitely better now that the developers have been introduced to the trials and tribulations of operational methodology, servers, containers and applications are deployed with a lot less of the pain than under waterfall, is this the end state? Most definitely not and I refer you to the concept of CI/CD. There is always room for improvement.
