What is DevOps?
Photo by Andrew Neel
Originally Posted On: https://www.carldeantucker.com/blog/what_is_devops/
DevOps is one of these terms that dominate many conversations about modern practices, especially when considering software development, but many times it is not clearly understood what DevOps really is. DevOps, as a term, originates from Development (Dev) & Operations (Ops), the two basic teams that exist in all software development companies and first appeared as an idea back in 2009, having had considerable expansion and progress since. The common industry joke about DevOps and how to approach it is, that you simply have to take your old Ops team and rename it, While there is some truth in this joke, DevOps is a much more refined redefinition of the traditional Development and Operations teams.
What is not true DevOps?
In order to better understand what DevOps really is and locate the benefits that lie within this approach, it is very important to first understand the bad practices, or DevOps Anti-Patterns, that are many times used in the industry and can have many problematic consequences.
Dev and Ops silos
One of the most common, and arguably old-fashioned, approaches is having two completely separate Development and Operations teams, commonly called Dev and Ops ‘silos’. The problem of this strategy is, that there is little to no connection between the two teams, leading to lack of agility, less flexibility, lack of feedback between them and of course economic losses for the company. You essentially have two malfunctioning groups that simply can’t compete with the pace of modern technological progress, being a system that is more or less a relic of the past.
A neighbouring problematic anti-pattern is having a third ‘silo’, DBA (Database Administration), which functions as a part of the Ops teams, and is usually useful in companies with a rich database that goes years or even decades back. Usually, this team will become the gateway between Dev and Ops, but since they are not involved in the early stages of development, they can’t offer useful feedback early enough.
Separate DevOps team
Another idea that is sometimes implemented, is creating a separate DevOps team which functions as a gateway between the isolated Dev and Ops silos that were mentioned above. Usually, this stems out of the urge to experiment with new ideas but ultimately implemented in a completely wrong way. Usually, the mentality of the Dev and Ops silos never changes, and the few direct connections that they had beforehand are severed by the abrupt addition of another team that instead of connecting them, acts as an additional barrier.
DevOps team within a Dev or Ops team
A common, yet usually problematic, way of implementing a DevOps team is by creating it within the separate Dev or Ops teams. The first possibility is to add a DevOps sector with the Dev team, an idea which usually has poor results. First of all, when a normal DevOps team is placed within a traditional Developer team, then they are usually underestimated and isolated, being unable to successfully operate. Additionally, it is very hard to manage the workflow when there are tasks that lie within the jurisdiction of both the Dev and the DevOps teams, leading to confusion within the department. Another approach to this model which usually is more successful is transforming the embedded DevOps team to a dedicated tools team, which operates in support of the Dev team. While this idea enhances the success of the Dev team, it has little to no impact on the main problem, which is the connection between the Dev and Ops teams. The same problem can arise with companies that hastily try to implement DevOps within the Operations team, leading once again to little or no impact on the workflow.
Ops and Dev teams embedded
Once again, this highlights the way that DevOps is not simply placing a team within another. Many times this is misunderstood and companies transfer the Ops department to the Dev department, hoping that this will result in a smoothly operating DevOps department. This couldn’t be further from the truth, as usually the reigning Dev team will underestimate the importance of Ops and will diminish their impact.
What truly is DevOps
After all the ideas explained above, it is easy to understand that there is widespread chaos in many software development companies that try to implement DevOps, but ultimately fail to do so and end up with even worse results than before and choose to abandon the addition of new strategies in their workflow. It is extremely important to understand that DevOps is not an elusive idea, but rather a very intuitive one which thrives upon human relations and the creation of a well functioning and cooperating team of workers. The following examples are some of the most important archetypes that define what is healthy and correct within the DevOps strategy.
The collaboration of Dev and Ops teams
Remember that in all of the previous problematic examples, the main issue was the lack of proper communication and feedback between the Dev and Ops teams, something that was the root of numerous problems in the smooth operation of a software company. The collaboration of Dev and Ops teams is the essential archetype of this philosophy, with the two teams working frequently together in projects, while at the same time retaining their fields of expertise to ensure the highest possible quality of the final product. Such a strategy is highly beneficial for the workflow of a software development company, as it partially merges the separate groups of development and operations. This also means that it is possible to create the DevOps department with the existing Dev and Ops teams, if there is sufficient desire for change and innovation within the company.
This model requires inspired and meticulous leadership, especially during the process of transition between the older models and DevOps, as there is a need to define the shared goals, objectives and tasks, while at the same time defining the areas that lie within the jurisdiction of a specific part of the two teams. In a way, it is a form of organic cooperation between the workers of a company and thrives in workspaces that encourage the development of social skills and the formation of a tightly knit, well-organized team.
This elegant and organic structure is the defining characteristic of most DevOps archetypes, underlining the fact that it isn’t a complicated technologically driven system, but rather an implementation of successful human relationships that become a driving factor behind the success of a company. As it can be easily understood, the enemy of such a model is the appearance of isolated groups that don’t cooperate well enough with the rest of the teams, something that can be avoided by increasing the organic structures that exist within the company.
Fully integrated and shared Ops
In many ways, this second model is a further refinement of the previous one, being even more innovative and open to a workspace with widely spread responsibilities. In this case, the two previously separate teams of Dev and Op, become a completely merged DevOps team, where all workers share the same goals and are acting as a single group in all of the processes that are an integral part of software creation.
Such a model has numerous benefits that aid the production process as a whole. First of all, the employees become adept in numerous skills that weren’t previously a part of their expertise, broadening their horizons. This also means that they have a better understanding of the production process as a whole and not as a specific part, leading to a deeper knowledge of the product and better cooperation within the group.
It is also noteworthy, that the pace of content creation can be potentially elevated, as they are not limited by the time-consuming exchange of information between two teams and the abovementioned problems that arise within models that follow such principles.
Finally, it is considered as a strategy that can lead to considerable cost efficiency, not only because the pace is better, but also because there is no need to sustain two, or even more, separate groups.
Other Ideas of true DevOps teams
Of course, such an interesting idea that concerns the complicated topologies that exist within a workspace can’t be completely represented by just two main examples. There are numerous other potential models that have varying degrees of success, with most of them being based on a common principle that changes according to the variables. This common principle is a separate DevOps team that acts between the traditional Dev and Ops departments, without having the disadvantages of the previously analyzed anti-models.
In these cases, the DevOps teams are not simple gateways between the two departments, as it is known to have little effect, but they aim to facilitate a tightening of the bonds between the two groups and provide support to numerous processes that lie outside of their traditional fields.
It is also possible that such a DevOps team can act as an intermediate step between the old systems and a completely merged DevOps team, as many companies prefer a steady and secure pace of innovation, rather than bold and sometimes risky steps.
Conclusion
So, what is truly a DevOps system?
As it can be understood by all of the examples given above, DevOps is not a concise and strict terminology, but rather a strategy and a mentality of work and production that focuses on cooperation between employees and the creation of a cohesive and well-balanced team, abandoning the previous ideas that aimed on needless and excessive focus, without proper feedback and support.
DevOps have drastically changed the contemporary workflow during the last decade and it is important to summarize what are considered as the main points of focus within this system. Many companies and researchers have their own ideas, but most tend to agree on some fundamental stages of production that become the essence of DevOps[1]:
- Planning
- Coding/Building
- Testing
- Preproduction
- Release
- Management
- Monitoring
At the same time, it is crucial that within the team and with the customers there is[2]:
- Continuous Feedback
- Continuous Integration
So, as you can see, changing the mentality and the way that you work can be a clever, and most times cost-effective, way to innovate and get ahead of your competition. The older models are simply not compatible with the continuously elevated demands of the contemporary software market. In many areas, DevOps considerably outperforms older development strategies by having even 30 times more frequent deployments, 60 times fewer failures, 60 times higher success rate and a staggering 160 times faster recoveries![3]
These statistics are an indication of the great potential of these strategies along with their rapid implementation by many industry leaders, like Amazon, Netflix and even NASA[4], in order to refine the processes and offer a higher quality of services, with a lower cost and better pace. All these examples prove why DevOps is not some wild idea, but an easy to implement change which will have drastic consequences on the workflow of every company.