On-Call is an increasing reality for developers, especially when a site has strict uptime requirements. And sadly, the experience often sucks. It's easy to mandate 24x7 support, it's much harder to set it up in a way that doesn't make the life of the people in the rotation miserable.
I want to talk about improving alerting. I'm focusing on creating high-quality alerts that trigger when they should and don't trigger when nothing is happening. Continuous tuning, automation, and using the right metrics are core parts of this process.

Target Audience: Developers, Architects, DevOps, Operators
Prerequisites: Monitoring, operating production software
Level: Advanced

Extended Abstract
Do you believe in “you build it, you run it”? What if you have on-call rotations, where you are responsible 24x7 for the health of a system? Nothing is quite so infuriating as a collection of poorly structured alerts that trigger randomly.
So, let’s do better! I want to talk about how to improve your monitoring capabilities. There are a few topics I want to touch:

• Reduce the noise
• Automate as much as possible
• Build actionable triggers
• Tune your monitoring constantly

After this talk, you’ll have concrete actions to make your engineers’ life easier when on-call.

krankheitsbedingt ein kurzfristiger Wechsel

Content Management Systeme, Web-Browser oder Betriebssystem: Viele der Produkte und Services die wir täglich nutzen werden mittlerweile als Open Source Projekte realisiert. Durch den hohen Einfluss, den die Open Source Entwicklung mittlerweile auf die digitale Welt hat, findet man allerdings auch viele unterschiedliche Aussagen über dieGefahren und Vorteile von Open Source Produkten. Vor allem wenn man sich selber noch nicht intensiv mit der Thematik auseinander setzen konnte ist es hierdurch schwer, fachlich korrekte Bewertungen zu Open Source Produkten treffen zu können.

Basierend auf der Mitarbeit an verschiedenen großen Projekten in der Eclipse Foundation und des Java Ökosystems werde ich in diesem Vortrag nicht nur die theoretische Definition von Open Source vorstellen, sondern auch zeigen, wie Open Source Projekte in der Praxis entstehen und weiterentwickelt werden. Wir werden uns auch anschauen, warumOrganisationen Software als Open Source veröffentlichen und welche neuen und interessanten Geschäftsmodelle sich hierbei ergeben. Hierbei werden auch die Themen wie Lizenzen, Security und Support von Open Source Produkten angesprochen, welche durch Beispiele wie OpenSSL und den 2014 veröffentlichten Heartbleed-Bug konkretisiert werden.

Das im Vortrag vermittelte Wissen soll helfen, Open Source Software besser verstehen und einschätzen zu können. Mit diesem Fachwissen können die verschiedenen Gefahren und Vorteile, die durch die Nutzung von Open Source Komponenten entstehen, in Zukunft besser beurteilt werden.

Due to the capabilities of Kubernetes, the usage of patterns rises to solve complex questions, but causing often confusion and unnecessary implementations. This talk intends to show what are the right scenarios for and for which cases another pattern is more suitable.
In this talk, Max will introduce you to various patterns, often misused by running applications and services within Kubernetes. The focus will be on structural patterns like Sidecars and Ambassadors as well as more advanced patterns like Controller and Operator.

Target Audience: Architects, DevOps Engineers, Platform Teams
Prerequisites: Good Understanding of Kubernetes
Level: Basic

Additional Information:
From this talk, you should take away in which scenario a pattern will suit most likely and how you can implement it. We will also look critically at the usage of these patterns.

How do you do DevSecOps in practice? What are relevant tools and practices? Based on his work as a consultant and as a member of the advisory board that publishes the Thoughtworks Technology Radar Erik will give an overview of tools and practices that have proven themselves in real-world use. And because security is now relevant at each step of the process, the scope of the talk is broad. It includes architecture, the software supply chain, fitness functions and how to implement them in a build pipeline, as well as runtime monitoring.

Target Audience: Architects, Developers, Ops
Prerequisites: Knowledge of continuous delivery and DevOps
Level: Advanced

Extended Abstract

Closer collaboration between developers and operations people brought businesses many benefits. It is also fair to say, though, that it created new headaches. Some practices, especially continuous deployments, forced us to rethink the traditional security sandwich, with conceptual work up-front and a pen test at the end. It was easy to sneak a “Sec” into DevOps, it was reasonably obvious to call for security to be “shifted-left”, but in practice this raised even more questions.

Based on his experience working as a consultant Erik will address these quesions. He will discuss practices like container security scanning, binary attestation, and chaos engineering, alongside examples of concrete tooling supporting these practices. In addition Erik will show how the concept of fitness functions, which have become popular in evolutionary approaches architecture, can be applied in the security domain.

The clean code principles are well-known in modern, agile software development. But what has become the default for our business code, unfortunately by no means applies to our infrastructure code. Instead, we find badly crafted, complicated and highly tangled code that is manually tested using a trial and error approach. However, for modern cloud based systems the infrastructure code plays a crucial role. So it's about time we begin to treat it as a 1st class citizen! This hands-on session shows how to craft clean infrastructure as code.

Target Audience: Architects, Developers, DevOps Engineers, SREs
Prerequisites: Basic knowledge of infrastructure as code practices and tools
Level: Advanced

