Finding the essence of DevOps can be challenging. We have gathered vivid analogies, striking phrases, and expert advice that will help even non-specialists grasp the core. As a bonus, weâll include insights from Red Hat's own DevOps team.
The term DevOps emerged 10 years ago, evolving from a hashtag on Twitter to a significant cultural movement in the IT worldâa true philosophy that encourages developers to achieve results faster, experiment, and progress through iterations. DevOps has become inextricably linked to the concept of digital transformation. Yet, as often happens with IT terminology, over the years, DevOps has accrued numerous definitions, interpretations, and misconceptions.
Because of this, questions like, is DevOps the same as agile? Or is it a specific methodology? Or is it just another synonym for âcollaborationâ? are frequently heard.
DevOps encompasses many different concepts (continuous delivery, continuous integration, automation, etc.), so pinpointing the main idea can be difficult, especially if you are passionate about the subject. However, this skill is very useful, whether youâre trying to convey your ideas to management or simply explaining your work to family or friends. Therefore, let's set aside the terminological nuances of DevOps for now and focus on the bigger picture.
What is DevOps: 6 Definitions and Analogies
We asked specialists to explain the essence of DevOps as simply and concisely as possible, so that its value becomes clear to readers of any technical background. From these discussions, we selected the most vivid analogies and impactful phrases that will help you articulate your narrative about DevOps.
1. DevOps is a cultural movement
âDevOps is a cultural movement in which both sides (software developers and IT systems operations specialists) recognize that software is of no real benefit until someone uses it: customers, clients, employeesâregardless of who,â says Eveline Oehrlich, a senior research analyst at the DevOps Institute. âTherefore, both parties work together to ensure fast and high-quality software delivery.â
2. DevOps empowers developers
DevOps empowers developers to own applications, manage their deployment, and oversee the delivery process from start to finish.
Usually, DevOps is talked about as a way to accelerate application delivery to production through the establishment and implementation of automated processes, says Jai Schniepp, Director of DevOps Platforms at Liberty Mutual. But for me, it's a much more fundamental concept. DevOps empowers developers to take ownership of applications or specific parts of software, oversee their deployment, and manage the delivery process end to end. DevOps removes confusion regarding responsibilities and leads all participants in the process toward creating an automated, developer-managed infrastructure.
3. DevOps is collaboration in the creation and delivery of applications.
Simply put, DevOps is an approach to software production and delivery where everyone works together, notes Gur Staf, President and Head of Digital Business Automation at BMC.
4. DevOps is a pipeline.
Pipeline assembly is only possible if all the components fit together.
I would compare DevOps to an automobile assembly line, continues Gur Staf. The idea is to design and create all parts in advance so that they can be assembled without individual adjustments. Pipeline assembly is only possible if all components fit together. Those who design and build the engine must consider how to attach it to the body or frame. Those who make the brakes must think about the wheels, and so on. The same should apply to software.
A developer creating business logic or a user interface must think about the database that holds customer information, the security measures to protect user data, as well as how everything will function when the service starts catering to a large, possibly multi-million audience.
"Getting people to collaborate and think about the parts of the work done by others, rather than focusing solely on their own tasks â that is the greatest obstacle to overcome. If this can be achieved, you have a great chance for digital transformation," adds Gur Staff.
5. DevOps is the right combination of people, processes, and automation
Jayne Groll, Executive Director of the DevOps Institute, offered a great analogy for explaining DevOps. According to her, "DevOps is like a recipe with three main categories of ingredients: people, processes, and automation. Most of these ingredients can be drawn from other areas and sources: Lean, Agile, SRE, CI/CD, ITIL, leadership, culture, tools. The secret of DevOps, just like any good recipe, lies in how to properly proportion and mix these ingredients to enhance the speed and effectiveness of work in creating and releasing applications."
6. DevOps is when developers work like a Formula 1 team
"The race is planned not from start to finish, but rather from finish to start."
"When talking about what to expect from DevOps initiatives, I often refer to a NASCAR or Formula 1 racing team," says Chris Short, Senior Marketing Manager for Cloud Platforms at Red Hat and publisher of the DevOpsâish newsletter. "The leader of such a team has one goal: to achieve the best possible finish given the resources at their disposal and the challenges they face. The race is planned not from start to finish, but from finish to start. First, an ambitious goal is set, and then the paths to achieve it are defined. After that, they are broken down into sub-tasks and delegated to team members."
"All week before the race, the team refines their pit stops. They engage in strength and cardio training to be in shape for the grueling race day. They practice collaborative actions to address any issues that may arise during the race. Similarly, development teams should train for frequent releases of new versions. With such skills and a well-established security system, launching new versions into production happens more often. In this worldview, increased speed means increased security," says Short.
"It's not about doing the 'right things,' adds Short, "but about removing as many obstacles as possible to achieve the desired outcome. Collaborate and adapt based on the real-time feedback you receive. Be prepared for anomalies and work on improving quality to minimize their impact on reaching your goals. This is what awaits us in the world of DevOps."
Scaling DevOps: 10 Tips from Experts
Basic DevOps and large-scale DevOps are entirely different things. We will discuss how to overcome barriers on the path from the former to the latter.
For many organizations, the journey to DevOps begins easily and pleasantly. Small passionate teams are created, old processes are replaced with new ones, and initial successes come quickly.
Unfortunately, this is merely a false shine, an illusion of progress, as Ben Grinnell, managing director and leader of the digital technology sector at consulting firm North Highland, puts it. Early wins are certainly encouraging but do not help achieve the end goal, which is widespread adoption of DevOps within the organization.
It is easy to see that a culture of division forms, creating a distinction between 'us' and 'them.'
"Organizations often launch pioneering projects, believing they will pave the way for widespread DevOps, without considering whether others will want to follow this path," explains Ben Grinnell. "Teams implementing such projects are typically composed of self-assured 'mercenaries' who have done similar work elsewhere but are new to your organization. They are encouraged to break and disregard rules that remain mandatory for everyone else. It's easy to see that this results in a culture of division into 'us' and 'them,' which hinders knowledge and skill transfer."
"This cultural issue is just one reason why scaling DevOps is challenging. DevOps teams face a surge of purely technical complexities typical of rapidly developing companies that have bet on IT technologies," says Steve Newman, founder and Chairman of Scalyr.
"In todayâs world, services change as soon as the need arises. Constantly implementing and deploying new features is, of course, great, but coordinating this process and resolving emerging issues is a real headache," adds Steve Newman. "In very fast-growing organizations, engineers on cross-functional teams struggle to maintain their ability to track changes and the cascade effects they generate at the dependency level. Moreover, engineers are far from pleased when they are deprived of this ability, making it harder for them to understand the nature of emerging problems."
How can we overcome the challenges described above and move towards widespread adoption of DevOps in a large organization? Experts advise being patient, even if your ultimate goal is to accelerate the software development cycle and business processes.
1. Remember that cultural change takes time
Jayne Groll, Executive Director of the DevOps Institute: In my opinion, the expansion of DevOps should be as gradual and iterative as agile development (and equally impact culture). Both Agile and DevOps emphasize small teams. However, as the number of teams grows and integrates, more people apply new work methods, resulting in significant cultural transformation.
2. Allocate enough time for planning and platform selection
Eran Kinsbruner, Chief Technical Evangelist at Perfecto: To make scaling work, DevOps teams must first learn to blend traditional processes, tools, and skills, and then slowly cultivate each individual DevOps phase and stabilize it. Everything starts with careful planning of user stories and value stream flows, followed by the software writing and version control phase using trunk-based development or other approaches best suited for branching and merging code.
Then comes the integration and testing phase, where a scalable platform for automation is required. Itâs important for DevOps teams to choose the right platform that matches their skill levels and project goals.
The next phase is deployment in a production environment, which should be fully automated using orchestration and container tools. It is crucial to have virtualized environments at all stages of DevOps (production environment simulator, quality control environment, and the actual production environment) and to always use the most recent data for testing to obtain accurate insights. Analytics should be intelligent and capable of processing large volumes of data with quick and actionable feedback.
3. Free accountability from a blame culture
Gordon Haff, Evangelist at RedHat: Creating a system and atmosphere that allows and encourages experimentation enables the implementation of what are known as successful failures in agile software development. This does not mean that no one is held accountable for failures anymore. In fact, it becomes easier to identify responsibility, as "being responsible" no longer means "being the one at fault". Thus, the essence of accountability changes qualitatively. Four factors become extremely important: the scale of the failure, approaches, production processes, and incentives. (You can read more about these factors in Gordon Haff's article "DevOps lessons: 4 aspects of healthy experiments.")
4. Clear the path forward
Ben Grinnell, Managing Director and Head of Digital Technologies at consulting firm North Highland: "To achieve scaling, I recommend launching a 'path-clearing' program alongside pioneering projects. The goal of this program is to remove the debris left behind by DevOps pioneers, such as outdated rules and other similar things, to keep the path ahead clear."
"Give people organizational support and build momentum through communication that goes far beyond the group of pioneers, broadly celebrating the successes of new ways of working. Train the individuals involved in the next wave of DevOps projects who are anxious about using DevOps for the first time. And remember, these individuals are very different from the pioneers."
5. Make tools more democratic
Steve Newman, Founder and Chairman of Scalyr: "Tools should not be hidden from people, and they need to be relatively easy to master for anyone willing to invest the time. If the ability to request logs is granted to only three people 'certified' to use a certain tool, you will always have a maximum of three individuals capable of dealing with the corresponding issue, even if you have a very large computing environment. In other words, this creates a bottleneck that can have serious (business) consequences."
6. Create ideal conditions for team work
Tom Clark, Head of Common Platform at ITV: You can do anything, but not everything at once. Therefore, set big goals, start small, and move forward with quick iterations. Over time, you will build a reputation as a team that gets things done, which will encourage others to adopt your methods. Don't chase after building a high-performing team. Instead, create the ideal conditions for people to work, and effectiveness will come naturally.
7. Don't forget Conway's Law and Kanban boards
Logan Daigle, Director of Software Delivery and DevOps Strategy at CollabNetVersionOne: It's important to understand the implications of Conway's Law. In my loose interpretation, this law states that the products we create and the processes we use, including DevOps, end up being structured similarly to our organization.
If an organization is highly fragmented, and the management of software planning, creation, and release frequently changes hands, the effect of scaling will be zero or short-lived. However, if the organization forms cross-functional teams around products that are funded with a market orientation, the chances of success significantly increase.
Another important aspect of scaling is to display all work in progress (WIP) on Kanban boards. When there is a place in the organization where people can see such things, it greatly encourages collaboration, positively impacting scaling.
8. Look for old scars
Manuel Pais, DevOps consultant and co-author of the book 'Team Topologies': Taking DevOps practices beyond just Dev and Ops and attempting to apply them to other functions is hardly an optimal approach. While it will certainly yield some effect (for example, through automation of manual management), much more can be achieved by starting with an understanding of delivery and feedback processes.
If there are old scars in an organization's IT systemâprocedures and management mechanisms that were implemented as a result of past incidents, but have lost relevance (due to changes in products, technologies, or processes)âthen they should certainly be removed or smoothed out, rather than automating ineffective or unnecessary processes.
9. Donât create variants of DevOps
Antony Edwards, the Production Director at Eggplant: DevOps is a very vague term, which means that each team ends up with its own version of DevOps. Thereâs nothing worse than having 20 varieties of DevOps in an organization, which donât get along well with each other. Itâs unacceptable for each of the three developer teams to have its own unique interface between development and product management. Similarly, products shouldn't have their own unique expectations regarding feedback processing when transitioning to a production-like simulation environment. Otherwise, you'll never manage to scale DevOps.
10. Advocate the value of DevOps to the business
Steve Newman, Founder and Chairman of Scalyr: Work on recognizing the value of DevOps. Learn and donât hesitate to share the benefits of what youâre doing. DevOps saves an incredible amount of time and money (just think: less downtime, shorter mean time to recovery), and DevOps teams must continually emphasize (and advocate for) the importance of these initiatives for business success. This way, you can expand the base of supporters and strengthen the impact of DevOps within the organization.
BONUS
At On September 13, our own DevOps will arriveâyes, at Red Hat, as a software manufacturer, we have our own DevOps teams and practices.
Our engineer Mark Birger, who develops internal automation services for other groups across the organization, will share his story in plain Englishâhow the Red Hat DevOps team migrated applications from virtual environments managed by Ansible in Hat Virtualization to a full container format on the OpenShift platform.
But that's not all:
After organizations migrated workloads to containers, traditional application monitoring methods may not be effective. In the second report, we will explain our motivation for changing our logging approach and showcase the ongoing journey that led us to modern logging and monitoring practices.
Source: habr.com
