What can be improved about DevOps, is open for speculation. However, this trend brought about tremendous changes to the industry even in its infant stage, without sophisticated tools available to us by now. Given this, in this article we’ll be talking about the core of the DevOps culture – the people and the mindset.
In pursuit of the customer’s satisfaction, the IT players seek the most effective methodologies (Agile, DevOps, etc.) to deliver top-notch products to the market in a better, faster and risk-free way. The trend is characteristic almost for the whole industry, which makes the IT market so innovative and ground-breaking. However, with all the sophisticated tools and staff we start to forget about the key elements of these philosophies – the mindset and the people. It is because of these two components that DevOps culture in particular was given the green light at its commencement. In this article, we get back to the start of the DevOps era, recall why the new philosophy was accepted and adopted and reflect on how to develop it in your own company.
DevOps story in brief
The story of DevOps culture is by far one of the most inspiring in the whole IT industry.
DevOps was intended to resolve mostly interpersonal/communicational issues, which actually only few saw clearly. Only after the change in the mindset, the change in tools follows. Let’s recall the events of the past decade to have a better understanding of the underlying idea of DevOps.
In 2007, Patric Debois, a Belgian IT consultant and PM, engages in a government data-center migration project. His task was primarily in certification/readiness testing. Among Patric’s duties was also ensuring smooth cooperation between the application development teams and operations teams. During his involvement on the project, he had to face the communication divide and lack of operational cohesion between the two, which negatively affected the project outcomes.
Soon after that, Debois meets Andrew Shafer, another to-be DevOps evangelist, at a Toronto conference. Actually, Debois was the only one who showed up at Shafer’s session, “Agile Infrastructure” dedicated mainly to the DevOps-related issues. Before this, Andrew received so much criticism on his posting that he even decided to skip his own session. Nevertheless, Shafer and Debois did meet at the conference hall, where the arm of destiny united two like-minded talents to give birth to a new operational philosophy. Together, the two formed a discussion group of the IT enthusiasts that were also tired of the operational segregation between the devs and ops to search for the possible solutions.
The problem that Debois and Shafer were highlighting, surely, was known to the whole industry. To acknowledge it on a broad scale and to elaborate an industry-wide solution, yet needed a little more support. Such support was given through “10+ Deploys a Day: Dev and Ops Cooperation at Flickr”, a presentation by John Allspaw and Paul Hammond, which in 2009 drew an adequate response among the concerned.
Later this year once again the IT community hears from Patric Debois who organizes DevOpsDays. The event receives enough resonance in social media among the devs as well as ops experts.
The movement continues to evolve and garners even more attention after Cameron Haight from Gartner voices his positive predictions as regards DevOps and its impact on the industry in 2011.
Why DevOps actually was given the greenlight?
The IT players could’ve very well given the new trend a cold shoulder. Nevertheless, after all the hardships, the DevOps enthusiasts eventually managed to set the stage for the industry-wide recognition of the new trend, and in a few years DevOps practices become a must both for the IT giants as well as start-ups. Where’s the trick? Many theories/philosophies that are seemingly very promising go west if they don’t hold the true value in them. DevOps does. Its adoption allows transforming current ineffective processes of a company and ensures lean, transparent and smooth performance, provided that every team member shares the DevOps vision.
See the before-after action scheme of a developer to get a clearer view of the impact that DevOps culture has on the industry.
As you can see from the above table, DevOps practices combine the strengths of the devs and ops teams through eroding communicational barriers. This helps achieving bigger objectives, which a separate team can’t do alone. As simple as that.
Communication patterns between your talents are the basement for the DevOps and without it, no matter how sophisticated your tools are, you won’t manage harnessing true DevOps potential. Automation and top-notch tools are great things, but they are of second class in case a company chooses to undergo the DevOps transformation. Furthermore, the DevOps pioneers managed to make a point without them.
How to develop DevOps culture in a company?
CALMS is a valid model to test how DevOps your company is. By contrasting CALMS practices and your teams’ practices, you’ll have a chance to fit the reference patterns to your current practices and see the weak points. Eradicate them and you will develop a true DevOps culture in your teams.
See the CALMS model in the breakdown by element with detailed explanation below for actionable ideas.
C – Culture
A – Automation
L – Lean
M – Measurement
S – Sharing
Culture forms a solid basement for applying other elements of the model. You may be asking yourself in the first place– what is culture? Your perplexity is well justified, for already back in 1952, Culture: A Critical Review of Concepts and Definitions contained a list of 164 definitions of “culture”.
In our case, we deal with the definition that is synonymous to the mindset. According to the DevOps culture/mindset, there’s no “My/Not my” tasks, there are Our tasks. In the same way, there’s no objective in the DevOps world to develop new features and apply new technologies while maintaining stability and high performance. There’s a goal to deliver maximum value to the customers.
Under DevOps philosophy, we automate the following:
- Almost all test types
- Build compilation
- Infrastructure deployment and configuration
- Application and database deployment
- Error alerts, and more.
Automation eliminates the human factor and reduces time to do the routine tasks, which connects it to the next CALMS element.
Identify and reduce your operational losses. To do this, visualize your workflow, limit your work in progress and stick to smaller releases to make the whole process more transparent and easy-to-manage. Avoid multitasking, for it may hide your true problems.
Likewise automation, management reduces the human factor. Instead of scolding about who’s to blame for the release failure, make use of almost real-time monitoring, which gives valuable insights on what’s running smooth or not. Study the dashboards, follow truly valuable metrics, while observing the whole system in complex, and spot the system’s weaknesses based on hard facts, not biased assumptions.
DevOps, as culture of collaboration and openness, implies that every team member knows what is done and why. The project info can be displayed at the white board and may include: all work in progress, architecture and configuration schemes, progress metrics, traffic distribution, etc. The other info may be placed in wiki/Confluence or other content sharing platform in a concise, easy-to-understand format.
Sharing doesn’t only touch upon the project info, but relates to personal experience of every team member. This is especially important when dealing with bugs and failures, for together, based on the cumulative experience, the team can come up with a brilliant solution to a stumbling block or fix the problem faster and easier than one could do.
Back to the Culture, the centerpiece of DevOps. How does it bundle all these elements together?
In the first place, DevOps is a Culture of collaboration. It helps see the role of each and every person involved in the task, offers another perspective where there’s no other man’s work and every effort is done with the purpose (Lean). The culture that diminishes barriers implies little to no constraints in operational processes, facilitation of routine task that free up time for creative thinking and tackling of sensitive unconventional issues (Automation). Culture of collaboration believes no biases (Measurement) and blames no individual for the failure (Sharing).
Still scratching your head as to where to find money for the new top-notch tools for your DevOps transformation? Your business compass is pointing to a wrong direction. Everything you need to make a good DevOps start is already in your office. DevOps is mostly about elimination of interpersonal barriers, not implementing brilliant tools. Automation will work to its best advantage only after you give the proper tools to a tightly-knit team of proactive, responsive and collaborative talents.