Um in verteilten Anwendungslandschaften den Überblick zu behalten, gibt es schon seit einiger Zeit unterschiedliche Ansätze, um Daten wie Metriken, Traces und Logs zentralisiert zu analysieren. Die Uneinheitlichkeit machte es bislang aufwendig, wirklich alle Komponenten einfach zu berücksichtigen. Im Jahr 2019 wurde unter dem Dach der Cloud Native Computing Foundation (CNCF) OpenTelemetry als herstellerneutrales, quelloffenes Ökosystem mit dem Ziel geschaffen, die Erfassung und Übertragung von Telemetriedaten zu standardisieren.

Zielpublikum: Architects, Developers, Process Owners, DevOps, Decision Makers
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract
In dieser Session werden die Spezifikation von OpenTelemetry und deren Bestandteile kurz vorgestellt. Es wird gezeigt, wie eine Integration bei Java-Anwendungen und die Verknüpfung mit gängigen Bibliotheken (Drop-In Instrumentation) erfolgt, so dass sich am Ende ein Business-Prozess bzw. die Anfrage eines Nutzers systemübergreifend verfolgen lässt. Die Beispiele lassen sich auf die z. Zt. zehn weiteren unterstützten Programmiersprachen übertragen. Zuletzt wird auf die Interaktion mit Cloud-Infrastruktur eingegangen, da OpenTelemetry sich insbesondere auf cloud-native Anwendungen fokussiert.

In diesem Vortrag berichtet die SüdLeasing - eine 100%ige Tochter einer Landesbank - von ihrem Weg von der “Legacy-IT” zur modernen cloud-basierten Umgebung. Aufgrund der Sensitivität der Daten lag von der ersten Sekunde ein besonderer Fokus auf dem Thema Cloud Security.
Business Continuity und Disaster Recovery wurden voll automatisiert mit Hilfe von Terraform, Access Control Lists und Microsoft Azure aufgebaut.

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

Extended Abstract
Die Digitalisierung traditioneller Unternehmen und damit meist zwingend verbundene Modernisierung der IT macht auch vor dem Sektor der Finanzdienstleister nicht Halt.
In diesem Vortrag berichtet die SüdLeasing - eine 100%ige Tochter einer Landesbank - von ihrem Weg von der “Legacy-IT” zur modernen cloud-basierten Umgebung. Aufgrund der Sensitivität der Daten lag von der ersten Sekunde ein besonderer Fokus auf dem Thema Cloud Security.
Hier berichten Tamira Horn und Thorsten Jakoby von der Reise eines BaFin regulierten Finanzdienstleisters in die Cloud. Statt "das sichern wir durch eine Firewall und Netzwerke", wurden Multi-Tenant-Zero-Trust-Architekturen aufgebaut.
Business Continuity und Disaster Recovery wurden voll automatisiert mit Hilfe von Terraform, Access Control Lists und Microsoft Azure aufgebaut.
Wir zeigen mit Beispielen und Demos, wie wir es technisch umgesetzt haben, nicht das Rechenzentrum in die Cloud zu migrieren, sondern eine sichere und flexible Plattform zu designen, um uns auf den Weg in die Cloud vorzubereiten.

I will introduce two AWS services: CodeGuru and DevOps Guru.
CodeGuru Reviewer uses ML and automated reasoning to automatically identify critical issues, security vulnerabilities, and hard-to-find bugs during application development.
DevOps Guru analyzes data like application metrics, logs, events, and traces to establish baseline operational behavior and then uses ML to detect anomalies. It does this by having the ability to correlate and group metrics together to understand the relationships between those metrics, so it knows when to alert.

Target Audience: Developers, Architects, Decision Makers
Prerequisites: Basic understanding of the code quality metrics and observability
Level: Basic

Extended Abstract
In this talk I will introduce two AWS services: CodeGuru and DevOps Guru.
Code reviews are one example and are important to improve software quality, software security, and increase knowledge transfer in the teams working with critical code bases. Amazon CodeGuru Reviewer uses ML and automated reasoning to automatically identify critical issues, security vulnerabilities, and hard-to-find bugs during application development. CodeGuru Reviewer also provides recommendations to developers on how to fix issues to improve code quality and dramatically reduce the time it takes to fix bugs before they reach customer-facing applications and result in a bad experience
Amazon DevOps Guru analyzes data like application metrics, logs, events, and traces to establish baseline operational behavior and then uses ML to detect anomalies. The service uses pre-trained ML models that are able to identify spikes in application requests. It does this by having the ability to correlate and group metrics together to understand the relationships between those metrics, so it knows when to alert and when not to.

In der Cloud-Szene ist es Trend, über 6R zu reden, d. h. die 6 Möglichkeiten zum Wechsel in die Cloud. Doch wenige haben bisher einen "Re-Purchase", also die Lieferung gleicher Funktionalität mit einer neuen Software, jemals in der Praxis gesehen. Dies ist die Reise eines Consumer-Produkts nach Hause - auf unsere Public Cloud, umgesetzt mit einem anderen Open-Source-Produkt. Wie funktioniert die Migration von mehreren Millionen Kunden und 5 Petabyte Daten im laufenden Betrieb? Wie geht Customizing und Vollautomatisierung mit Terraform?

