Immer häufiger werden Anwendungen auf einem Kubernetes-Cluster betrieben. Umso wichtiger ist die Absicherung gegen Angriffe von außen, aber auch innerhalb des Clusters.

Wir demonstrieren anhand von praktischen Beispielen, wie mit wenigen Schritten ein Cluster abgesichert werden kann. Ausreden, warum nicht mehr Sicherheit möglich ist, gibt es dann nicht mehr.

Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse in Kubernetes und Security, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In den letzten Jahren hat sich Kubernetes als Plattform für Anwendungen etabliert. Es verspricht, das Deployment deutlich zu vereinfachen, birgt aber auf der anderen Seite eine höhere Komplexität.

Oft wird der Betrieb auf einem Kubernetes-Cluster als zusätzliche Aufgabe auf das Entwicklungsteam übertragen, ohne die entsprechende Expertise aufzubauen. Das Wissen um Kubernetes bleibt dann lückenhaft, das Management des Clusters steht nicht im Fokus. In der Konsequenz stehen viele Kubernetes-Cluster ungeschützt im Netz.

Im Vortrag konzentrieren wir uns auf den Aspekt der Sicherheit eines Kubernetes-Clusters gegen Angriffe von außen, aber auch innerhalb des Clusters. Dabei gehen wir Schritt für Schritt durch die verschiedenen Schichten und zeigen anhand praktischer Beispiele, mit welchen Maßnahmen der Cluster abgesichert werden sollte.

Ein Erfolgsmuster zur Umsetzung von DevOps ist Site Reliability Engineering (SRE). Sie fördert objektiv die Zusammenarbeit zwischen Teams in einem skalierenden Umfeld. Besonderheit: Die System-Zuverlässigkeit wird zum Nummer 1 Feature! In diesem Vortrag werden die SRE-Prinzipien erläutert und SRE-Praktiken veranschaulicht. Abgerundet wird der Vortrag durch die Veranschaulichung des Aufbaus von Betriebsmodellen mit SRE.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundkenntnisse in agilen Methoden und Betriebsmodellen
Schwierigkeitsgrad: Anfänger

The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production yet. What do you need to keep in mind for your instrumentation infrastructure?

* Quick OpenTelemetry overview.
* Tradeoffs between the three architectures you use with OTel (depending on your vendor): vendor exporter vs OTel Collector vs OTel protocol support
* Sampling, including head vs tail based, and how to keep it representative and / or useful.

Target Audience: Architects, Developers
Prerequisites: Software development knowledge and some monitoring experience is also helpful
Level: Advanced

Extended Abstract:
The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production. What do you need to keep in mind for your instrumentation infrastructure? OpenTelemetry is THE emerging standard for monitoring and creating more observable systems. Starting with an overview, this talk then dives into two areas that make a big difference in cost, flexibility, and insights:

Firstly, the three possible integration architectures with vendor exporter, OpenTelemetry Collector, and native protocol support; and why a combination of Collector and native protocol are the most common choice today.
Secondly, sampling or how to get the big picture from a subset of the data (and cost). Here the tradeoffs evolve around head- vs tail-based sampling and how to keep the collected data representative and / or useful. It generally comes down to simpler and cheaper with the head-based approach, while the tail-based one is potentially more useful with higher overhead. And now it's time to roll it out in production!

I will share our hands-on experience with a cloud native (container) transformation that is currently unfolding. Technically, implementing an Open Shift Container Platform (bare metal) is pretty challenging. Doing this in a way that we will have pretty stuff in our data centers and at the same time making sure that our technical possibilities are actually being used effectively by product developers ... is a different challenge all together.

Join this session if you'd like to hear what we figured out about the people side of this kind of change!

Target Audience: Architects, Management, Developers, Operational Heroes, Product Owners, Agile Coaches, Scrum Masters
Prerequisites: Basic knowledge of DevOps concepts
Level: Advanced

Extended Abstract:
In this session I will share our hands-on experiences implementing a container-based architecture in our organisation. Choosing to implement Open Shift (bare metal) as your container platform is pretty difficult and challenging technically. It is also rather exciting and not too difficult to find smart people willing to help you build and run this new platform. However, it turns out that there is far more to this challenge than just the technology. Therefore, we are adopting an evolutionary implementation approach - stringing together small experiments - towards a flexible, more experimental and proactive culture that will allow us to actually benefit from the technical possibilities our new platform offers. This session is our story of our evolutionary and experimental approach and what we discovered along the way that works in this kind of transformation. Our main "discovery" is that even though at first it seemed mostly a technical transformation, it actually is far more of a human challenge.

