With the 2018 “State of DevOps” report telling us that those who implement the practice enjoy software delivery times that are 2,555 times faster, its clearly worth the time to learn more about it and how to implement it in your own organization.
The simplest and most understandable definition of DevOps can be drawn from the two words it is a compound of, development and operations. As we move along you may find it useful to change the question “What is DevOps” to “What can we achieve by adopting a DevOps culture?”
In the earliest days of computer programming, a programmer produced the code necessary to have the computer perform specific functions. That code was presented to the computer operations team who loaded it and ran it. If something went wrong, those computer operators really had no idea how to fix it, so they returned the code to the developers to make corrections. As you can imagine, this could become very time-consuming very quickly, and did.
DevOps celebrates the value of collaboration, communication, and integration making them the three main principles of this ever-growing, modern approach to software delivery. In this case, it’s collaboration between the developers of the software and the operators of the hardware. They come to share methodologies and tools working as a single united team.
Here lies perhaps the greatest source of confusion in the continuing development of the DevOps movement.
Earlier, we pointed out that DevOps has been an outgrowth of Agile Development which has also spawned the development of several agile methodologies including Scrum, Kanban, Lean, and Extreme Programming. The majority of people don’t fully understand yet what DevOps is, and even more don’t understand the relationship between DevOps, Agile, Lean, Scrum, and others.
Most simply, is the overarching umbrella for many iterative and incremental software development methodologies. While each of these has its own unique approach, they all share the same vision, values, and principles described earlier in the Agile Manifesto. They all feature constant iteration and the continuous feedback required to continue to refine and deliver better software faster.
DevOps is exploding. That’s easy to say, but just looking at the sheer number of major companies that are embracing it, the volumes of books and articles being written, the vast selection of companies springing up that “specialize” in training, consulting, or even outsourced execution of DevOps initiatives proves it. The DevOps evolution rivals that of cloud computing and the Internet of Things.
With all of that we are still clearly at the rising front side of the bell curve heading toward a level of maturity that will eliminate the less-qualified contenders and emphasize the strongest players.
The types of companies that can benefit from DevOps span the gamut from cloud service providers, to toolmakers, to testing automation platforms, team coding collaboration platforms, project tracking systems, microservice containers, software-defined-everything providers, dedicated toolchains, source code management, code segment repositories, provisioning and deployment automation solutions, Agile facilitators, Lean facilitators, Scrum facilitators, and more.
The failure of users to adopt any new platform is often cited as the underlying cause behind three-quarters of new initiatives. Given that DevOps requires deeper commitment by a broader variety of people than most platforms or methodologies, nowhere is it more critical to pay close attention to the active promotion of adoption than it is when transitioning to DevOps.
Users and even executives cite several reasons why they fail to adopt a DevOps culture-shift. Many suggest that other technology and business initiatives are higher priority to them than DevOps. Some point to a shortage of resources impacting the decision to change. Some simply don’t see value in making such a comprehensive change.
DevOps is still in the process of being defined, and everyone has their own interpretation. While many “best practices” can be suggested, it is to each reader to determine what is “best” in their particular environment. As such, the following are suggestions for your consideration.
Most people resist change, especially when it comes to the culture they are accustomed to living in. While implementing DevOps involves humanistic change for the better, it’s still change. Always remain sensitive to the natural resistance you will encounter and find ways to overcome it gently and productively. While you’re at it, work at removing any “blame game” tendencies in your existing culture as you make your changes.
Especially in larger organizations, you may find it valuable to create a central, dedicated DevOps unit which creates and/or owns all of the DevOps tools and is tasked with implementing Agile methodologies in each of the development groups.
The concept of joining development and operations people together supported the goals of DevOps:
“Improve collaboration between all stakeholders from planning through delivery and automation of the delivery process in order to:
This is accomplished by implementing and adhering to a straightforward lifecycle of activities:
The result is an iterative cycling creating constant improvement with far shorter update cycles that accelerate time to market while making it far easier to identify and correct deficiencies should they occur. That iterative DevOps lifecycle repeats constantly:
From the monitoring, we learn what we need to know to return us to being agile and beginning the next plan. Jez Humble, one of the founding developers of DevOps and author of The DevOps Handbook, points out that “DevOps is not a goal, but a never-ending process of continual improvement.”
Just about everything is benefitting from automation these days, and DevOps is no exception. As with most process-driven environments, automation enables speed, scale, consistency, and feedback. All four are critical to the success of an iterative constant-improvement environment like DevOps.
Every manual process that is automated enjoys significant increases in speed, so the more automated processes the faster the overall engine becomes. Add to this a dramatic reduction or elimination of user errors.
Many manual processes simply cannot scale because humans cannot execute the necessary tasks quickly enough to complete them in the time allotted. As data entities grow larger, the need for automation grows along with them. Automated systems have far greater elasticity, so additional resources can be provisioned as they are required to accommodate scale.
Automated processes execute exactly the same way every time they execute. They do not vary. They are not subject to external conditions such as mood, distraction, or other human elements. Consistency of operations brings control, which reduces risk and adds speed.
In a well-automated environment, software can request feedback from users while they are using it. Many information-gathering efforts happen with greater assurance and consistency when they are automatically executed. This feedback in turn informs the next round of changes needed which contributes powerfully to the goal of achieving constant improvement.
With the DevOps movement exploding, and with so many different disciplines being incorporated into it, the list of available tools is enormous. Here is a list of those found listed on various “Top 10”, “Top 30” and other lists:
|New Relic APM||Bamboo||Gradle||OverOps||Behat|
A DevOps practice doesn’t necessarily need tools, and is certainly not defined by them, but given that the goal is accelerated release of constantly improving software, anything that speeds up the processes inherent in DevOps is, by definition, a good thing.
One thing you should note after reviewing the previous list of just what are considered the top tools in the DevOps world, is that part of your evaluation must determine how well each of the tools you select work with the other tools you select. Combining tools that work well together results in the creation of a DevOps toolchain which is simply defined in Wikipedia as “a set or combination of tools that aid in the delivery, development, and management of applications throughout the systems development life cycle, as coordinated by an organization that uses DevOps practices.”
This may seem obvious, that DevSecOps includes the security team with the development team and the operations team all working together, but a deeper understanding of why, is of definite benefit to your planning and operating processes.
In 1983, the International Standards Organization (ISO) introduced a useful seven-layered model for networked computing called the Open Systems Interconnection (OSI) model.
Moving outward from the user, data is entered into the network through software running on the Application layer. This application is running on a device-based operating system at the Presentation layer which is signed in through the Session layer. Data is moved from that user to another destination by the Transport layer which uses the Network layer to connect to that destination. This connects to the actual network via a network interface card at the Data-Link layer which, finally, connects to the actual cabling and wireless infrastructure at the Physical layer.
Arriving at the other end, the data travels back up the seven layers to arrive at its intended destination. Each layer has its own protocols and other communication standards that govern its efficient operation.
So, you may be asking, where is the Security layer? Where does security fit in?
The answer is “Yes.”
Great DevOps engineers are hard to find, even harder to hire away from their current employment, and most likely compensated far beyond most budgets. So how does an organization enthusiastic to launch their DevOps initiative with complete and total buy-in at all levels avail themselves of the services of such a valuable resource?
Cloud computing has taught us that there isn’t very much that you can do yourself that you can’t have done for you by an external resource. DevOps is no exception. New DevOps consulting companies are emerging with astounding rapidity. So much so, in fact, that the challenge comes in selecting the right one rather than finding them.