Getting started with automation is a bit like investing – high risks with potential high rewards. Most DevOps transformations are set in motion in order to get things done better; “better” often meaning getting things done quicker and cheaper.
I attended the lifecycle and continuous tracks on Days 1 and 2, respectively, of the HPE Customer Forum in Dublin 2017. It was clear from the start that Kaizen is at the heart of DevOps; or, as Tal Levi Joseph, VP of R&D ADM at HPE, put it: “DevOps is an evolution, not a revolution”.
As a summary of the talks I compiled a diagram below (figure 1). The diagram depicts the common challenges and benefits of DevOps and thus does not accurately describe each DevOps transformation – I did hear someone had a reduction in speed as a result of applying DevOps practices (quite rare I say). Traditionally, all people want from DevOps is agility and speed. However the demands and realized benefits in the more recent DevOps adoptions focus on the right talent, scale, and quantity.
So what about the risks? Seeing them more as healthy challenges, DevOps initiatives will expose flaws in processes and collaborations (or the lack thereof), within organizations. Toine Jenniskens from Rabobank highlighted the importance of automation while getting started with DevOps. Even if not all automated processes will work perfectly, they will still bring efficiencies, give more accurate outcomes without human error, and quickly indicate which parts of the automated process are broken. One of his mantras was “one function, one tool”. Indeed, many tools have been developed with one primary function in mind, and using best of breed solutions for each, is typically the best way forward.
In a different talk, Arne Luehrs from HPE described ChatOps as “anything that is not email and allows users to communicate in real-time”. A great example of an organization embracing a new method of communication, to share and explore information in a way that serves its users better. Now at HPE, they have over 4000 chatrooms dedicated to particular systems and configuration items with empowered teams able to collaboratively create their own rules of engagement for each conversation.
The above examples are really about reducing “time to market”: getting rid of boundaries of email, or automating tasks. But what else can you do? One idea that came up was to regard everything as code: infrastructure, data, best practice code; giving you the possibility to automate everything. A good example of this is when developers have access to all code written within the organization, and they can quickly find a package written by and reviewed by their peers. This not only saves time but adds much-needed resilience and lowers the risk of poor code in the developed solution.
To summarize the fantastic two days in Dublin in two words: embrace failure. This forces teams to re-establish an open culture where instead of looking for someone to blame teams are concentrating on working together with one goal in mind: team success.