DevOpsCon Munich 2019 was a four-day festival of DevOps delights. With talks from thought leaders and experts from all across the world, it was a real pleasure to learn more about DevOps. In case you missed the conference or couldn’t make it to all of the talks, here are our key takeaways.

Everyone is in Ops now

Incident management is something that is often perceived as a rather boring duty. However, its importance cannot be ignored, as Damon Edwards explained in his opening keynote. The reason for this is that in the meantime every developer is somehow also active in the field of operations. True to the motto: “Aren’t we all a little bit ops?

But failure in itself is not a bad thing. According to Edwards, we now have to try not only to avoid failures, but also acknowledge the importance of accepting and learning from them so that next time problems can be solved more quickly. These “incidents” cannot be avoided, so “Accept failure…but not downtime” should be the motto.

We also caught up with him after his keynote for an interview in which we got a deeper look at his thoughts on DevOps, SRE and the future.

Soft skills are now core skills

Soft skills are no longer simply nice to have, they are essentials that have become mainstays of DevOps-related positions. This means that we should now stop talking about soft skills and instead start to think of them as core skills – skills that should be a part of your core competencies.

You should really read The Unicorn Project

There were a lot of book recommendations from all the different speakers throughout their talks. Whether it’s Seeking SRE with a chapter from Damon Edwards or Thinking in Bets by Annie Duke, there’s one book that came up again and again. Of course, it makes sense because The Unicorn Project is the latest masterpiece from DevOps visionary Gene Kim and was released just days before the conference started. We haven’t finished it yet, but we’re already seeing ways we can use the five ideals to make our working lives better!

We should stop binary thinking

I’m right and you’re wrong. That’s binary thinking at its best. Julia Wester gave an insightful talk in which she explained the benefits of moving towards spectrum thinking and how new perspectives can open up new avenues of thought and ways to find more innovative solutions.

In dissecting a tweet from US President Donald Trump, she showed the techniques used by binary thinkers so that we are prepared to see such arguments for what they are in future. After all, a team where everyone thinks the same thing the same way is no better off than a team where nobody understands anyone else.

With spectrum thinking we learn to accept that maybe there’s a third way (or perhaps even more), and that it’s not just about who’s right and who’s wrong, but finding the best way to address the customer’s needs.

DevOps transformation is like burning your fingers

Communication is the key to DevOps, in case you didn’t already know that. We shouldn’t be working cut off from everyone else. For those looking to start a DevOps transformation, the most important thing they can do, according to DevOpsCon speaker René Lippert, is talk to other companies who made the same journey.

Using an example, he asked the audience to describe the sensation of burning your fingers. This is difficult to put into words. He said that the same is true of a DevOps transformation; there’s a lot that is difficult to express in exact terms, but you can get an idea. And the better an idea you have of what will happen before you jump in and try it yourself, the better prepared you are for the possible outcomes.

To achieve concrete change, you need concrete reasons – you can’t impose change, you have to show how it’s better.

Artur Margonari pointed out that simply running around telling everyone how agile you are and they are doesn’t help at all. Similarly, telling your teams that they need to be agile now and telling them what to do to become agile probably won’t work because they know their tasks and their workflow and it works pretty well already.

To instigate real change, concrete change, he says you should first address the reasons why with your teams and then work with them to see how they could begin to apply agile practices in order to visibly improve their daily work. If you can show them that, then there won’t be a fight because they will understand and strive towards the same goals as yours.

You design it, you build it, you run it

Communication is the key. This phrase can be found virtually everywhere – from the football pitch to the executive floors of DAX companies. And so it is in the software development world, as Michael Plöd, Principal Consultant at innoQ, once again emphasized in his session. In his opinion, modern working methods that want to achieve the best possible results in the shortest possible time require not just communication, but direct communication. In practice, this means that developers work in direct exchange with domain experts. For his model, Plöd combines elements from DevOps and DDD. The two strategies are not new, but have by no means lost their topicality.

The result is a cross-skill collaboration with Ops, Devs and Architects as autonomous teams who are in direct contact with business domain experts, and this is how they move through the entire lifecycle of a project. In this way, DDD and DevOps extend the old saying “You build it, you run it” to “You design it, you build it, you run it”. Both philosophies are not silos, but toolboxes of techniques. By using them together, Plöd demonstrates the versatile possibilities for teams in software development.

Successful missions are run not built

How do you control chaos? Tobias Kunze, co-founder and CEO of Glasnostic, answered this question in his talk. Controlled Chaos: Managing your Microservice Ecosystem for Business Agility, the title of the presentation, dealt with the ever-increasing service landscapes. In what Kunze calls the new reality, individual applications combine to form huge systems. Interdependencies are growing – as is the vulnerability of these ecosystems. “If you don’t know what your apps are doing, you’re doing something wrong”. Kunze’s quote summarizes the problems that companies face in this context. More apps, more data and a lack of standardization lead to chaos and loss of control.

What’s the solution? According to Kunze, the first step is to say goodbye to the idea that monitoring alone would suffice; successful projects are always managed, monitored and controlled, not just run, by agile teams. Growing service landscapes and all kinds of microservices therefore require mission control, like the Apollo 11 flight.

With new technology come new risks

Rani Osnat’s talk focused on the question of security best practices for new technologies such as Docker and the cloud. The short answer: Automated security that covers the entire lifecycle. The longer answer: Security teams have to adapt to new technologies like the cloud. In practice, this means CI/CD instead of a few planned deployments, open source wherever you look and orchestrated pods.

While many security experts and developers still see container technology as a big risk, Osnat urges us to consider security right from the start. This includes using verified internal pools of base images, dedicated users and minimizing packages with sensitive data such as Storing Keys.

Managed services are the new libraries

The term “DevOps” celebrates its tenth anniversary this year. Many of our readers will remember the time when Ops still provided software, servers and networks for developers. At that time this meant in part actually plugging a cable into a server rack, as Konstantin Diener revealed in his session – it sometimes took up to 6 weeks from ordering a server to commissioning. Today, thanks to cloud providers, it only takes a few seconds.

However, not only the way we provide software (via container technology) and where we host it (in the cloud) has changed, but the way we structure it has also changed significantly over the past ten years. While we often asked, “Is there a library for it?”, today people are more likely to ask whether there is a managed service that can be used for certain problems. Why use a library to write something yourself when you can simply implement the existing service into your own (microservice) architecture via API? Exactly…!

Infrastructure is not a pet (anymore)

Ops teams, who ten years ago still helped set up infrastructure, had a special relationship with their servers and platforms. Often one so intimate that they gave them pretty, trivial names, perhaps “Snuggles” or “snaggletooth”. This resulted in admins treating them like pets, loving and protecting them.

Infrastructure is not a pet (anymore)

Ops teams, who ten years ago still helped set up infrastructure, had a special relationship with their servers and platforms. Often one so intimate that they gave them pretty, trivial names, perhaps “Snuggles” or “snaggletooth”. This resulted in admins treating them like pets, loving and protecting them.

With the advent of Infrastructure as Code (IaC) and the cloud as the first hosting choice, a shift in this server-admin relationship began, Konstantin Diener noted in his session. Rather than being treated like pets, infrastructure today is treated more like livestock, with only names like 2019-node-1, 2019-node-2, and so on. This is of course enough for efficient functionality, but emotional connections have fallen by the wayside.

Closing thought

And finally, let us leave you on an ominous note thanks to Adam Nowak and Kamil Puk who said the following in their session, Continuous Everything – increasing business value by embracing the DevOps culture: