DevOps is more and more frequent in today's IT environment and it probably represents the way we will be organizing work in our communities. The following article will talk about how the need for DevOps appeared, where it stands today, and why it is considered to be a culture, not a methodology. The final section will analyze the way in which DevOps is being implemented in a Cluj company.
The IT domain has undergone several transformations, both on a technological and an organizational level. Whether we realize it or not, the way we organize our work in our teams has depended, mostly, on the technological advancements of the moment.
The waterfall software development model as appeared, for the first time in 1956 (although the name was not yet coined). It was, probably, the first attempt to standardize this process and it comprises of the following phases: analysis and design, implementation, testing and maintenance.
Technological limitations have kept this process alive for a long period of time. Software either ran on software vendor mainframes, either was statically delivered to the client (CD, floppy drives etc.).
Also, well defined roles have emerged inside the companies: software developers (programmers), system administrators, database administrators, network engineers etc.
However, a problem appeared: the client.
Many times, he seemed to be this ambiguous, undecided entity. So ambiguous that a colleague of ours from the company wrote his Ph.D. paper on the "Ambiguity in Software Requirements". But the most troublesome part was the indecision. This kept on generating changes in demands, which in turn led to changes in design, implementation and so on.
Given that the old waterfall strategy could no longer cope with this dynamic environment, the day was saved by the new methodology in town, Agile.
The Agile methodology was actually a shorter and faster waterfall, reiterated many times, until the product was done and the client was satisfied. Of course, this comparison is an oversimplified one, the theme itself being much more complex and interesting.
What is of interest to us is the fact that, within companies, task assignment has stayed the same: the programmers develop the application (as an iteration, this time) and the others focus on their systems, data bases, and networks.
The pressure the online environment exerts on the teams involved in the development and maintenance of contemporary applications (which are either web apps or depend, intrinsically, on the web) determined some organizations to take an important step: they decided to take down the walls that were growing higher and higher between teams.
They managed to place an admin among developers and they obtained some surprising results: fewer bugs, more deploys, less downtime, and faster come-backs in case of problems. Due to this newfound proximity between the teams, the "movement" was named DevOps (in some organizations, the System Administration team bears the name of Operations).
The need to bring Development and Operations closer generated multiple approaches within the IT organizations.
More and more companies are recruiting for DevOps positions. The ideal candidate is, in most cases, a rock star admin, skilled at system administration, application deployment, data bases, scripting, programming, and, if possible, a bit of management). In other situations, the companies create a buffer team of DevOps between the traditional developers' team and the admin team.
The "rock stars" can help a team through their experience and knowledge, which can benefit the entire team. This is especially true if these people know how to share the knowledge. A better name for this employee would be full-stack developer.
However, some companies, like Etsy, tend to avoid them in favor of junior level employees that they can train themselves. The reason for this approach is that, in their experience, rock star admins are not the best at team work. Companies like Etsy prefer unified, well-organized teams that can function as a whole and that don't depend on only one person.
Although some might consider that Etsy is a bit too fussy and oversimplifies things, the truth is that recruiting a full-stack developer is extremely difficult; there aren't that many people with this kind of skills on the market. For a project or a company, training new employees that end up working well together is far more cost effective and more sustainable in the long run.
The second approach, which is placing a new team between two teams that need to collaborate, may not bring the best results. Besides the fact that the communication environment is "broken" in two (dev - devops - ops), there is also the problem of finding the right distribution of responsibilities.
The model that will be presented towards the end of the article is an example of how the teams can be brought closer together with the purpose of slowly creating a new mentality and a new way of doing things, in the DevOps spirit.
The first impulse when trying to define DevOps is to call it a methodology.
Methodology usually applies to the theoretical analysis of the methods applied in a certain domain. When talking about the Agile methodology, for example, we refer to a set of methods and good practices that it implies, being backed up by a theoretical and even a practical argument.
DevOps did not appear and develop to replace Agile, but to complete it.
DevOps attempts to break the barriers that formed between the Devs (programmers) and the Ops part (admins) behind the software projects. This move affects the entire dynamic from within the organization, involving all the hierarchical levels in the process. Therefore, in an organization that practices DevOps, there is already a culture of communication and problem solving in mixed teams.
The answer to this question is offered by the report "Puppet 2015 State of DevOps". This report is prepared annually by Puppetlabs and it represents the statistic result offered by crunching the data from 4900 answers offered by IT employees, working on different positions and in various geographical regions. The conclusions of this report state that IT organizations with high performance:
Deploy 30 times more often
Have lead periods 200 times shorter (the interval between writing code and actual production)
Have 60 times less failures in production
These numbers represent a comparison between the companies with the highest and the lowest levels of performance.
The way in which an IT company's performance is measured and assessed is detailed in the document mentioned, along with the factors that help with its improvement. We will only mention a few, inviting the reader to go ahead and check the entire report in his/her own pace:
Applying lean management principles and continuous delivery
Getting the management involved in the DevOps changing process
The Yardi Romania story started in 2006, with PropertyShark. This is a product designed for real estate professionals in New York, offering detailed reports about properties.
Being a relatively small firm, (around 40 employees), the organizational model that was chosen was one in which all the employees knew the product really well, each going, at a certain point and for a certain amount of time, through each team. This led to a better understanding of the business needs and the problems that may appear.
Although the admins were working separately from the developers, they were attending all product meetings and were involved in the decision making process. If needed, they were also able to access the code and make necessary changes.
In 2010, PropertyShark was bought by Yardi Systems, Inc. After the acquisition the parent company started assigning more and more products to the local office. Each product needed its own team of developers, but the system administration remained unique (with a bigger number of members). Each admin would take care of local IT tasks, as well as product-related tasks. And because almost all the admins were part of the on-call team, it was imperative that each team knew the product very well.
This system worked well for a long time, but it was becoming more and more obvious that the more products were being added, the more this solution was not scalable.
To solve this problem, it was decided that each product will be given two people, who will have to participate to the developers' daily stand-ups. Therefore, it was clear for the managers of the respective teams who were in charge of the system administration part, and the admins were very active in the discussions and decision-making process of the product.
This change brought positive and encouraging feedback: the managers noticed an improvement in task solving capabilities and the admins were able to focus better on their products, without being required to move between context, environments, and products.
The next important phase took place when a new, internal project appeared, and the manager asked for the two admins assigned to the project to stay with the rest of the team. After a few weeks, the results were visible: the team was able to function as a whole, each person having a well-defined role but very in-sync with the rest of the colleagues.
The increased level of efficiency for this project convinced the managers that it was a good decision to move the admins closer to their respective teams. This proximity helped the developers and the mangers understand better the administrative problems that could appear and it helped the admins understand the needs of the developers. Moreover, the shared meetings helped people detect problems even before they developed or they helped solve them shortly after appearing.
There is still a need that the on-call team knows the products really well, but not as in-depth as before. Specific product tasks are being taken care of by the assigned team which then notifies the on-call team of any changes.
This process has proven to be extremely efficient at our company and its step by step implementation had a major contribution to its success.
To sum it up, probably the key take-away here is the fact that DevOps must not be considered a set of skills that some employees must have or a set of tools that we need to use to be able to call ourselves DevOps. The most important thing is the proximity between teams; the skills and the tools surface only if the need for them appears.
Effective Devops - Jennifer Davis, Katherine Daniels; O'Reilly Media 2015
"We are all DevOps" presentation, Velocity Amsterdam 2015.
"State of DevOps report 2015", Puppet Labs.