We are right in the middle of this transformation so in this talk, I will bring you the latest and most valuable insights and experiences regarding this organisational and cultural transformation that is needed to turn the potential of our container platform into actual value for our organisation. We will summarise our ideas in a practical "this might work" list (bear in mind however there are no best practices, just patterns that might work in your specific situation).

An example of an experiment that turned out useful in our situation is: "create a small separate team that will drive this change". In our organisation we strive to build end-to-end teams, so at first we tried to get this new platform started from within the regular Infra DevOps team (as a huge Epic on the backlog). But people however got swamped in work and annoyed by all the context switching this required. Team members got tired and frustrated with the huge amounts of work, sky high ambitions and lack of progress. So, in the end we did a small experiment by creating a separate, dedicated, core team to get things going. This experiment turned out to be successful (and was thus extended) because it allowed team members to focus on the development of the platform and to build, document and share their experiences along the way, so that this team is also able to incrementally onboard the other teams along the way. Busy OPS-teams and product teams can't just develop the new platform on the side, next to all their other ongoing work. Building a container platform is epic and needs dedicated time and focus, also to keep people in their best energy.

I will share some of our most useful experiments and experiences, all having to do with the human side of this container transformation.

This session is not meant for decision making on going cloud native or not. If you do go cloud native, please bear in mind it is still about people, most of all!

Diese Session zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und warum man beide Ansätze kombinieren sollte. Wir werden dabei auf die kulturellen Aspekte beider Ansätze eingehen und herausarbeiten, dass die Kombination aus DevOps und DDD zu sehr gut geschnittenen cross-funktionalen Teams mit Ende-zu-Ende-Verantwortung für einen klar abgegrenzten fachlichen Bereich führt.

Der Vortrag zeigt zudem auf, welche Wege sie beschreiten können, damit aus einem "you build it, you run it" ein "you design it, you build it and you run it" wird.

Zielpublikum: Architekt:innen, Projektleiter:innen, Entscheider
Voraussetzungen: DevOps- und DDD-Grundlagen sind vorteilhaft
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Das DevOps-Versprechen "You build it, you run it" wird mittlerweile in zahlreichen Unternehmen ernst genommen und erfolgreich etabliert. Durch die enge Zusammenarbeit zwischen Entwicklung und Betrieb können zahlreiche Hürden überwunden und Release-Prozesse beschleunigt werden.

Darüber hinaus wollen wir mit einer agilen Denkweise weg von einem traditionellen Projektdenken hin zu einem Produktdenken kommen. Für Letzteres ist jedoch eine weitere Fähigkeit relevant: das Wissen über die Geschäftsdomäne.

Hier kommt die Softwarearchitekturdisziplin Domain-driven Design (DDD) ins Spiel, die eine sehr enge Zusammenarbeit zwischen Domänenexpert:innen und Entwicklungsteams propagiert.

Dieser Vortrag gibt Ihnen einen Überblick über Domain-driven Design und zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und welche Vorteile sich aus der Kombination der beiden Ideen ergeben. Darüber hinaus wird kurz erörtert, wie Microservices mit Domain-driven Design harmonieren. Zusammenfassend werden wir im Laufe der Präsentation sehen, dass aus einem "you build it, you run it" dank Domain-Driven Design ein "you design it, you build it and you run it" werden kann.

Mit Terraform, Ansible/Nixos und Continous Deployment per Knopfdruck zum Betrieb.

In diesem Vortrag betrachten wir Herausforderungen, die bei der Inbetriebnahme von Software aufkommen und setzen Infrastructure as Code mit Terraform, Ansible/NixOS und Continous Deployment beispielhaft um. Wir legen für ein Beispielprojekt live Infrastruktur an, konfigurieren diese und spielen die Software darauf. Bei allen Schritten gehen wir auf die Vorteile und die wenigen Nachteile von Infrastructure as Code ein.

Zielpublikum: Architekt:innen, Entwickler:innen, Admins, DevOps
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Mit Terraform, Ansible/Nixos und Continous Deployment per Knopfdruck zum Betrieb. Der Mehrwert jeder Software kann frühstens erlangt werden, wenn sie betrieben wird. In vielen Fällen ist das dann der Fall, wenn sie auf entsprechender Infrastruktur installiert und betriebsbereit ist. Dafür benötigen wir die Infrastruktur, müssen diese mit Betriebssystemen und nötigen Softwarekomponenten versehen und konfigurieren. Dies ist bei kleinen Systemen oft trivial, doch bei zunehmender Komplexität stellt sich schnell heraus, dass der Aufbau und die Wartung einer stabilen Infrastruktur schwierig ist.

