In großen Unternehmen entwickeln viele Teams REST APIs. Dabei gibt es einige Aufgaben, die sich wiederholen: z.B. Validierung, Test und Publikation. Der Aufbau einer API Operations Pipeline zur Automatisierung dieser Aufgaben ist aufwändig. Dieser Talk zeigt am Beispiel von Azure DevOps Templates, wie so eine Pipeline als Service angeboten werden kann. So kümmert sich ein spezifisches Team um die Entwicklung und Wartung der Pipeline, während alle anderen sich auf das Design und die Entwicklung ihrer APIs fokussieren können.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: OpenAPI, DevOps
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Folgendes lernen die Zuhörenden in der Session:

• Welche Vor- und Nachteile hat es, eine API Operations Pipeline zentral zur Verfügung zu stellen?
• Welche Aufgaben kann eine API Operations Pipeline übernehmen?
• Wie können konkrete Aufgaben wie Validierung und Test umgesetzt werden?
• Wie können Azure DevOps Templates für eine API Operations Pipeline als Service eingesetzt werden?
• Wie kann das Einbinden und die Nutzung dieser Pipeline für andere Teams vereinfacht werden?

Der Talk enthält eine interaktive Live-Coding Session zu API Contract Testing.

As more organizations are moving to the cloud, cloud architectures are getting more sophisticated by having a kind of technology diversity. This includes for example container orchestrators, database services, networking components & virtual machines.
When it comes to security, observability on this diversity is paramount. The main question here is, do you really perceive when your app landscape is under attack?
In this session, you'll have the opportunity to see various attack vectors & ways to mitigate them using different technologies.

Target Audience: Architects, Developers, Software Engineers
Prerequisites: Basic cloud & security knowledge
Level: Advanced

Extended Abstract:
Come and watch a live attack on a real-world based cloud architecture and see the attacker scan web applications and start lateral movement with the goal of exfiltrating data. Furthermore, become a part of the blue-team, defending and securing the architecture with modern open source tools.

"Which programming language is the fastest" usually is everyone's first thought when green software is mentioned! It's a common deduction that the fastest code is, therefore, the most efficient, which then, of course, can save us from this climate disaster. However, code efficiency is not even half of the story! In this talk, Sarah will review the three approaches that make software green. She will also introduce efficiency-achieving practices that can take us closer to fighting this pesky climate change.

Target Audience: Architects, Developers, SRE/DevOps
Prerequisites: Basic knowledge of any Programming Language, Introductory Familiarity with DevOps Space
Level: Basic

Extended Abstract:
In this talk, I will go over the following:

1. My journey so far with green software emphasizes how I don't need to leave my climate enthusiasm at home every day when I go to work
2. Brief facts about WHY we need to take action now in the tech industry
3. 3 approaches that make software green
4. Why code efficiency is not the answer to most green software problems with an example
5. Going over why DevOps practices are much more effective in achieving greenness in software with a couple of examples
6. Wrapping up with fruit for thoughts, especially highlighting the close connection between DevOps practices and Green Software practices
7. Encourage the audience to look at their software engineering problems through a green software lense

Data, the way that we process it and store it, is one of many important aspects of IT. Data is the lifeblood of our organizations, supporting real-time business processes and decision-making. For our DevOps strategy to be truly effective we must be able to safely and quickly evolve production databases, just as we safely and quickly evolve production code. Yet for many organizations their data sources prove to be less than trustworthy and their data-oriented development efforts little more than productivity sinkholes.

Target Audience: Developers, Data Engineers, DevOps Engineers
Prerequisites: Understanding of DevOps
Level: Advanced

Extended Abstract:
This presentation begins with a collection of agile principles for data professionals and of data principles for agile developers - the first step in working together is to understand and appreciate the priorities and strengths of the people that we work with. Our focus is on a collection of practices that enable development teams to easily and safely evolve and deploy databases. These techniques include agile data modeling, database refactoring, database regression testing, continuous database integration, and continuous database deployment. We also work through operational strategies required of production databases to support your DevOps strategy. If data sources aren’t an explicit part of your DevOps strategy then you’re not really doing DevOps, are you?

