Digitalization has been changing existing industry B2B businesses, digitalization business models arrived and the Digitalization solutions need to be developed to support this. The sudden enforcement of social distancing has given the digital transformation a significant push forward. How do we develop innovative Digitalization offerings in the future? We will show how to seize these opportunities and forge new paths toward the new normal for Software Engineering.

Target Audience: Software Engineers, System and Software Architects, Software Managers
Prerequisites: Knowledge in Software Engineering Practice
Level: Basic

To continuously deliver IT systems at speed with a focus on business value, high-performance IT delivery teams integrate quality engineering in their way of working.

Quality engineering is the new concept in achieving the right quality of IT systems. Testing only after an IT product was developed is an outdated approach. Built-in quality from the start is needed to guarantee business value in today’s IT delivery models. Quality engineering is about changes in skills, organization, automation and quality measures.

Target Audience: All people involved in high-performance IT delivery teams
Prerequisites: General knowledge of IT delivery
Level: Advanced

Extended Abstract

To continuously deliver IT systems at speed with a focus on business value, high-performance cross-functional IT delivery teams integrate quality engineering in their way of working.

Quality engineering is the new concept in achieving the right quality of IT systems. Testing an application only after the digital product has been fully developed has long been a thing of the past. More is needed to guarantee the quality of applications that are delivered faster and more frequently in today’s high-performance IT delivery models. It is about achieving built-in quality. The road to quality engineering means changes in terms of starting points, skills, organization, automation and quality measures.

Our new VOICE model guides teams to align their activities with the business value that is pursued, and by measuring indicators, teams give the right information to stakeholders to establish their confidence that the IT delivery will actually result in business value for the customers.

Teams benefit from the clear definition of QA&Testing topics that are a useful grouping of all activities relevant to quality engineering. Organizing topics are relevant to align activities between teams and performing topics have a focus on the operational activities within a team.

Also, to be able to deliver quality at speed, for today’s teams it is crucial to benefit from automating activities, for example in a CI/CD pipeline, whereby people must remember that automation is not the goal but just a way to increase quality and speed.

In this presentation the audience will learn why a broad view on quality engineering is important and how quality engineering can be implemented to achieve the right quality of IT products, the IT delivery process and the people involved.

This presentation is based on our new book "Quality for DevOps teams" (ISBN 978-90-75414-89-9) which supports high-performance cross-functional teams in implementing quality in their DevOps culture, with practical examples, useful knowledge and some theoretical background.

In large software projects the assessment of the impact of a code change can be a cumbersome task. If the software has grown and shows an evolutionary design there are always unwanted side effects.

Change control boards are established. But on what data do they judge what can happen with the changes? Very often there is the HIPPO syndrome which means it is the highest paid person's opinion.

In this talk we will show you ways to come to a deterministic prediction of the impact, what data you need and what you can do with it.

Target Audience: Architects, Test Managers, Developers, Testers
Prerequisites: Basic knowledge of collected data in software projects
Level: Advanced

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.

Mit Microservice-Architekturen & DevOps-Prozessen werden große zentrale Security Gateway-Installationen zunehmend in Frage gestellt. Die notwendige Koordination zwischen Anwendungsverantwortlichen, Administratoren, Entwicklern & Security führt zu Effizienzverlusten und Frustration. Besser wäre es, Security-Aufgaben mittels Microgateways zu erledigen. Der Vortrag beleuchtet technische und organisatorische Herausforderungen von Microgateways und zeigt in einer Demo, wie Microgateways genutzt werden können, um existierende Services zu schützen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract
Mit dem Aufkommen von Microservice-Architekturen und DevOps-Prozessen werden große zentrale Security Gateway-Installationen zunehmend in Frage gestellt. Die notwendige Koordination zwischen Anwendungsverantwortlichen, Administratoren, Entwicklern und dem Security-Team führt zu Effizienzverlusten und Frustration. Besser wäre es, wenn Security-Aufgaben nahe bei den zu schützenden Services mittels sogenannter Microgateways erledigt würden. DevOps-Teams könnten die Verantwortung für die Sicherheit ihrer Services von der ersten Minute an bis in die Produktion übernehmen (Shift Left). Der Vortrag beleuchtet technische und organisatorische Herausforderungen rund um den Einsatz von Microgateways. Zudem wird in einer Demo gezeigt, wie Microgateways konkret genutzt werden können, um existierende Services zu schützen.

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.

This talk describes how to build and run a successful product development organization that delivers business value, not just features. I will cover what makes effective product development teams, how to structure, loosely couple, align and choreograph them, especially in larger organisations with up to 100 teams. Methods I will talk about include OKRs and Kanban Flight Levels. In this context I will also show when and how decentralised product teams can benefit from centralised platforms.

Target Audience: CTO, Manager, Decision Makers
Prerequisites: Experience with software development at scale
Level: Advanced

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.