DevOps Summit Amsterdam 2018 is one of many DevOps conferences worldwide, took place on November 8-9 and brought together senior IT management and DevOps practitioners seeking to share their DevOps experience.

There was an important idea that walked me through all the conference and spiked almost in each speaker – DevOps is not about tools! Tools – those will come and go, the trends will change, the market will change and definitely people will change.

“Don’t let the tooling drive the change! “
(Nicole Forsgren, Author of ‘Accelerate’, co-founder of DevOps Research and Assessment (DORA))

So, there must be something more, something that will bring people together, that will inspire and improve every corner and will give the freedom for inspiration and innovation. Could that be DevOps?

 

Practices. Processes. Culture.

These three words might be the essence of what DevOps is. Sounds simple enough, but variations of how, when and what are uncountable.

Multiple speakers shared their experience on their path to DevOps, their struggles and “aha” moments, what they believe are most important keynotes. Also, some specific topics like knowledge swarming, importance of security in every aspect, monitoring maturity model or in other words Pre-Mortem analyses and the essence of what is service reliability architect.

I favored an idea shared by Mirco Herring (Managing Director at Accenture, Author of ‘DevOps for the Modern Enterprise’) that we don’t know where we are and we don’t know where we are going. The cultural and mental transformation of organizations and even small groups can be and are very exhausting and could take even up to three years. I would say – as per DevOps the change should be a never-ending process, but it also shouldn’t feel that hard, right?

 

You probably have experienced painful deployments and seen a paranoid Ops guy who triple-checks every change manually before applying? I saw the first one five years ago and couldn’t understand the paranoia until I learned how all the existing procedure and systems works. Then I also got deployment paranoia sickness. It might be contiguous.  So, how can we change with ease?

To get to those nice pipelines, automated tests, continuous integrations and deployments we need to change our mindset quite a bit. Introduce never-ending feedback process, have an open mind, dedicated time for improvements, experiments and control flow. And with all of this it is also very, very important – we need to know WHY. One way how to answer it is maturity models – essential part to measure and track our success and progress.

“Measuring is knowing!“
(Marc Lammers, Former Head Coach of the Dutch Women’s National Field Hockey Team)

Also, it good to keep in mind that maturity model shouldn’t have an end state. When we reach our goals, there should be further ones. We have to keep maintaining and improving the system and process. The world is changing around us and we should try to build systems that will allow us to be agile and evolve together with world. But tricky part about measuring is that each person might have different see where we are. Look to this image below from Mirco Herring presentation.

Mirco Hering, THE ART OF ACTION, slide 10, @mircohering #notafactoryanymore, accessed 5 December 2018, <https://www.slideshare.net/mircohering/the-antitransformation-transformation-devops-summit-amsterdam>.

 

When we ask our leads: “Are we using DevOps practices?” – what do they say? And what does a project manager working with the team or developer going through DevOps transformation say? Do they mean the same? And when our leads say that we are going to be innovative and agile – does everyone think the same and do the same or as per each individual understanding and experience? The plan that is made can be quite far from what actually can and will be executed. So, we need significantly shorter period plans, where we can be more agile and adapt to actual situation.

 “Management is not the same thing as Leadership.”
(Ratidzo Felicia Zvirawa, Lead Product Manager, WeTransfer)

Ratidzo told the  story of their company’s path to DevOps, and one of the essential flow steps was creating a clear vision. She highlighted that we should look around and notice who are the actual people leaders, who necessary doesn’t have the titles, but sway the company forward. Is is also key to think about your own impact to others. It is imperative that the real leaders are aware of ongoing cultural change, what it means and where it should lead, so they can continue supporting to create a clear vision and help understanding why we are doing this. Also other speakers emphasized that leadership matters and it is important to answer the question “why”.

On the topic about true leadership spirit – I believe the talk of Marc Lammers boosted the whole conference hall. Although he hasn’t been directly related to IT, his approach to work with his team of the Dutch Women’s National Field Hockey has been more than Agile. They use continuous experimentation and improvements to find their success formula, ongoing health monitoring with attached gadgets to player bodies, research and crazy ice-cold baths, because a gold winning racehorse had cold pool walks as a routine. Trying to focus on the weaknesses and understanding that they must focus on their strengths as that will boost players’ confidence and over time players naturally will want to improve their weaknesses. And many more ideas and thoughts.

