How I Didn't Make It to London but Still Attended the London DevOps Enterprise Summit

This year's DevOps Enterprise Summit was held between the 23rd and 25th of June in London — or rather "in London," because the event went virtual due to the pandemic. Online conferences have both negative and positive effects: on the one hand, networking takes a big hit, but on the other hand, you can take a break between presentations without having to hear the buzz of the crowd and also dedicate a few days focusing on presentations that you are particularly interested in, which is very convenient.

In a similar fashion, I recently attended two virtual meetups that were held on two consecutive days and formally took place in different cities hundreds of miles away from each other, and a few days later I participated in another meeting "in California."

As you can see, physically attending those events would’ve been very difficult. Sure, you could always listen to the recordings, but the feeling that you dedicated a specific time slot to learning in itself makes learning easier.

Conference reports have become an established blog post type, and the desire for self-development keeps growing stronger while you're stuck at home. But there are so many conferences — how can you see everything you want to see?

That's why I thought that I should do a slightly different conference report. Instead of sharing the contents of the presentations, I decided to write an article that would summarize the conclusions and hot trends, and also point you to sources with up-to-date information.

What is the DevOps Enterprise Summit? How is it different from other conferences?

Any article on a DevOps conference is supposed to start with a reflection on what DevOps is. But everyone is tired of that, so I'll try to get right to the point.

Even though there are many conflicting opinions on DevOps, most people would at least agree that "DevOps is a set of practices that make software delivery and infrastructure management easier." The difference in opinion comes from the fact that one group (usually administrators) says that "discussion of DevOps practices should be as practical as possible," while another (developers and, most often, development managers) considers those practices to be a "philosophy" and a "methodology."

Some might think that I'm oversimplifying, but, in a nutshell, applying administration methods and approaches to development changed the underlying ideology of the development process and made DevOps the new Agile. When we hear about a DevOps conference focused on management, what we get is a conference on changes in the development methodology. However, the DevOps Enterprise Summit is a conference that has something for administrators too, because it also includes more technical presentations.

The first DevOps Enterprise Summit (DOES) was held in 2014. It’s organized by a company called IT Revolution, whose founder, Gene Kim, you might know as a co-author of The Phoenix Project. IT Revolution is a publisher that launched a whole book series on DevOps and its connection to agile methodologies. But why does the DevOps Enterprise Summit have Enterprise in its name? This is an important point.

Implementing agile methodologies in a small company is easy: if you have only a few employees, chances are that you're already using these methodologies — you just don't call them agile. But if your company has thousands or tens of thousands of employees, it’s much more difficult. Such a company has a myriad of processes that were put in place to keep it running. We can imagine it as a big ship: when a ship sails from one continent to another, it performs its function. However, it can't quickly change direction or be rerouted — this will take time, especially for technological processes.

A startup with a few employees can build a prototype of a product in several days, while a company with thousands of employees would be building the same product for years, unless it transforms. That's why big companies want to change and start applying the methods of startups, but they also must figure out how to maintain their processes while transforming.

For example, Excel considers 1900 a leap year. This was intentionally implemented for backward compatibility with Lotus versions 1-3 that had this bug. But those versions were released in the 80s, so do we actually need that compatibility now? How appropriate is this approach of "we'll fix these bugs later" if you deploy software on, for example, a bank’s permanently offline servers? How can you stay flexible? That’s what DevOps Enterprise Summit 2020 was about.

The format of the event

Today, all conferences are trying to go virtual, often with interesting results. Here's how DOES did it:

Presentations are still grouped by tracks, and you can switch between them while watching the stream.
Presentations are pre-recorded in order to avoid technical issues with streaming, so while their presentation is being streamed, the speaker interacts with the audience through a Slack channel. I think this is what stood out to me the most in the organization of the conference. I have mixed feelings about this decision, because the presentations themselves are not interactive, but there’s more time for questions from the audience, and the speakers can answer more of them. However, I, for example, was mostly watching presentations and didn't want to switch between them and Slack, so I would only open it at the end of each presentation, when the time allotted to discussion had almost run out and the next speaker was about to start.
The interaction takes place in Slack, where each track has a dedicated Slack channel. There are also sponsor and networking channels.
There were much more networking activities than before. What I didn't like though was that you couldn't participate in them passively: at the Zoom meetups you had to introduce yourself, and at the round tables everyone who joined was actively discussing different topics. But sometimes you want to just take a look at what people are talking about and then, if you aren’t interested, leave.