Organizations are drawn to migrate their systems into the cloud, but in practice, cloud transformations do not always succeed in achieving the advantages often promised by cloud providers, such as scalability, availability, and cost effectiveness.
We give an overview over Kevin Hoffmann's fifteen factors for cloud-native applications and how they help us achieve success in our cloud migrations.

Target Audience: Architects, Developers, Operations, DevOps
Prerequisites: Basic understanding of web services
Level: Basic

Extended Abstract:
You think you are already reaping the cloud's harvest by lifting and shifting your apps to some cloud-provided VM or container infrastructure?
You've already read about Heroku's (original) twelve factors, maybe even skimmed though Kevin Hoffmann's book, and think your app is good enough, because you are using Git, have a CI pipeline, and someone in the team once ran the app in a Docker container?
Or you think your team isn't going to the cloud any time soon and this advice does not apply to you anyway?
Maybe you're right. Chances are, you are in for a surprise, though.
The original twelve factors for cloud-native application development are (reasonably) well established and widely agreed upon. Yet, in practice, there appear to be some misunderstandings regarding their meaning, and we see cloud migrations fail precisely due to reasons that could be avoided by following these factors correctly. The extension to fifteen factors by Kevin Hoffmann is less widely known, but no less important for modern, cloud-native application landscapes, especially since this extension also revisits and updates the original twelve factors.
The goal of this talk is to disseminate and discuss the fifteen factors, as well as to emphasize their interrelations and embed them in the greater context of modern application development, in order to help reduce pain for many teams tasked with bringing their software to the cloud.

"Σπεύδε βραδέως" in ancient Greek, or "festina lente" in Latin translates as "hurry slowly" an oxymoron saying to indicate the need for balancing deliberation and urgency.
In this talk we comment on the prevailing perceptions relating to speed of software development and how in a DevOps context what sometimes is perceived as fast from an individual's perspective has a deleterious effect on team performance while practices traditionally viewed by developers as cumbersome have in fact a positive effect on team performance and effectiveness.

Target Audience: Software Engineers and DevOps Practitioners
Prerequisites: None
Level: Advanced

Extended Abstract:
The talk draws on the experience of multiple projects but uses the team setup and 2020/2021 data of the NHS Covid19 app's backend services teams as a showcase for a team that managed to avoid neglecting subjects like peer reviews, documentation, testing etc. in a high pressure, high pace environment.

Eine explizite Softwarearchitektur ist der Garant für erfolgreiche Softwareprojekte. Zur Unterstützung der Kommunikation braucht es eine inhaltlich hinreichende und aktuelle Dokumentation. Der Docs-as-Code-Ansatz unterstützt, indem die Dokumentation in Form leichtgewichtiger Text- und Grafikformate näher an den Quellcode gebracht, in der Versionsverwaltung abgelegt, mit leichtgewichtigen Entwicklerwerkzeugen (IDE/Texteditor, Build-Tools, CI/CD-Pipelines) bearbeitet und in die Softwareentwicklungsprozesse integriert wird.

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

Extended Abstract:
Der Vortrag stellt leichtgewichtige Methoden, Vorlagen und Tools vor, die zum Erstellen einer hochwertigen, sich selbst validierenden Softwaredokumentation eingesetzt werden. Wir schauen uns Ansätze wie Docs-as-Code, leichtgewichtige Textformate, Ablage in der Versionsverwaltung und die Einbettung in die Build- und Review-Prozesse an. Das Sichtbarmachen von Software-Architekturkonzepten im Code und das Einbinden von Software-Analyse-Werkzeugen ermöglichen den kontinuierlichen Abgleich der Soll- und Ist-Strukturen und machen die Architekturdokumentation lebendiger.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Falk.Sippach