Did it all come easily? Definitely not – the change comes with resistance as people don’t like to be changed and you must overcome it to achieve results. How? With lots of explanations “why we are doing this”, with inspiring success stories and lot of involvement. Ask your people open questions – how they would improve the process, how they would fix the problem? That might not be easy at start, but at the end could result in more engaged and inspired team, bright ideas and honest feedback.

It all comes with experimentation. Situations are varying and there isn’t one success formula, but there exist a lot of good practices. And sometimes even seemingly wrong and crazy ideas might work for your team.

An interesting and a bit different story was told by Pavel Zastavnitskiy, a Senior Front-end developer at Booking.com. The development approach almost hasn’t changed in their team since 2013, and they could put a checkmark against each high-performer group’s quality… except for delivery time and failure rate. There is a fast change implementation and a lot of freedom, many deployments per day and your code is in production almost after the commit. But a lot of deployments fail because there is a lack of automated testing. They see code reviews and automated testing as potential blocks, and therefore in their approach they prefer to respond to the risk by monitoring closely and quickly reverting.  And yet they manage to be one of the most successful accommodation providers. Of course, don’t get too worried about your next booking – they do use testing, especially for security, and also triggered canary analyses of each of their deployments (a bit lesser chance that you might be the lucky one finding a bug in their system).

The answer to booking.com story could be presentation by Lodewijk Bogaards (CTO at StackState) about importance to move from reactive to predictive IT. This talk was about AIOps – Artificial Intelligence for IT Ops – and how to move from monitoring our current state to monitoring and predicting future state.

Future state – Pre-Mortem Analyses.  Nobody wants to wake up in the middle of night because there was CPU alert to find out it was just because of a spike activity after football game that resolved by auto-creating a new instance. But in the middle of night we really would like to know what the actual impact will be. Imagine that there could be a monitoring system that collects all information, collects trends on other nodes, knows all dependencies and will know what will happen and tells you that in 7 hours response time of Redis will become critical and Ordering System will have downtime for 2 hours, the probable root cause of this issue is “Infrastructure upgrade” from 10pm, January 16.

 

Another interesting concept, presented by Iwan Eising, was role invented in Infor called Service Reliability Architect (SRA). SRA (inspired by SRE) is compared to Gandalf (Lord of The Rings character) as an ultimate wisdom person who leads by inspiration, guides, advises and supports and profoundly cares for reality.

The ultimate goal of SRA is to partner with developers and improve the critical pillars of a successful cloud. The SRA team provides in the most cost efficient manner an operational architecture perspective on reliability, performance, scalability, agility and security that complements application developers and architects. This creates another level of specialists, and at some point such group of people might be even necessary in large organizations, but big success key hides in knowledge sharing.

Knowledge swarming. Jon Hall, Principal Product Manager in BMC, talked about how to get out from 3rd-line ticketing hell, but the idea of swarming could be used not only in the service desk world. Quite often a lot of time can be spent on ticket bouncing, asking questions, waiting for answers, forwarding and not getting a result even if it might take just a few minutes. Solution he provides is removing the tiers of support and calling on the collective expertise of a “swarm” of analysts. This started with few people from each level and a group being called into swarming mode and they would go through the ticket backlog and share their knowledge on how to resolve the issue. In this scenario, even the most experienced person could learn a lot by looking on things from different angle and gaining knowledge shared by others. Also, such swarming can have some difficulties as finding the right people for a swarm, a few individuals might be dominating and it is difficult to evaluate individual contribution.

 

All in all, this was great experience, and as a closing note I would like to quote Nicole Forsgren that “a smart investment in tech and practices make our work better. Also, less burnouts… it’s not about feeling exhausted, but about no longer finding joy about things you used to love about your work.”

 

#ThinkDevOps

DevOps Specialist
Sintija Vernava