Understanding DevOps and the Dos and Don’ts of it
“Devs are from Venus, Ops are from Mars” – Steven Haines
DevOps as a term is the space that establishes itself where a Venn diagram consisting of three separate terms intersect. DevOps can be defined as a compound term that consists of software development, software operations and the allied quality assurance that oversees these two domains. A relatively new term when compared to the origins of software, DevOps as an organizational core value has rapidly ensconced itself in corporations globally. This is so because a functionality like this is needed for software development as creating a software product per se is a complex process which essentially is carried out by a number of internal teams, even if the product is a prototype or a pseudo.
Parellely, software operations work on their own priorities without any knowledge of what is happening with the development part. At the end, when it comes to deployment, operations and development reach an impasse because the conclusions of these two domains become extremely tedious to merge. This problem was noticeable for industry stalwarts who specialize in Agile methodologies in software development, hence inventing a brand new term in 2008, which we now know as DevOps. DevOps integrations have helped companies automate a major number of vital ancillary processes that are required for software development. Furthermore, applying DevOps capabilities have helped shorten development cycles, increased software deployment frequencies and helped customers rely on software releases. Hence, it has been successful so far in creating a win-win scenario by satisfactorily delivering on customer expectations that are in conjunction with business objectives.
Any proven methodology achieves its own credibility and DevOps is no different. DevOps has managed to penetrate most software enterprises, globally and will be embraced by a rising number of companies in the future. Internal DevOps implementation is not a mysterious process, but stakeholders need to be conscious of what needs and what doesn’t need to be inculcated for a successful DevOps rollout, in order to churn out an industry ready and robust software product.
“DevOps is not a Goal, But a never-ending process of continual improvement” – Jez Humble
DevOps Dos and don’ts
The thumb rule of DevOps is to integrate software operations and development. Always focus on this to be the primary reason for its implementation. Do not designate one entire team just for DevOps because this team eventually does not deliver business value. Instead, do find a DevOps expert that can assess its progress step by step till the conclusion of a pilot DevOps project. DevOps will always be an ongoing transition that requires precise planning to excel at every step. An organization should ideally start off with a smaller project and help it succeed before getting into avenues in a business that is at the core of revenue generation.
For organizations that are just starting off to absorb DevOps, they should be aware of what their end-goal would be via its methodologies. Most enterprise stakeholders make the mistake of competing with software behemoths that speak proudly about visible changes that DevOps brought into their success stories. Although inspiring in theory, practical implementations are only possible by realistic goals. When sketching a DevOps roadmap, enterprises may consider working backward as an experiment to try and figure out if this may just be a better way to inculcate the technology into daily operations.
Since DevOps is responsible to combine the Holy Trinity of Software Development, Software Operations and Quality Assurance, that are fundamentally all opposite in functional nature, enterprises should really not look for immediate results. Visible results will only appear at the end of the project and initial phases of combining siloed departments will be a challenge. But to truly measure success, engineers and supervisors that are responsible for specific departments should get all their numbers in place before and after DevOps was implemented. Post DevOps and at project conclusion, the visible numbers would definitely be better than what they looked like prior to project conclusion without DevOps.
The most important thing here is to not be over-ambitious and immediately start off with converting a pre-established organizational model into a DevOps model. This would serve as a recipe for chaos. Lethargic but important areas in business can initially be ignored and only very dynamic projects should be fully DevOps enabled. Even if an organization is being consulted by a technological evangelist, there would be several failures on the road of DevOps. This is expected, and the important point is to understand the mistake and try not to replicate it as the DevOps story progresses.
DevOps – Six use cases
Dealing with contracts and signatures, Docusign’s first steps in DevOps adoption were not easy, to say the least. Although DocuSign always developed in Agile their biggest challenges were elements such as continuous integration and delivery. Since the core nature of their business is signatures and approvals, a slight mistake such as misattribution could possibly ruin their entire operation. Hence to cope up with modern development speeds, the company leveraged on a tool known as an application mock. Thanks to this tool, DocuSign was able to integrate critical functionalities such as incident management. They were also able to extensively test their application with simulations that very nearly as good as real life exchanges between signatures and approvals.
Forter’s operation is similar to DocuSign, that of lightning-fast exchanges. Forter put a large impetus to the fact that issues arising through their application should heal on their own which is driven by a robust Incident Management System. Forter’s DevOps capabilities filter common issues and subsequently attempt to auto-resolve such identified issues. Hence DevOps facilitated Forter not just in addressing issues but also in preventing them all together in the future.
Students leverage Turnitin’s platform to improve their writing. By adopting DevOps the company could continuously monitor database performance, the most critical aspect of its business. DevOps also helped manage Turnitin to recognize normal and abnormal spikes, keep a check on backend response time and most importantly respond to abnormal spikes in their Database Server.
Commercial end users, as well as software developers, use Gengo’s translation platform for application integration. For Gengo, adapting to DevOps meant smart monitoring, optimized applications and freeing up a lot of time of its core team so that they can innovate.
Etsy is one of the biggest practitioners of DevOps. They reshuffled the entire organization to fit into the DevOps model. Etsy understood very early that company culture, recruitment regimens, and general employee motivation would contribute to the long-term change process. DevOps was leveraged on the strategic end by Etsy in reference to the cross-pollination of teams and transparency in policies along with clarity for everybody.
Netflix is hailed as the epitome of DevOps adoption — ensured that Netflix always runs on maximum horsepower. Their poster boys are single-handedly their detailed architectures and their vigilantism about their Cassandra database never going kaput. Netflix spends a hell lot of time testing their databases before they release anything. Although, backends are not tested so rigorously, mostly only after several releases and under finite scenarios.
Deployment celebrations should be about the value of the new features, not joyful relief that nothing went horribly wrong – Rebecca Parsons
Statistically, so far, software enterprises that have fully absorbed DevOps into their mainstream claim that they are seeing a 60 percent higher ROI coupled with profits. The technology is allowing them to grow their businesses at 20% annually, 2.4 times more than their archrivals that do not have these capabilities yet. This tiny statistic re-enforces the present day importance of adapting to Development Operations. In a world where business models have become very dynamic, keeping up the pace with the competition is close to lethal. Every day presents an invention of a newer feature or facet on the technology front.
With DevOps, an entire organization works on a homogenous level helping them to communicate effectively amongst teams. This, in turn, gets changes done quickly, so that an organization can keep up with the competition. Hence, if the Dos and don’ts are religiously followed, the technology would be the foundation of a brighter enterprise future.
Artificial Intelligence is integrating into the enterprise’s operational mainstream very fast. DevOps so far has been fairly alien as a concept when it comes to integrating with AI. Technological evangelists are constantly on the look-out for the best possible ways to marry AI with Development operations. However, DevOps is a vast subject which is entirely customizable for an organization’s immediate and future challenges. Artificial Intelligence will have a role to play in the near future for sure. However, the idea seems far off, at least for now.
On paper, industry stalwarts speak about immediate integration of AI into DevOps to simplify basic challenges that enterprises face very often. One aspect is certain though, which is the integration will unfold a whole new world of Information Technology possibilities which were not imagined before. Ultimately, stakeholders won’t be surprised if the entire organizational structure is designed to behave and function autonomously.
Read More: The Artificial Intelligence Week