Is it hard to get the point when talking about DevOps? We have collected for you vivid analogies, striking formulations and advice from experts that will help even non-specialists get to the point. At the end, the bonus is Red Hat's own DevOps.
The term DevOps originated 10 years ago and has gone from a Twitter hashtag to a powerful cultural movement in the IT world, a true philosophy that encourages developers to get things done faster, experiment and move forward through iteration. DevOps has become inextricably linked with the concept of digital transformation. But as is often the case with IT terminology, over a decade, DevOps has managed to acquire a lot of definitions, interpretations and misconceptions about itself.
Therefore, you can often hear questions about DevOps like, is this the same as agile? Or is it some special methodology? Or is it just another synonym for the word "collaboration"?
DevOps includes many different concepts (continuous delivery, continuous integration, automation, etc.), so it can be difficult to isolate the main thing, especially when you are passionate about the subject. However, this skill is very useful, whether you are trying to convey your ideas to your superiors or just talking about your work to someone in your family or friends. Therefore, for now, we will put aside the terminological nuances of DevOps and focus on the big picture.
What is DevOps: 6 definitions and analogies
We asked experts to explain the essence of DevOps as simply and concisely as possible, so that its value becomes clear to the reader with any level of technical training. As a result of these conversations, we have selected the most striking analogies and punchy language to help you build your story about DevOps.
1. DevOps is a cultural movement
“DevOps is a cultural movement in which both parties (software developers and IT systems operators) recognize that software does not bring real value until someone starts using it: customers, customers, employees, not the point,” says Eveline Oehrlich, Senior Research Analyst at the DevOps Institute. “Therefore, both of these parties jointly provide fast and high-quality software delivery.”
2. DevOps is what empowers developers
"DevOps empowers developers to own applications, run them, and manage delivery from start to finish"
“DevOps is usually talked about as a way to speed up the delivery of applications to production by building and applying automated processes,” says Jai Schniepp, director of DevOps platforms at insurance company Liberty Mutual. “But for me it's a much more fundamental thing. DevOps empowers developers to own applications or certain pieces of software, run them, and manage delivery from start to finish. DevOps removes the liability confusion and leads everyone involved in the process towards an automated and developer-driven infrastructure.”
3. DevOps is about collaboration in building and delivering applications
“Put simply, DevOps is a collaborative approach to manufacturing and delivering software,” said Gur Staf, President and Head of Digital Business Automation at BMC.
4. DevOps is a pipeline
"Conveyor assembly is only possible if all parts fit together."
“I would liken DevOps to a car assembly line,” continues Gur Staf. “The idea is to pre-design and make all the parts so that they can then be assembled without custom fitting. Conveyor assembly is only possible if all parts fit together. Those who design and build the engine must think about how to mount it to the body or frame. Those who make brakes should think about wheels, and so on. The same should be true for software.
A developer who creates business logic or a user interface must think about the database that stores customer information, about security measures to protect user data, and how all this will work when the service begins to serve a large, perhaps even multimillion-dollar audience of users.
“Getting people to collaborate and think about the parts of the work that others do, rather than focus solely on their own tasks, is the greatest hurdle to overcome. If this succeeds, you have excellent chances for digital transformation,” adds Gur Staf.
5. DevOps is the right combination of people, processes and automation
Jayne Groll, Executive Director of the DevOps Institute, has a great analogy to explain 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 taken from other areas and sources: Lean, Agile, SRE, CI/CD, ITIL, leadership, culture, tools. The secret of DevOps, like any good recipe, is how to properly proportion and mix these ingredients to increase the speed and efficiency of creating and releasing applications.”
6. DevOps is when programmers work like a Formula 1 team
"The race is planned not from start to finish, but on the contrary, from finish to start."
“When talking about what to expect from a DevOps initiative, I use the example of a NASCAR or Formula One racing team,” says Chris Short, general manager of cloud platform marketing at Red Hat and publisher of the DevOps'ish mailing list. - The head of such a team has one goal: to take the highest possible place at the end of the race, taking into account the resources available to the team and the trials that fell to its lot. At the same time, the race is planned not from start to finish, but, on the contrary, from finish to start. First, an ambitious goal is set, and then ways to achieve it are determined. After that, they are broken down into subtasks and delegated to team members.
“All week before the race, the team perfects the pit stop. Does strength and cardio to keep fit on a grueling day of racing. Works out joint actions in solving any problems that may arise at the race. Similarly, the development team should practice the skills of releasing new versions frequently. With such skills and a well-established security system, the launch of new versions in production also occurs more often. In this mindset, more speed means more safety,” says Short.
“It's not about doing the 'right thing',” adds Short, “but about eliminating as many things as possible that get in the way of the desired result. Collaborate and adapt based on the feedback you receive in real time. Be prepared for anomalies and work on improving the quality to minimize their impact on the movement towards the goal. This is what awaits us in the DevOps world.”
How to Scale DevOps: 10 Tips from the Experts
It's just that DevOps and mass DevOps are completely different things. We will tell you how to overcome the barriers on the way from the first to the second.
For many organizations, the path to DevOps starts easy and pleasant. Small passionate teams are being created, old processes are being replaced by new ones, and the first successes are not long in coming.
Alas, it's just a false glare, an illusion of progress, says Ben Grinnell, managing director and head of digital at consulting firm North Highland. Early victories are certainly encouraging, but do not help achieve the ultimate goal, namely, the massive use of DevOps in the organization.
It is easy to see that as a result, a culture of division into “us” and “them” is formed.
“Often organizations launch these pioneering projects thinking they will pave the way to mass DevOps without considering whether or not others will be able or willing to do so,” explains Ben Grinnell. – Teams for the implementation of such projects are usually recruited from self-confident “Varangians” who have already done something similar in other places, but are new to your organization. In doing so, they are encouraged to break and destroy the rules that remain binding on everyone else. It is easy to see that as a result, a culture of separation between “us” and “them” is formed, which prevents the transfer of knowledge and skills.
“And this cultural issue is just one of the reasons why DevOps is difficult to scale. DevOps teams are facing an increase in the purely technical complexity of high-growth IT-based companies,” said Steve Newman, Founder and Chairman of Scalyr.
“In today's world, services change as soon as the need arises. Constantly implementing and introducing new features is great, of course, but coordinating this process and fixing problems that arise is a real headache,” adds Steve Newman. “In very fast-growing organizations, engineers on cross-functional teams struggle to keep track of changes and their cascading effects at the dependency level. Moreover, engineers are not at all happy when they are deprived of this opportunity and, as a result, it becomes more difficult for them to understand the essence of the problems that arise.
How to overcome these difficulties described above and move to the massive use of DevOps in a large organization? Experts urge you to be patient, even if your ultimate goal is to speed up the software development cycle and business processes.
1. Remember that culture changes take time.
Jayne Groll, Executive Director, DevOps Institute: “In my opinion, scaling up DevOps should be as incremental and iterative as agile development (and culturally impactful in equal measure). In Agile and DevOps, the emphasis is on small teams. But as the number and integration of such teams grows, we get more people using new ways of working, and as a result, a large-scale cultural transformation occurs. ”
2. Spend enough time planning and choosing a platform
Eran Kinsbruner, Lead Technical Evangelist at Perfecto: “For scaling to work, DevOps teams first need to learn how to combine traditional processes, tools, and skills, and then slowly nurture and stabilize each individual phase of DevOps. It all starts with careful planning of user stories (userstory) and value streams (valuestream), after which comes the stage of writing software and version control using trunk-based development or other approaches that are most suitable for branching and merging code.
“Then comes the integration and testing phase, where a scalable automation platform is already required. And here it is important for DevOps teams to choose the right platform that would meet their skill level and the end goals of the project.
The next phase is production deployment and should be fully automated using orchestration tools and containers. At the same time, it is important to have virtualized environments at all stages of DevOps (production environment simulator, quality control environment, and production environment itself) and always use only the latest data for tests in order to receive up-to-date conclusions. Analytics need to be smart and able to process big data with fast and actionable feedback.”
3. Get rid of the taste of guilt
Gordon Haff, RedHat Evangelist: “Creating a system and atmosphere that allows and encourages experimentation allows for so-called successful failures in agile software development. This does not mean that no one else is responsible for failures. In fact, it becomes even easier to identify who is responsible, because "being responsible" no longer means "causing an accident." That is, the essence of responsibility is qualitatively changing. In doing so, four factors become critical: the scale of the disruption, approaches, manufacturing processes, and incentives.” (For more on these factors, see Gordon Huff's DevOps lessons: 4 aspects of healthy experiments.)
4. Clear the way forward
Ben Grinnell, managing director and head of digital at consulting firm North Highland: “In order to achieve scaling, I recommend launching a “clearing the way” program with pioneering projects. The purpose of this program is to clean up the garbage left behind by DevOps pioneers, like outdated rules and stuff like that, so that the path forward is clear.”
“Give people organizational support and momentum through communication that goes far beyond the pioneering group by widely celebrating the successes of new ways of working. Coach people who are involved in the next wave of DevOps projects and are nervous about using DevOps for the first time. And remember that these people are very different from the pioneers.”
5. Make the tools more democratic
Steve Newman, Founder and Chairman of Scalyr: “Tools shouldn't be hidden from people, and they should be relatively easy to learn for anyone willing to put in the time. If only three people "certified" to work with a particular tool are allowed to request logs, you will always have a maximum of three people able to deal with the corresponding problem, even if you have a very large computing environment. In other words, this creates a bottleneck that can lead to serious (for business) consequences.”
6. Create the perfect team environment
Tom Clark, Head of Common Platform at ITV: “You can do anything, but not all at once. So set big goals, start small, and move forward in rapid iterations. Over time, you'll build a reputation as a team that gets things done, so others will want to use your methods too. And don't chase after building a high-performing team. Instead, give people the perfect working environment and efficiency 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 is important to be aware of the implications of Conway's law. In my loose retelling, this law states that the products we create and the processes we use to create them, including DevOps, are arranged in the same way as our organization.
“If there is a lot of silos in an organization, and when planning, building, and releasing software changes hands many times, the effect of scaling will be zero or short-lived. If an organization forms cross-functional teams around products that are funded in a market-driven way, then the chances of success increase dramatically.”
“Another important aspect of scaling is to display all work in progress (WIP, workinprogress) on kanban boards. When there is a place in an organization where people can see these things, it encourages great collaboration, which is good for scaling.”
8. Look for old scars
Manuel Pais, DevOps consultant and co-author of Team Topologies: “Bringing DevOps practices outside of DevOps itself and trying to apply them to other functions is hardly the best approach. This will undoubtedly have some effect (for example, by automating manual control), but much more can be achieved if you start with an understanding of the delivery and feedback processes.
“If there are old scars in the organization's IT system - procedures and management mechanisms that were implemented as a result of past incidents, but have lost their relevance (due to changing products, technologies or processes), then they certainly need to be removed or smoothed out, rather than automating inefficient or unnecessary processes.”
9. Don't breed DevOps options
Anthony Edwards, Director of Operations at Eggplant: “DevOps is a very vague term, so each team gets its own version of DevOps. And there's nothing worse than having 20 different DevOps in an organization that don't play well together. It is impossible for each of the three development teams to have their own, specific interface between development and product management. Just as it is impossible for products to have their own, unique expectations in terms of handling feedback when they are transferred to a production environment simulator. Otherwise, you will never be able to scale DevOps.”
10. Promote the value of DevOps for business
Steve Newman, Founder and Chairman of Scalyr: “Work on recognizing the value of DevOps. Learn and feel free to talk about the benefits of what you do. DevOps is incredibly time- and money-saving (just think: less downtime, shorter MTTR), and DevOps teams must relentlessly emphasize (and preach) the importance of these initiatives to business success. This way you can expand the circle of adherents and increase the influence of DevOps in the organization.”
BONUS
On the Our own DevOps will fly in on September 13 - yes, Red Hat, as a software manufacturer, has its own DevOps teams and practices.
Our engineer Mark Birger, who develops internal automation services for other groups throughout the organization, will tell his own story in pure Russian - how the Red Hat DevOps team migrated applications from Hat Virtualization virtual environments managed by Ansible to a full container format on the OpenShift platform.
But that's not all:
Once organizations have moved workloads into containers, traditional application monitoring methods may not work. In the second talk, we will explain our motivation for changing the way we log and show the continuation of the path that led us to modern logging and monitoring methods.
Source: habr.com