What is DevOps?

What urged me to write this article:

1. This year I have been involved in 8 or 10 projects as a Configuration Manager (another strange word) and could see that not all of our customers understand what DevOps is and how you can benefit from implementing DevOps practices.
2. Over the last 3 months I have been taking part in selecting candidates for positions of Intern DevOps Engineer and Middle DevOps Engineer, and questions related to DevOps culture have caused the applicants most difficulties.
3. I’ve been asked to )

It is very likely that after reading this article the readers might feel a certain dissonance between what they have read and what the DevOps Engineer is doing on their team. Still, the DevOps culture is more about interactions than about tools, continuous integration or vertical or horizontal scaling of servers.

This article will tell about nothing but DevOps culture. My next article might be about something more familiar – about DevOps engineers.

So, What Exactly is DevOps?

The classic definition goes as follows:

DevOps (a compound of English words ‘development’ and ‘operations’) is a set of practices aimed at active interaction of software development specialists with software operation and maintenance specialists as well as integration of their working processes into one another. It is based on the idea of close interdependence of development and operation of software and is intended to help companies to create and update software products and services faster.

It is believed that the DevOps movement was born in 2009 as an association of many adjacent and complementary communities: Velocity Conference, with brilliant talks of John Allspaw and Paul Hammond “10 Deploys A Day”, an “Infrastructure as code” approach (Mark Burgess and Luke Kanies), “Agile infrastructure” (Andrew Shafer) and “System administration in Agile” (Patrick DeBois), “Lean Startup” approach of Eric Ries with his idea of continuous integration, as well as a wide availability of cloud and PaaS technologies.

To put it simply, DevOps is a culture that can create a consistent and logical proactive networking system of all participants involved in development-testing-implementation-operation of a big system or service.

In an ideal world, this system would look something like this:

Implementation of this methodology adds one more abstract level to company management (synchronization and coordination of all stages of building your large team).

This approach can be shown as the following graph:

Initially, DevOps had nothing to do with a specific job in a company. Many still claim that DevOps is not a job title, but a culture, which ensures the closest communication between all participants of a project.

But, as time goes, DevOps has naturally moved from concepts of “culture” and “ideology” to a list of “jobs”. The number of vacancies with this word in the title is growing rapidly. DevOps are expected to have a wide range of skills, such as system administration, programming, using cloud technologies, and automation of a large infrastructure.

This means that it’s not only necessary to know programming, but also to understand the operation of networks, operating systems, virtualization, to be able to provide security and fault tolerance, along with a dozen of other skills: from basic and time-tested iptables and SELinux to fresh and trendy Chef or Docker technologies.

What DevOps is for

Transition to DevOps is intended to decrease the number of conflicts, which arise when developers are oriented at meeting business needs, adding new functions, and increasing usability of applications, while maintenance and support specialists are traditionally focused on reliability and security of IT system functioning. Therefore, developers must be taught about operations, and maintenance specialists – about faster and more efficient satisfaction of business needs.

The main technical concept of DevOps is the following: as processes of infrastructure interaction become automated during development, testing, deployment and monitoring, companies can remove many operational defects and improve development and operation processes. In practice, the main questions are which tools should be used and what resources are worth investing in each given area of DevOps.

“DevOps Cookbook” and “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” describe the cornerstone “Three Ways” principles all the DevOps patterns can be derived from:

The First Way emphasizes the performance of the entire system as opposed to the performance of a single team or department.

The focus is on all business value streams that are enabled by IT.

The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback, so that necessary corrections could be made continually.

The Third Way is about creating a culture that fosters two things: continual experimentation that requires taking risks and learning from failure, as well as understanding that repetition and practice is the prerequisite to mastery.

According to many customers, the value of the described approach is that it allows to get the big picture of the development model, including all interested parties, clearly defined processes, and integration mechanisms.

DevOps Implementation

There is no single sure way to implement DevOps. The fact that a company has its own successful DevOps strategy does not mean at all that the same processes will allow to implement DevOps practices as successfully in another environment. An enforced “injection” of processes and instruments into a certain environment can lead to additional isolation and resistance to changes.

DevOps encourages critical thinking in approach to processes, instruments, and practices. A self-learning company requires surveys and iterative process analysis. Doing this, the company should not blindly rely on statements about “the only true way” or “all this has already been done for us”.

DevOps methodology is not a set of rigid rules like in Scrum or ITIL. Companies that have been the most successful in implementing DevOps did this through creation of comfortable conditions for learning and iterative search for the most efficient tools and processes.

Therefore, it makes no sense to say something like “DevOps technology has been implemented successfully” because “we do up to 10 deployments per day”. Attention should be paid not to numbers, but to specific problems that you are trying to solve in your company. You should think about why certain changes are made, and not about the number of deployments or other arbitrary metrics.

According to Patrick DeBois, DevOps is a purely human issue. It means that each company shapes its own DevOps culture unique for people who are a part of it.

Although there is no “true for all” way of implementing DevOps in all companies, we can identify four basic common components:

– Cooperation – the process of reaching a set goal by several people working together.

– Proximity – the process of forming relationships between teams, which contributes to the freedom of setting goals or indexes while keeping to the main company goals.

– Tools – a stimulant of change, implemented based on the current goals and culture*.

* It is important to understand how to select tools correctly and how they affect existing structures, in order to avoid emergence of underlying and hidden problems in teams and companies. If the selected tools (or their absence) hinder work of certain team members, the initiative of DevOps implementation will be doomed to fail.

 – Scaling focuses on processes and driving forces that companies must use during their entire life cycle.

Using these four keys to efficient DevOps methodology, you can remove cultural and technical problems that affect the process of software development.

Conclusion: DevOps is the responsibility of the entire team.

DevOps as the responsibility of the whole team means the interaction of all players. If someone is resisting, especially developers, the intended result will not be achieved.

All players are responsible for the success of transforming their previous model into a more efficient one, which will, in the long run, bring higher profit and protect against loss.

• #Cloud Solutions
• #DevOps Outsourcing