Daher sollen alle nötigen Schritte automatisiert werden, nachvollziehbar sein und jederzeit reproduzierbar durchgeführt werden können. Dafür kommt Infrastructure as Code zum Einsatz. Alle nötigen Definitionen und nötigen Schritte werden mit Konfigurationsdateien, als Code oder mit Domain Specific Languages (DSL) zum eigentlichen Quellcode der Software festgehalten.

Mit Terraform wird die Infrastruktur an sich definiert. Dabei wird z. B. festgelegt, wie viele virtuelle Maschinen mit welchen Ressourcen benötigt werden, wie die Netzwerk- und IP-Konfiguration erfolgen oder in welchem Rechenzentrum die Software betrieben werden soll.

Sobald die Infrastruktur vorhanden und zugänglich ist, muss diese konfiguriert werden. Mit Ansible und NixOS gibt es zwei Ansätze jeden Installations- und Konfigurationsschritt zu definieren und automatisch zur Anwendung zu bringen.

Im Betrieb stellt man sich dann der nächsten Herausforderung: Software muss häufig und regelmäßig aktualisiert werden. Eine Automatisierung ist nahezu unumgänglich. Mit Continuous Deployment und als Code definierten Schritten in z. B. Github Actions gelangt die Software vollautomatisch auf die Infrastruktur.

In diesem Vortrag betrachten wir Herausforderungen, die bei der Inbetriebnahme von Software aufkommen und setzen Infrastructure as Code mit Terraform, Ansible/NixOS und Continous Deployment beispielhaft um.

Wir zeigen das Werkzeug Terraform, mit dem Infrastruktur providerabhängig definiert und einheitlich angewendet und erstellt werden kann. Mit Ansible oder NixOS stellen wir eine (oder beide) Möglichkeiten vor, das Betriebssystem eines Servers mit Quellcode und Konfigurationsdateien automatisiert zu konfigurieren.

Mit einem kurzen Einblick einer möglichen Continous Deployment Konfiguration in Github Actions zeigen wir eine weitere Möglichkeit, Code zu schreiben, anstatt händische Arbeit zu verrichten.

Bei allen Schritten gehen wir auf die Vorteile und die wenigen Nachteile von Infrastructure as Code ein. Ein größeres Augenmerk liegt auf der Dokumentationseigenschaft von Infrastuktur, die auf diese Weise definiert werden. Dies erspart viel weitere Arbeit im Betriebskonzept. Sofern zeitlich machbar wird im Vortrag live Infrastruktur angelegt, konfiguriert und eine Software darauf aufgespielt werden.

Discipline, determination, a highly visible area, and a few sticky notes, are all you need to move beyond problems with technical debt.

Target Audience: Developers, Project Leader, Designers, Product Owners, Decision Makers
Prerequisites: Basic Knowledge of Software Development Process
Level: Basic

Extended Abstract:
## Making great software is challenging
It doesn't matter how qualified a team is, it will never be able to produce perfect, flawless, entirely bug-free software.
While teams are discovering how to build the right software in the right way, the environment the team operates in changes.
This results in a constant reorientation of the product, and the corresponding software solution, which will cause gaps between how things work, and how they should work.
Unfortunately, the market won't wait infinitely until teams have addressed these issues in the software, and organizations tend to run out of patience too.
That is why teams often have to move forward with designs and code that are ... let's call them sub-optimal.
These gaps, they are technical debt: a loan against the future, where things will be fixed, at some point ... Hopefully.
According to a global survey performed by Stripe, Inc. amongst software engineers in 2018, researchers found that **engineers estimate to spend 17,3 hours per week on addressing technical debt**.
That same research established that developers work about 41.1 hours per week. With that in mind, addressing technical debt constitutes well over a third of the time a typical engineer spends per week.
**If engineers are spending that much time, how could they better utilize their attention?**
Why do they seem unable to gain control over this metric and push it downwards?
While technical debt sounds nice and predictable: "you just have to pay interest", it really is like a loan with a mobster, and not with a bank.
It will show up unannounced at your doorstep at 3.30 in the morning, demanding that you pay up now!
How can you prevent being surprised by this goon?! And what can you do to leverage the benefits of borrowing against the future?
Because when the conditions are right, taking out a loan and paying it back Tomorrow might just help you ship a better product today.

