DevOps: What It Is and Why It Matters
Alvaro Oliveira, VP of Talent Operations at Toptal, recently published a fascinating insight into one of latest industry Best Practices:
DevOps: What It Is and Why It Matters
“Though there are no surefire, “silver bullet” methods for improving IT efficiency, DevOps has yielded results that are hard to ignore. As its name suggests, DevOps combines software development and software operations principles with the goal of helping organizations develop products with greater speed and efficiency. TIAA-CREF, for example, has seen its $40 billion business make significant improvements through using DevOps principles. An interview by TechBeacon with TIAA’s Chief Digital Officer, Scott Blandford, explains how TIAA moved from clunky, legacy software and systems to “an agile-based DevOps approach” that yielded a four-fold increase in development productivity. Updates are released far more quickly, and “IT has regained the trust that had eroded over the years as it began meeting user expectations.”
Results from the 2017 State of DevOps Report suggest striking differences between high performance organizations employing DevOps principles and organizations that do not. According to the report, high performance organizations have far higher software deployment frequencies (46 times more frequent), far faster lead time for changes (440 times faster), and a significantly lower software change failure rate (five times lower) than their lower performance counterparts.
Despite these significant benefits, DevOps stands as a classic example of an important, relatively new technical concept that has been misused or misunderstood all too often. For many, the idea remains fuzzy, and even a basic definition of DevOps can prove elusive.
This lack of clarity could potentially have negative effects on organizations and teams attempting to implement DevOps principles, causing strategic confusion and impeding the speed and efficiency that DevOps is supposed to promote. As a DevOps engineer at IBM said in an article published by InfoWorld, “We needed to answer some basic questions and determine the problems we were trying to solve…If you don’t know how the work is actually done, you don’t know which problems are worth solving.”
As software development and operations become more closely intertwined, and as companies become increasingly reliant on cloud infrastructure, executives and project managers must develop fluency in DevOps to remain competitive and ensure their teams are performing at their full potential.
DevOps should not be thought of as another vague buzzword, but rather as an important concept with the potential to dramatically improve products and businesses. This article, aimed at a relatively non-technical audience, aims first and foremost to clarify exactly what DevOps is. Using specific examples, this article will then explore what DevOps principles look like when done well, and why DevOps matters for you and your organization.
DevOps as a Type of Engineer, Culture, and Practice
What is DevOps? In a previous article published by Toptal, Demir Selmanovic writes that “DevOps is a culture, mindset, and it is part of IT as (a) whole.” He writes further that DevOps is a practice that enables organizations to optimize speed and efficiency across IT functions.
Amazon Web Services, which is the biggest player in cloud infrastructure and has accordingly developed significant DevOps expertise, uses a similar definition, saying that “DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.”
“DevOps people are basically those who have found interest in both systems administration and software development and decided to combine their skills to create a unified, better approach to both.”
These are both useful definitions for an audience already well-versed in related fields, but they may be too abstract for executives with less extensive technical backgrounds. Indeed, perhaps some of the confusion surrounding the definition of DevOps stems from the fact that it is often referenced simultaneously as a type of engineer, set of practices, and culture. While DevOps does encompass each of these elements, it is useful to begin by considering them separately.
To start with what a DevOps engineer looks like, Martin Chikilian, a software developer formerly for IBM and Hewlett Packard with over a decade of experience employing DevOps principles, puts it in simple, concrete terms: “DevOps people are basically those who have found interest in both systems administration and software development and decided to combine their skills to create a unified, better approach to both.”
They are able to maintain the servers, networks, and other types of infrastructure systems a company has, as well as actively iterate and improve on those systems through software development. As Chikilian said another way, “A DevOps person is someone who can leverage the foundations of software development to help themselves and companies build better tools to handle infrastructure.”
The “combination of cultural philosophies,” as Amazon puts it, refers to the combination of approaches used by software developers and those with infrastructure, or software operations, expertise. In breaking down the traditional barrier between these practices, a DevOps culture seeks to empower organizations to benefit from the distinct strengths that developers and infrastructure experts bring to the table. Successfully implementing DevOps principles “requires a change in culture and mindset” for companies that silo these different kinds of engineers. As Emily Dowdle describes at the 2016 Nordic API Platform Summit, removing barriers also helps alleviate the natural friction that can sometimes exist between developers and infrastructure experts and foster a more congenial, cooperative work environment.
Stated simply, DevOps is about translating complex manual processes involving error-prone human interaction into an instrumented approach that can be tested, measured, and easily scaled.
Armed with an understanding of what a DevOps practitioner and culture look like, what DevOps means as a practice becomes more apparent. Stated simply, DevOps is about translating complex manual processes involving error-prone human interaction into an instrumented approach that can be tested, measured, and easily scaled. For example, if a developer would like to create an environment that allows business users to provide feedback, he or she can initiate an automated process in which the developer can issue a command created by the DevOps team (rather than handing off a piece of code to the infrastructure team), which performs the relevant task in a consistent and tested way, getting to the expected results quickly and enabling collaboration.
A comprehensive definition of DevOps requires an understanding of what it means as a type of engineer, culture, and practice. Having explored what DevOps means from these perspectives, it is now important to delve into what DevOps looks like when successfully implemented.
Your DevOps Toolkit
In addition to the aforementioned cultural shift – going from a company that silos software developers and infrastructure experts to one that embraces their collaboration – companies need to understand a number of specific practices and tools crucial to DevOps. Below are three of the most crucial (though certainly not the only) of such practices:
Automation: Increased efficiency is central to DevOps, and this is significantly achieved through automating a range of relatively slow, onerous processes in software development and infrastructure maintenance. One specific example that Amazon cites is the practice of automatically sending out relatively small but frequent software updates. This practice takes the onus off of systems administrators, who might otherwise have to perform these updates manually. As Amazon notes, this practice also has the benefit of de-risking software deployment through enabling administrators to more easily catch and fix bugs that may arise. Automation is a cornerstone of DevOps and is crucial to the other DevOps practices discussed below.
Continuous Integration: On a fundamental level, DevOps is about close collaboration between engineers and, further, entire teams. Continuous Integration refers to the practice of engineers sharing and merging code in a central location. As Amazon explains, “In the past, developers on a team might work in isolation for an extended period of time and only attempt to merge their changes… once their work was completed.” Through Continuous Integration, engineers can more efficiently collaborate and avoid the bottlenecks associated with developing and integrating their code in a more piecemeal fashion.
Continuous Delivery: Continuous Delivery refers to the practice of automatically delivering and implementing software product changes as they’re made. In other words, Continuous Delivery is enabled by Continuous Integration, given that changes to code can only be effectively pushed to the entire system if the code is already housed in a central place. Automation is also crucial to Continuous Delivery. Indeed, the aforementioned example of sending small, frequent systems updates can also be thought of as an example of Continuous Delivery. Continuous Delivery enables organizations to implement changes and improvements quickly, and it allows engineers to focus their time more efficiently on other, complex issues.
Please find the complete article here.
Please get in touch with us: