For a long time, the term “Devops” has emerged in the forums, articles, white pappers, blogs, websites specialized and coffee breaks. The superficial concept of DevOps is easy to understand. The word “DevOps”, in some way, is self-explanatory. But explain what it is, in fact, it is another story.
In 2008, the mailing list on Google “Agile System Administration” created by Patrick Debois and Andrew Shafer talked about infrastructure management using agile methodologies. In the same year, at Agile Conference in Toronto, he spoke about “Agile Infrastructure and Operations”, available here. In 2009, Paul Hammond, director of engineering at Flickr, gave the lecture “10+ Deploys per Day:. Dev and Ops Cooperation at Flickr” on O’Reilly Velocity Conference in San Jose, which Debois watched via live stream and decided to hold the DevOpsDay in Ghent, Belgium.
The word itself comes from the junction of two words widely used and easily identifiable in the IT world: Development and Operations. Refer to different stages of the software life cycle: the creation and use, respectively.
The definition, according to Debois, “in the last few months, a movement has begun to take shape. It’s a movement of people who think it’s time for change in the IT industry – time to stop wasting money, time to start delivering great software, and building systems that scale and last. This movement is being called Devops.”
Why? For what?
The idea came about due to an almost ubiquitous difficulty in companies where the development team (DEV) is completely separated from the operations team (OPS).
This separation is not only because they are different teams. It is also because they are teams with little communication and understanding. With different concerns. With misaligned objectives to be almost antagonistic.
|Want to deliver new requirements, new features, new bugfixes.||Wants to ensure stability (which can be seriously compromised by new features).|
|They have determined and never large enough deadlines to perform all the tasks satisfactorily.||It have to keep everyting working by a time (almost always) undetermined.|
|Focused product (developed software).||It is focused on service (monitoring, backup, provisioning, etc.).|
|It is reactive. It's corrects registered issues.||It is proactive. Monitoring, analysis, forecasting incidents.|
|Create innovation for the product.||Optimal use of resources.|
Okay, but after all: What actually is DevOps?
By definition of the creator of the term we see that DevOps is not just about tools. Or processes. Or communication between the teams. It’s about all these things! It’s a way to think, to act, to create, to document, maintain and also to roll out the software.
It is mainly a way of thinking and acting. Devops is always reminding people to think about software, not only in his team or himself. If for all people care about the entire software life cycle and not only with the project or the development or operation. According to Lori MacVittie: “DevOps is not something you build, is something you do”.
It is necessary to understand that, although they are at different teams (development and operation), the software is the same. And the goals must be aligned. DevOps stands that a team think about the other:
- System administrators should participate in the development phase;
- What has been developed can not disrupt the operation. Quite the opposite! Should assist the operation;
- The data obtained in operation should serve as input for developers to improve the functioning of the software;
- Developers must create documentation that is useful in the operation.
The Devops tools
Generally, DevOps culture has its main focus on tools. This is so important that in many situations DevOps is confused with just adopting collaboration tools, integration and automation tasks.
But there are several types of tools used under Devops’s flag. The following software categories are cited more often in the Devops subject:
- Log analysis
- Application Performance Monitoring (APM)
- Builds and testing automation
- Network Emulation
- Infrastructure Configuration Management
- Continuous Integration
- Repository files
- Security Event Management (Siem)
But there is no clear definition of what tools are not of DevOps. In fact, any tool that automates tasks or generate collaboration can be considered a DevOps tool. However, if you look well, almost all existing tools fit this description.
In the future we will talk about each of these tools categories, understanding better the common features of each one. But just to reinforce: tools should be only part of DevOps and not the whole.
Devops is a culture that aims to make different teams in IT integrate and help each other to ensure that the application life cycle happens , as best as possible in the most effective and low cost way possible.
This integration between the teams should be so consistent that often some skills and knowledge of the teams merge, such as developers thinking about performance and system administrators participating in development.
Collaboration and sharing of responsibilities are also fruits coming from DevOps culture, making teams work closer to each other, sharing the moments of tension and also each of the small victories.
The adoption of DevOps culture gives us more complete professionals, more communication between the teams, more efficient teams, more data for inportant decisions, better software and more profitable being produced and operated more quickly.