## Imagine...
- A lightweight process to discover technical debt without a big investment up front
- A data-driven approach to identify the technical debt that needs attention right now
- A system that is easy to introduce, and simple to enforce
- Something that will guide engineers to articulate technical debt in terms of our roadmap
- Which will ultimately improve the flow of work in your organization

## The Wall of Technical Debt™️
A few years ago [Mathias Verraes coined the term "_The Wall of Technical Debt_"][1]. During this presentation Marijn Huizendveld will show you how to institute such a process for managed technical debt. Doing so will provide you with a safety net that allows you to make "naive" design choices every now and again to ship your ideas as fast as possible, without sacrificing sustainable delivery in the long run.
[1]: verraes.net/2020/01/wall-of-technical-debt/

Even in the time of agile software development and devOps, maintenance and evolution of large-scale software systems remain challenging. This is not only caused by technical debt, but is heavily caused by lost knowledge, high complexity of micro-service architectures, difficult requirements management, not available documentation, and the complexity of communication among and coordination of the many stakeholders. In our session we will talk about the challenges we identified in our study and present new approaches to address these challenges.

Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: Project Management Experience, Software Maintenance
Level: Expert

Software containerisiert auszuliefern, ist mittlerweile sehr etabliert. Selbst bei Beachtung gängiger Best Practices ist es jedoch schwierig, Docker-Images reproduzierbar und sicher zu machen. Mögliche Folgen sind beispielsweise Versionskonflikte oder plötzlich fehlschlagende CI-Pipelines.

Mit dem Package-Manager Nix kann man einen großen Teil dieser Probleme vermeiden. Insbesondere das Nix-Tooling rund um Docker ermöglicht eine schmerzfreie Erstellung vollständig reproduzierbarer und minimaler Docker-Images.

Zielpublikum: Entwickler:innen, Architekt:innen, Dev-Ops-Ingenieure
Voraussetzungen: Docker-Basiswissen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Es wird eine kurze Einführung in die Nix-Toolchain und -Programmiersprache geben. Wir schauen uns ein Beispielprojekt an, in dem verschiedene Technologien zum Einsatz kommen. Dabei identifizieren wir gemeinsam diverse Problem einer sehr naiven Dockerisierung des Projekts, und versuchen im Anschluss, diese mit einer "nixifizierten Variante" zu lösen. Als Resultat erhalten wir cache-freundlich minimale und reproduzierbare Docker-Images ‒ baubar sogar ohne Docker-Installation.

Grundlegende Erfahrung mit Docker wird vorausgesetzt. Vorwissen zu Nix ist keine Notwendigkeit.

Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Kubernetes-Kenntnisse, allgemeine Entwicklungskenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"
Dieser Vortrag geht am Beispiel einer Java-Anwendung die typischen Entwicklungsschritte von der Ablage im VCS bis hin zum Deployment auf einem Cluster aus Sicht einer Entwicklerin durch.

Angetrieben durch Bewegungen wie Fridays For Future hat sich unser Fokus wieder auf die Klimaveränderung gerichtet. Unternehmen achten immer mehr darauf, klimaneutral zu werden und/oder klimaneutrale Produkte zu liefern.

Was hat das eigentlich für Auswirkungen auf unser herkömmliches IT-Verständnis? Machen wir einfach weiter wie bisher? Gibt es Einflüsse auf die DevOps-Bewegung?

Dieser Vortrag versucht Aufklärung und gibt erste Schritte, wie wir unsere Denkweise anpassen können.

Zielpublikum: Alle DevOps-Fans, Entscheider
Voraussetzungen: Cloud Verständnis, DevOps
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
DevOps und eigentlich auch die agile Bewegung stellen eine hohe Valueorientierung in den Fokus, und zwar Valueorientierung für den Kunden.

Ist das überhaupt noch gültig? Oder können wir bestehende Methodiken wie Wertstromanalysen noch weiterhin benutzen?

Zudem schauen wir uns an, wie uns Cloudprovider helfen bei der Unterstützung, CO2-Emissionen erst mal zu verstehen. Wie schon in Gemba, heißt es zunächst, den Verbrauch zu sehen und danach Maßnahmen zur Verbesserung durchzuführen.

Was können Maßnahmen sein? Da werden wir uns auch paar Beispiele ansehen. Unter anderen neue Faktoren in der Auswahl einer Cloudregion.