Zielpublikum: Jeder, der sich für reale, moderne Cloud-Migrationen interessiert
Voraussetzungen: Grundlagen von Public Cloud und DevOps-Automatisierung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Dieser Erfahrungsbericht besteht aus 5 Teilen:
1. Minmal-invasive Anpassungen an einem Open-Source-Produkt
2. Hochskalierende Cloud-Installationen einer klassischen Web-Architektur auf Public Cloud - mit verbreiteten Lösungsmustern (und ohne Kubernetes)
3. "Zero-Intervention"-Administration mit einer Terraform-Vollautomatisierung
4. Auf die harte Tour: Wie sieht der kontinuierliche Ablauf einer Live-Migration aus? Welche Optionen gibt es, was braucht man dafür und wie plant man richtig?
5. Das kleine Architekten & Scrum-Master FAQ: Teams und der menschliche Faktor

In diesem Vortrag beschreiben wir die Entwicklungsstufen unseres Deploymentprozesses hinsichtlich der Infrastruktur in der Cloud.
Von der managed Cloud über "Infrastructure as Code" mit Cloudformation, das für ein dediziertes System funktionierte.
Inzwischen sind wir auf den GitOps-Ansatz gewechselt, mit dem wir stabile Infrastuktur-Deployments in Produktion bringen. Wir beschreiben, welche Herausforderungen zu lösen waren im Hinblick auf Configuration as Code, dem richtigen Git-Flow und der Einhaltung von Konzernvorgaben und ISO-Normen.

Zielpublikum: Entwickler:innen, DevOps-Engineers
Voraussetzungen: Grundwissen in Infrastruktur as Code, Pipelines, Automation
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Was ist die beste Vorgehensweise, um ein Produkt im Konzernumfeld für mehrere Mandanten auszurollen? Hoffentlich ein multimandantenfähiges Kaufprodukt einkaufen, das der Vorgabe der Prozesstrennung für Mandanten entspricht. Leider hatten wir in unserem Team kein solches Produkt zur Verfügung und standen vor der Herausforderung, für jeden Mandanten ein eigenes System aufsetzen zu müssen.
In diesem Vortrag beschreiben wir die drei Entwicklungsstufen unseres Deploymentprozesses hinsichtlich der Server-Infrastruktur in AWS inklusive Trennung der AWS-Accounts in Test- und Produktiv-Umgebungen. Die erste Phase beschreibt dabei den Aufbau einer managed Cloud mit festen Servern. Diese können zwar automatisiert eingerichtet werden, die automatische Skalierbarkeit ist aber unzureichend.
Die nächste Iteration beleuchtet den Ansatz des "Infrastructure as Code" über Cloudformation, der für ein dediziertes System sehr gut funktionierte. Probleme bereiteten uns der richtige Git-Flow und die fehlende Unterstützung für eine echte Trennung der Systeme pro AWS-Account.
In unserer aktuellen und hoffentlich finalen Iteration sind wir auf einen konsequenten GitOps-Ansatz gewechselt. Wir beschreiben, wie wir mit diesem Vorgehen seit Monaten stabile Infrastuktur-Deployments über Gitlab in Produktion bringen, welche Herausforderungen zu lösen waren im Hinblick auf Configuration as Code und dem richtigen Git-Flow. Auch die Erleichterung hinsichtlich der Einhaltung verschiedener Konzernvorgaben, beispielsweise der ISO 20000 an Release- und Changemanagment, darf hierbei nicht fehlen.

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 den automatisierten Build-Prozess 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
Voraussetzungen: Grundlegende Kenntnisse von Architektur-Dokumentation und über automatisiertes Build-Management
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Im Gegensatz zu den klassischen Ansätzen (Textverarbeitung, Wiki, Netzlaufwerke, ...) verfolgt Docs-as-Code den Ansatz, die in Softwareprojekten relevante Dokumentation genau wie den Quelltext zu behandeln. Für die entwickelnden Team-Mitglieder entsteht somit kein Medienbruch. Sie können die gleichen Werkzeuge (Texteditor, IDE, Build-Tools, CI/CD-Pipeline) verwenden, um die Inhalte als leichtgewichtige Textformate neben dem Sourcecode in der Versionsverwaltung abzulegen, die Änderungen gemeinsam mit dem Quellen zu reviewen, als Release zu markieren und auszuliefern sowie die zielgruppenorientierte Zusammenstellung der Ergebnisse in den Build-Prozess einzubinden. Um Redundanzen zu vermeiden, können aus den vorhandenen Projektmodellen (Sourcecode, DB-, UML-Modell, ...) automatisiert textuelle Inhalte und Diagramme generiert werden.
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 Architektur-Regeln regelmäßig automatisiert zu testen. Die Zuhörer erfahren in diesem Vortrag, wie sie mit Documentation as Code starten können, welche typischen Fallstricke sie umschiffen sollten und welche konkreten Tools bekannt sein sollten.