Any holistic approach to how DevOps is to be implemented into real life is unavailable. DevOps is not a methodology. This is rather a branch of the post-industrial philosophy dedicated to digital environments. It is on the rise now since many software development teams are trying to accommodate DevOps to their workflows.
Due to a lack of the clear “how-to” manuals, the DevOps agenda is balancing on the edge of uncertainty. The least advanced practice suggests rather a cumbersome method of transforming developers into system administrators and vice versa. Another approach offers to create a separate and independent “DevOps engineer” basing on somebody’s private ideas and biases.
How to recognize a kernel of truth in a mess of speculations? What is worth learning to make DevOps magic work? And would it be really justified to rename a sysadmin having coding skills to a DevOps engineer?
Mixing Molotov cocktail
The corporate pipelines, infrastructure, and deployment patterns are always vulnerable to chaotization when DevOps appears in the organizations where development and operations are separated with a wall. DevOps enthusiasts strive to ruin the wall while intracompany conservators come to lament and sigh “Why?
Everything has been running well…” And the latter are right in many cases since the labor division is invented for a reason. DevOps is not for everyone. Small teams having rather infrequent deploys can do fine without a deep integration of development and operations. However, large organizations with a prolific production will not be able to get away from DevOps. Look at Google with two billion builds a day. Can you imagine their efficient workflow with a wall between developers and operation engineers?
Thus, the original question before diving deep in DevOps is to be “Do we really need to shake developers and sysadmins mixing them in a DevOps cocktail?” Don’t rush into answering it, because this would result in the Molotov cocktail able to ruin not only the separating wall. It can destroy the entire infrastructure wounding both teams by the shrapnel of frustration.
Let’s …. our infrastructure!
What should any self-respecting sysadmin do for being sleeping in peace every night? Any reputable system administrator would provide the production servers with the automated self-maintenance. It’s a sane idea indeed. However, the original sysadmins hardly ever possessed the sufficient coding skills providing the entire infrastructure with full automation. In such a case two possible approaches dominate - either inviting developers to join the assignment or assigning a sysadmin to learn coding.
They are not the same being both DevOps-like actually. Both approaches come to rather hybridization instead of cooperation. Even though they result in operational automation to some extent, nothing would drastically alter the staff structure. Hence, the far-reaching outcomes improving a day-to-day workflow can hardly be expected.
And the reason is because both approaches have no any strong philosophical concept at their core. The concept that allows a DevOps leader not looking like an idiot while urging the team with “Guys, let’s goddamn destroy our infrastructure!”
The very ability to make teammates feel comfortable when they destroy and rebuild the entire stack can distinguish a true DevOps leader from the rest. Any other acceptance of such practices can just mimic DevOps when developers and administrators compose a group of fellows stochastically bouncing around servers.
Tools matter, but they differ
In order to move from the philosophy to technology, every organization embarking on the path of DevOpization should arrange the workflow in a manner when nothing is provisioned manually. And here an ambivalent technical method may appear. Trying to get rid of the infrastructure challenges many teams use cloud services where servers are provisioned independently.
This is fashionable, easy, and rather cheap. Besides, it has a workable analog with databases. However, the deploying servers via Ansible or through other configuration management systems leave infrastructure static and a significant part of provisioning manual. It can be admitted as semi-DevOps. Another matter is the pure DevOps technologies such as Jenkins, Docker, or Artifactory. They require time and efforts from staff. They require learning.
Besides, they push organizations to accept containers and microservices as the agenda on default. Nonetheless, the tooling offers DevOps engineers a unique experience impossible within a traditional paradigm. And namely these technologies provide IT teams with continuous integration, fully automated infrastructure maintenance, and the deployment speed accelerated by an order of magnitude.
Transition to DevOps remains a private business of each individual organization. Pros and cons, slogans and mottos, living examples and theorization all are just occasions for reflection. Nonetheless, DevOps has appeared as a phenomenon, and no one could ignore it. Nothing hints at the disappearance of the practice soon afterward.
And even though DevOps gains only a partial popularity, Indeema may anticipate DevOps will take its rightful place among 5 sigma, Agile, SaaS and other efficient systems and practices.