Since the dawn of software development, programmers have been perpetually occupied with migrating our "legacy" code to "the new platform". As soon as we finish, it is obsolete, and we need to start over. Today we are typically in the midst of moving to the cloud. We need DevOps, microservices, new frontend frameworks ... there is always some new tool that promises to deliver much better value than our existing solutions. Millions - even billions - are spent on these initiatives. Are they worth it? For whom?
In this presentation we will go through various strategies and their tradeoffs. How can we work with our code bases, staff and users to maximise the actual value delivered? The answer will depend on many things. Be conscious of what exactly you are aiming to achieve.

Im Gegensatz zu den klassischen Ansätzen verfolgt Docs-as-Code das Ziel, die in Softwareprojekten relevante Dokumentation genau wie den Quelltext zu behandeln. Somit können die gleichen Werkzeuge wie für die Entwicklung verwendet werden, um die Erzeugung und Auslieferung in die automatisierten Build-Prozesse einzubinden.

Jedwede Art von Dokumentation gewinnt somit an Sichtbarkeit und durch die Eingliederung in die Entwicklungsprozesse und die damit verbundene kontinuierliche Weiterentwicklung steigen Qualität und Akzeptanz bei den Lesern.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Grundlegende Kenntnisse von Architekturdokumentation und für automatisiertes Build-Management
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dokumentation wird häufig vernachlässigt. Mit dem Docs-as-Code-Ansatz wird die in Softwareprojekten relevante Dokumentation genau wie Quellcode behandelt, in der Versionsverwaltung abgelegt, mit leichtgewichtigen Entwicklerwerkzeugen (IDE/Texteditor, Build-Tools, CI/CD-Pipelines) bearbeitet und in die Softwareentwicklungsprozesse integriert. Die Inhalte können redundanzfrei verwaltet und manche Informationen aus Modellen oder dem Quellcode generiert werden. Durch die Verwendung leichtgewichtiger Text- und Grafikformate lassen sich die Ergebnisse einfach zielgruppenorientiert zusammenstellen. Die Verarbeitung erfolgt automatisiert über die schon vorhandenen Build-Prozesse.

Jedwede Art von Dokumentation gewinnt somit an Sichtbarkeit, durch die Eingliederung in die Entwicklungsprozesse und die damit verbundene kontinuierliche Weiterentwicklung steigt die Qualität und damit die Akzeptanz bei den Lesern. Dokumentation kann sogar ausgeführt werden, um zum Beispiel eingebettete Architekturregeln regelmäßig automatisiert zu testen. Die Zuhörer erfahren in diesem Vortrag an konkreten Beispielen, wie sie mit Documentation as Code starten können, welche typischen Fallstricke sie umschiffen und mit welchen konkreten Tools sie am besten arbeiten sollten.

Fast jeder kennt das Problem, dass die Konfiguration eines Systems oft (weit) vom gewünschten Zustand (desired state) abweicht. Statt den Zustand (nur) zu dokumentieren oder programmatisch herzustellen, kann man ihn bei GitOps auch deklarativ beschreiben, z. B. mit Terraform, und in Git ablegen. Änderungen lassen sich als Workflow z. B. über eine Pipeline-Engine realisieren.

Der Workflow ermöglicht den flexiblen Roll-Out von Änderungen. Ursprünglich wurde GitOps auf Kubernetes realisiert, das Konzept lässt sich aber auf andere Systeme übertragen.

Zielpublikum: Architekt:innen, Entwickler:innen, Site Reliabilty Engineers
Voraussetzungen: Dev- oder Ops-Kenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Vortrag erläutert das Konzept von GitOps am Deployment einer einfachen Anwendung und der dazugehörigen Infrastructure as Code mit Terraform. Dabei werden die typischen Abläufe von Deployments als Workflow auf einem Git-Repository über eine Pipeline realisiert, angelehnt an das bekannte two-phase-commit Pattern aus verteilten Transaktionen:

•    Vorbereitung des Deployments (prepare)
•    (Optionale) Qualitätssicherung des Deployments (review, test)
•    Durchführung des Deployments (perform/commit)

Zur Qualitätssicherung kann explizit ein personalisiertes Review (4-Augen-Prinzip) gehören. Darauf aufbauend lässt sich auch ein Rollback auf einen früheren Zustand durchführen (reverse commit).
Der Autor hat ein solches System mehrfach außerhalb von Kubernetes implementiert bzw. solche Implementierungen benutzt. Damit lässt sich zeigen, dass das Konzept, das ursprünglich für Kubernetes gedacht war und in mehreren Implementierungen vorliegt, auch außerhalb von Kubernetes nutzbar ist.