Takeaways

DOES focuses on the experiences of horse companies instead of unicorn companies: in other words, companies that proved their worth through hard work over many years (as opposed to market capitalization). Among the examples, you'll see a 100-year-old insurance company, the largest European delivery service, and other companies of this type. You might even think of the approach taken by DOES as an anti-hipster trend centering around the practical application of new methodologies and technologies (see the introductory presentation by Gene Kim).
A cornerstone of DevOps as a methodology is "scenius" — collective genius. Scenius is opposed to individual genius, and that's the point of uniting teams that previously opposed to each other and establishing continuous interaction between them — with scenius, teams can advance to a higher level of problem solving (see the introductory presentation by Gene Kim, and also this link; or, if you prefer, you can just google "scenius").
Every second speaker was talking about a positive experience with creating a platform team as well as Platform Engineering in general, where a flexible microservices architecture runs on top of a platform that provides main infrastructure services. One of the presentations from DOES on this topic was “DevOps Journey at adidas III: Exploring Data in the Cloud,” by Fernando Cornago, VP, Platform Engineering, and Daniel Eichten, VP, Enterprise Architecture, adidas. (To learn more about it, you can also read this article or google "platform engineering" and "platform team.") By the way, it's quite amusing how established methods can be reintroduced as something new. A platform team is not just about engineers who create platforms, it’s also about sharing advice on how to operate them. A platform team is a team with a vision of how their platform should develop (platform advisory/community management/platform operation/platform evolution).
Every third speaker was talking about creating a DevOps Dojo, so let me elaborate on that a little. In the case of small companies or a small number of participating employees, meetups and workshops for sharing experience seem to be undoubtedly beneficial.

But how can a company with thousands or tens of thousands of employees do the same? This is the purpose of DevOps Dojos.

Dojo is a Japanese word meaning a hall for practicing martial arts. The American retailer Target introduced a similar practice into DevOps methodology: the company systematically organized internal workshops, meetups, and conferences, where employees could share their positive and negative experience, and which served as a safe environment for practicing their skills without being afraid of making mistakes. For more details, see this YouTube video.

Speakers from Swiss Re (a 156-year-old Swiss insurance company) were talking about the successful adoption of DevOps methodologies in their company, using their new service as an example. They started their DevOps transformation as an internal startup for three specific products. The company played the role of an investor for the startup, which had its own CEO, management, platform, etc.

By the way, according to Gartner, 76% of companies undergoing DevOps transformations consider themselves to be less than halfway through their journey to DevOps.

When starting a DevOps transformation, you also have to understand the risks. Many companies can complete the implementation of their DevOps initiatives only in five years, and in that time, many practices become outdated or irrelevant. The main issue here is that large companies use the waterfall model to implement an agile methodology, and this creates more problems along the way. Shifting to DevOps implies iteration. Another thing that can advance transformation is changes in a technology team that result in a new vision: speakers from Hermes Germany GmbH mentioned that their DevOps initiative was started by their new CIO. Interestingly, they were against the concept of internal startups, because such startups stay isolated and the company itself doesn't transform.

Almost all presentations about successful transformation cases mentioned the importance of metrics that indicate how successful the transformation was. You can find more about these metrics in State of Devops and also in Accelerate by Gene Kim.
As a tech geek, I was also particularly impressed by the “DevOps And Modernization 2.0 (CSG)” presentation by Scott Prugh. He shared how his company implemented DevOps methodologies in mainframe operation. I'd recommend waiting until the recording is released, because this presentation is amazing: the speaker was talking about migrating COBOL code and speeding up its deployment, rewriting 3.7 million lines of HLASM code in Java, and much more cool stuff! Conclusion: DevOps transformation is possible even for very complex infrastructures with tons of legacy technology.

N.B. Two books were mentioned by the presenters and I strongly recommend reading them: Team Topologies in Action and Accelerate: Building and Scaling High-Performing Technology Organizations.