I take the liberty and the big challenge to try to explain/define what I understand when talking about DevOps. All this thoughts are gathered from my experience and forking some idea of Adam Jacobs (CEO of Chef). Forking and following Adam's idea is exactly like we are working nowadays on our projects. Let's try to have this article as MythBusting for DevOps discipline and DevOps role, and how together we can build a new culture and mindset in our organization.
The DevOps movement emphasizes communication, collaboration and integration between software developers and IT operations. This was the main reason why DevOps appeared in the software industry. Making life easier through communication, collaboration and integration can be realized in multiple ways.
There are some several interesting benefits for adopting DevOps, people from companies that practice DevOps can become more productive as IT professional - increasing the chance to be part of more attractive and enthusiastic workplace. Practitioners can also be more focus on using interesting technologies and adding value-work which redirect them to a greater job satisfaction and not the last with this new lean process will be spared of the politics. Culture, tools and automation can fill the gap between those 2 silos and through the workflow just created software will benefit of:
Timely talking the word #DevOps appear sometime like 2009 and it was behind a lot of discussions like Agile, Operations Management (Systems Thinking & Dynamics), Theory of Constraints, LEAN and IT Service management. Anyway this year it should not be so important because a lot of people were doing DevOps before 2009.
Let's not think that 2009 was the beginning of DevOps. A lot of people that where developing software, driving projects or companies have in mind most of the principles that are characteristic for DevOps nowadays. I guess exactly the same guys that and defining DevOps now or evangelize DevOps wherein doing DevOps before this term really appear.
In the next paragraphs I'll present DevOps from 2 perspective: discipline and role. By doing this, I expose the benefits of adopting DevOps culture in your company. Seeing DevOps from both views and presenting key points of adopting DevOps culture will help everyone to see the big picture and also that small steps needed to have DevOps. This ideas should not be addressed only to QA, Developers or SysAdmin should be an entry point for Project Managers, Scrum Master, BA and all the people involved in software delivery from point 0 to Production.
In defining DevOps - discipline, we should take into consideration how UNIQUE this word is for every person. There are a lot of people that are using this word in lot of scenarios, either because they are doing or they just think that are doing DevOps. But in all the way they are unique, everything they are doing is unique from person to person from project to project from company to company. Comparing it to Continuous Delivery - there is not a specific recipe about doing DevOps. But it doesn't matter where they work, on witch position, with what technology DevOps are building an workflow that relies, technologically, on automation and socially, based on collaboration.
As a DevOps practitioner a lot of people see this role as the lifeguards or firefighters that can come and save the moment, do a redeploy and make everything to work like at the beginning. One of the first steps when defining DevOps is to set them apart from Operations.
Before jumping in having a DevOps role in you company - it is recommended to review culture, process, metrics, infrastructure and scalability of your team/company.
Like an "expression" it sounds very good until it happens to you. DevOps practitioners are mitigating for lean and continuously improving development process. In this way it should be avoided moments like - "BIG release day", "let's roll back not forward", "call the DevOps he broke something". "The build is broken".
Having separate DevOps teams is something frequently seen nowadays in the companies that start hiring DevOps. As a suggestion we should stop doing this is software industry because DevOps is about creating a culture of sharing responsibility in delivery teams. It's a better idea embedding operations skills into delivery teams to reduce friction and deliver better to costumes. Anyway there are phases were you can have like separate teams that are specialized in delivering some tools or building a new private cloud.
To do DevOps you need to be aware about having a suitable environment and create one for the others. This environment can be defined by some terms. This are in very tight correlation and depend one on each other
Safety: physical safety, information safety but also the ability to act without fear of unintended consequences
Knowledge: Like you may know, knowledge is a leading indicator of social progress. Having the right knowledge at the right time we'll make everyone aware about how they influence and improve the software, project and company they are working at. Other than technical knowledge we may refer at the business knowledge, for people to see if their job has made the business greater and bigger
Contentment: satisfied about the work that you done. Because doing DevOps will make you happy every day. Need to feel good about the system you build or the people you work with.
Freedom: The power or right to act, speak or think as wants without hindrance or restrain.
Another thing that DevOps is associated with are tools. Some of the pioneers of DevOps have started to work as Configuration Management People of Linux Engineer. And for doing the job better, faster they have used tools like Chef, Puppet, Jenkins, Atlassian Stack, Ansible, Xen or RedHat.
These companies have made a lot for the DevOps movement but not everything is about them or about the tools they build for us. Another thing that I have found out at a summit organized by one of these companies is that they evangelize a lot DevOps in all the world parts. In this way they help people to do DevOps and Continuous Delivery but not by "selling" only their own tool, for sure the tools that they have made are primarily, but they also use other stuffs. The main goal on evangelizing DevOps for this team was to set the right mindset for those companies and for the members of those companies.
It Is not all the way wrong but DevOps should not be just about tools/a specific tool As DevOps you should be very good in working with tools but also a sociable and people orientated person. Also we need to be aware that DevOps and Continuous Delivery is not about a tool is about process and about how fast this combination gives us FEEDBACK.
I know that failure is not a nice subject and people are avoiding it. But as a DevOps I think that we should elaborate this part a little. One of the biggest value of someone who is doing DevOps is the ability to fail. For this, let's take a quick look about what T. Roosevelt said in 23 of April 1910:
" It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again"
Trying to adapt as much as possible what Roosevelt said, it's not ok just to stay out, examine, read articles, being amazed about what other can do or how expensive is our AWS bill . We should start implementing, fight with new technologies and for example reduce the AWS bill or implement a continuous delivery blue/green pipeline not just read about it.
Not saying that DevOps should get used with failure, but practitioners of DevOps should know the balancer or the moment when they can faille proudly just in time to make improvements for the future.
In our day by day work we face failure frequently, let's take as example a continuous delivery pipeline. We create a new pipeline, investing a lot of time, power, tools and money, but why we create this? - what should be the benefit of pipelines. Most important benefit of this pipeline is to break our build - and feed as where our code is wrong and where we should do the changes before this gets in to production. In a software development life cycle is important to find as many possible scenario where you code will fail and fix them in Dev or QA. Embrace the failure and the right moment don 't let it to get when you don't expect.
Funny thing that we get to feedback. DevOps practitioners should be aware that all the tools and processes give us an iterative cycle of fast feedback. Feedback should be the main purpose of our daily work, because if you don't get the proper feedback at the proper time you will lose more time by getting back to the right iteration and only then fix the problem. We should not forget that feedback can be positive and constructive, having both of them will bring values to our product and team.
Gathering feedback can be made through "user" and in this way people, teams and company can be more lean, agile and innovative day by day.
The purpose of the article was to define the concept of DevOps as a role and as a discipline and I would like to use a definition made by Adam Jacobs that is the most close to the truth:
"A cultural and professional movement, focus on how we build and operate high velocity "projects", born from the experiences of there practitioners"
Taking a closer look at this definition we can say that for doing DevOps is not necessarily to be DevOps like a profession, you need to be in the culture of DevOps you can have any other profession but practice DevOps. The scope of doing DevOps is to build high velocity project with cool and this is the main scope of what we are doing. When you are doing DevOps you need to be part of the action, you need to share your knowledge and together with the team and get to the final scope.
by Ovidiu Mățan
by Mihai Câsu