Kubernetes ist omnipräsent. Entweder laufen die Anwendungen in Kubernetes oder sollen in Kubernetes laufen. Entwickler mögen sich jetzt denken "Aber was hat die Kubernetes-Infrastruktur mit mir als Entwickler zu tun?"
Dieser Vortrag gibt eine Kurzeinführung, was Kubernetes ist und aus welchen Komponenten es besteht. Beim Durchgehen der Komponenten und Konzepte steht die Sichtweise eines Entwicklers im Vordergrund. Am Ende nehmen die Zuhörer Good Practices anhand von Beispielen mit nach Hause.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Allgemeine Software-Entwicklungskenntnisse
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Kubernetes ist omnipräsent. Entweder laufen die Anwendungen in Kubernetes oder sollen in Kubernetes laufen. Entwickler mögen sich jetzt denken "Aber was hat die Kubernetes-Infrastruktur mit mir als Entwickler zu tun?"
Mit der Einführung von Kubernetes bekommen die Entwickler aber oft die Aufgabe, neben dem Anwendungscode jetzt auch noch Deployment-Skripte in Form von Kubernetes-Deskriptoren zu schreiben. Dafür brauchen sie ein Grundverständnis der Kubernetes-Komponenten.
Dieser Vortrag gibt eine Kurzeinführung, was Kubernetes ist und aus welchen Komponenten es besteht. Beim Durchgehen der Komponenten und Konzepte steht die Sichtweise eines Entwicklers im Vordergrund. Am Ende nehmen die Zuhörer Good Practices anhand von Beispielen mit nach Hause.

Warum reden Entwickler und Operator so oft aneinander vorbei?
Warum können sich viele Entwickler gar nicht vorstellen, wie die IT abseits ihrer JVM tickt?
Warum stoßen Entwickler auf Probleme, sobald es hardwarenaher wird?
Warum ist das Anbinden von Hardware für viele Entwickler ein Problem?
Warum versuchen viele Entwickler, alle Fehler mit dem Debugger in ihrer IDE zu finden?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung als Entwickler hilfreich
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Das Phänomen, dass viele junge Entwickler keinerlei Erfahrungen mit der "Welt da draußen" haben, beobachte ich immer wieder. Wie kommt dies?
Die IT ist zu komplex geworden! Beim Einstieg in die praktische IT kommen diese Themen gar nicht vor. Der Grund, warum ältere Entwickler dieses Wissen haben, ist nur, dass sie früher geboren wurden. So war es üblich, seine Homecomputer oder PCs selbst zusammenzubauen. Nicht weil es schick war, sondern weil man es machen musste.
Viel Wissen wurde so quasi "nebenbei" angeeignet.
Schaut man auf die Maker-Szene, so erlebt dieses Wissen wieder ein Revieval. Schließlich ist jeder Maker mit seinem Raspberry Pi nicht nur Entwickler, sondern auch gleich Operator bzw. Hardwaredesigner.
Dieser Talk zeigt einige Aspekte, wie Entwickler dieses Wissen mit viel Spaß und Vorgehen aus der Makerszene für ihre tägliche Arbeit nutzen können.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/thomas.ronzon

At Tchibo we wanted to reduce our server and energy consumption with our product development teams. But why would we care? We all like fast snappy development and test systems. And our shop needs to survive Black Friday’s shopping traffic. Annual Google Cloud consumption forecasts do not trigger us to consume less. But when we started to show teams their related carbon dioxide footprint, we created a feedback loop that will help us to become better CO₂-developers.
As developers, we have an impact - to program CO₂ reduction.

Target Audience: Everyone, Developers, DevOps People
Prerequisites: None
Level: Advanced

Extended Abstract:
We will present the idea and first measurements on the server side. The planned client side measurements are still work in progress and very difficult to perform. Nevertheless is the client side induced CO₂ consumption at large websites probably a large lever for reduction.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/johannes.mainusch

DevOps isn't dead yet and it will not die in the future. Platform engineering comes to leverage DevOps practices horizontally to support developers, operations and those in between. In this session, I will give you a perspective on how to move on from DevOps to Platform Engineering, how to design and shape your internal platform and build a vibrant community sharing best practices and enabling each other to overcome faster issues. In the end you will understand how we can reduce the cognitive load for dev teams to focus on features.

Target Audience: DevOps, Developer, Manager
Prerequisites: Experience in DevOps and an understanding of the pain of silos
Level: Advanced

Extended Abstract:
Platform Engineering is often seen as the evolution of DevOps. However, it is yet a new discipline using DevOps practices but focusing on the entire chain and breaking silos. I will show details from my experience on my job as well as 3 years of release engineering at Kubernetes where it wouldn't be possible to release without a proper platform.