DevOps Enterprise Summit London

Why I call myself Mr DevOps

There's a reason why I call myself Mr.DevOps. It's embarrassing, but here it is. In a role where we're supposed to be blameless, I'm blaming the process...

So let me explain. When I show up, the registration screen asks for my name and title. So after many years of filling in my address, I thought it was a bit odd I needed to enter my title, but I went ahead and entered Mr like I have so many times over my life. Here is the most basic of examples why a process needs to be fool proof and why I call myself Mr DevOps...

The summit experience

At first I was a bit apprehensive as I saw the demographic for this sort of event was catered more for execs/managers.

Over the next few days however, I learned a lot. The majority of the talks I went to were primarily data driven or expressing the importance of metrics. These talks   I found very interesting as it gave an insight to how other companies value metrics and how they use this data to determine the best course of action to improve. Because without this data, why do what we do? How do we know if what we're doing is actually improving the process? Some of these talks included:

• Sonatype going over their report of package vulnerabilities and the dependencies pulled over the year
• The importance of metrics and how they tell a story
• How we can use metrics to determine what unplanned work is the biggest issue and what can we do to reduce these issues
• A chat bot that could track issues and provide a report on unplanned work with time allocation

Other talks I found interesting were companies telling their stories of how they incorporated the DevOps culture and showed how their previous estate operated compared to their existing estate. Best example of this was one of the main presentations from ITV showing the viewing numbers for the channel over 5 minutes before the newest season of Love Island started. You could see the numbers ramping up and they explained as they could see the number of requests coming in, they were autoscaling to accommodate  for the sudden rise, which was interesting to see.

The only part of the talks I felt let down by was the "Tales from DevOps" segments. Before my colleague and I even left for the trip we was saying how it will be interesting to hear these stories of how companies tried to implement a CI/CD based process and maybe tried to run before they could walk. So horror stories of how they weren't prepared. Then the first talk starts and they talk about this guy had been tasked with implementing CI/CD and he was the only person tasked with the whole thing. First thing we thought was it was going to be a story of how the guy took on more than what he could handle. Then the whole story took a turn and the guys wife was diagnosed with a terminal illness, he was stressed and falling behind with work and ends up losing his job. By the end of it, we left and our reaction was "wtf was that about?..." If that was a true story, I feel for the guy, but really wasn't what I was expecting for "Tales from DevOps".

The convention hall

The convention hall was a good experience for meeting a lot of companies offering various services to help with the DevOps tool set. I gotta say though, for the most part I was thinking about what I could get in my bag of swag to show off when I got back.  There was a lot of it. T-shirts, stickers, pens, books, etc. We did check out some of the companies and the products they offer such as:

Gitlab

But some of the products we looked at were intriguing such as Gitlab and they was showing us how their pretty much a one stop shop for everything. The one thing I was impressed by was the source code is scanned with a static code analysis tool when pushed to the repo. I liked this aspect, because right now I primarily use Sonarqube, and although a great tool, the quality gate forces us to put an explicit sleep timer so it has enough time to fetch a status from Sonarqube in order to pass. But with this, it would save time on scanning during the build process.

DataDog

This tool I was really impressed with and would love to work with this tool in future. I know it was a demo, but the UI was super responsive and they displayed a great deal of the scope and how much you can drill down into the data and how to easily transforms to information you need.

Meeting Gene Kim

Gene Kim is the author of The Phoenix Project. A book most people in the DevOps culture will have read. The first night in the convention hall we all got to meet Gene Kim and have him sign an excerpt from his newest book which is out now called The Unicorn Project.

After that, there was plenty of food and drinks to be had which helped with us all talking on the convention hall floor as I'm typically not a social person.

Conclusion

I would definitely recommend going to the next DevOps summit if you can. It was a great experience and there are lessons to be learned from companies telling their stories on how they started out and where they hope to end up. It helped give me ideas on things we could try and what aspects we should be concentrating more on to succeed.