In Anwendungen, die Machine Learning-Komponenten enthalten, müssen bereits in der Entwicklung eine Metrik zur Überwachung, besondere Qualitätsmerkmale wie Erklärbarkeit und Fairness und ebenso die ständige Weiterentwicklung mitgedacht werden. 

Das beschert derartigen Anwendungen eine besondere Position im Bereich des DevOps und mit MLOps entsteht eine eigenständige Sparte. 

In diesem Talk gehe ich auf die besonderen Anforderungen im Betrieb ein und welche Auswirkungen diese auf die Entwicklung haben. 

Zielpublikum: Architekt:innen und Entwickler:innen 
Voraussetzungen: Ein Grundverständnis von DevOps ist notwendig, ein Verständnis von ML ist hilfreich 
Schwierigkeitsgrad: Fortgeschritten 

 Extended Abstract: 
Bei klassischer Software-Entwicklung wird Business-Logik anhand von Regeln von Software-Entwicklern kodiert. Diese Regeln sind entweder unmittelbar gegeben (z. B. Gesetzestexte) oder entstehen durch die Analyse einer Domäne in Form von Anforderungen. 

Machine Learning-Modelle basieren dagegen nicht auf expliziten Regeln, sondern werden durch für die Domäne repräsentative Daten trainiert. Das Herausarbeiten von Regeln übernimmt hier also auch die Maschine und nicht der Mensch. Da die Welt und die meisten Domänen nicht stillstehen, ist dies allerdings ein dynamischer Prozess. Ein Modell kann selten einmal trainiert werden und dann über längere Zeit in Produktion gehalten werden. 

Dies erfordert bereits in der Entwicklungsphase eine Metrik, mit der man bestimmen kann, wie gut ein solches Modell noch auf die Realität passt. Zudem muss für viele Anwendungen die Erklärbarkeit gewährleistet und auch in Produktion geliefert werden. 

Im Bereich von Teams bedeutet das die Einführung weiterer Rollen und eine neue Form von Zusammenarbeit zwischen diesen. 

Was MLOps umfasst, ist bisher nicht geschlossen festgelegt, sondern eher definiert darüber, was man braucht, um Machine Learning-Modelle in Produktion zu bringen und dort erfolgreich zu halten. Mit Sicherheit müssen wir über die Integration in bestehende Software, die Aufteilung in Services und das Monitoring sprechen. 

Diese Session beschränkt sich nicht auf die Konzepte, sondern demonstriert diese anhand einer durchgängigen Anwendung. 

At a big town hall, a manager mentions DevOps, how that can help our company, and that it is necessary to switch to DevOps as our leading culture/process. Simple, yes? But what often gets forgotten is what needs to be changed to succeed in that culture switch and the expectation that it is a journey. I will show you two teams in the same company with the same presentation and how they went completely different directions. What we have learned from that and what I can give you as advice.

Target Audience: Developers, Managers, Team Leads, Ops, Decision Makers, Project Leader
Prerequisites: Basic knowledge of what DevOps is about
Level: Advanced

Extended Abstract:
Why is it so hard to move to a DevOps culture? This a common question from managers as they already talked about the advantages and got positive feedback from the team. On the other hand, developers now think they must be full-stack developers and ops specialists but still earn a developer salary. Then there is the Ops team, who struggles with the outcome of the development teams and their new role in the process. Everybody else is confused by the word DevOps and starts to think it is a new position in the company (well, you find DevOps team leads and specialists on job platforms).

Changing a company to follow a DevOps-oriented culture is a big project and should be planned accordingly. You will have setbacks; the bigger the company, the longer it will take. If you understand that this is a journey and that you cannot simply copy another company's culture, then you are at the right starting point.

Der Weg in die Cloud ist herausfordernd, insbesondere wenn ein gewachsenes Ökosystem den Ausgangspunkt bildet. Denn in einer langen Historie entstanden vielfältige Spezialitäten und organisatorische Eigenheiten. Für eine erfolgreiche Migration sind daher die Bereiche Organisation, Architektur und Infrastruktur gemeinsam anzugehen.

In diesem Vortrag möchte ich aufzeigen, was Cloud-Migration und Cloud Native eigentlich bedeutet und welche Konsequenzen daraus abgeleitet werden sollten.

Zielpublikum: Projektleiter:innen, Manager, Entscheider, Architekt:innen
Voraussetzungen: Projekterfahrung, Cloudmigrationserfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Cloud-Migration ist der Prozess der Verlagerung von Arbeitslasten, Daten, Anwendungen und Prozessen in eine Cloud-Umgebung. In den meisten Fällen werden die Ressourcen von einem lokalen Rechenzentrum zu einem Cloud-Anbieter geschoben. Manchmal auch von einem Cloud-Anbieter zu einem anderen.

Die Gründe sind vielfältig. Manche Unternehmen erhoffen sich geringere Kosten, andere mehr Flexibilität, und manchmal zwingen Vorschriften dazu, mehr als einen Cloud-Anbieter zu nutzen. Was auch immer der Grund sein mag, eine einfache Umstellung auf die Cloud ist nicht immer erfolgversprechend und kann auch nicht die Vorteile und das Versprechen der Cloud ausschöpfen. Darüber hinaus kann die Umstellung auf die Cloud neue Anforderungen an das Unternehmen stellen und Veränderungen erfordern. Eine Veränderung, die für alteingesessene Unternehmen nicht immer einfach ist.

In diesem Vortrag werde ich aufzeigen, was Cloud-Migration und Cloud Native eigentlich bedeutet und welche Konsequenzen daraus abgeleitet werden sollten. Anschließend zeige ich die Herausforderungen einer solchen Migration auf und gebe Empfehlungen für ein schrittweises Vorgehen. Natürlich darf auch die Sicherheit der Umgebungen und Daten nicht außer Acht gelassen werden. Ich informiere über die zu berücksichtigenden Sicherheitsaspekte. Schließlich formuliere ich Migrationsmuster, die bewährte Verfahren aus vielen Migrationsprojekten beschreiben.

Die DevOps-Bewegung bricht Silos zwischen Entwicklung und Betrieb auf. Etliche Unternehmen sind intern auf dieser Reise weit gekommen. Sobald sie jedoch externe IT-Lieferanten beauftragen, entstehen oft wieder die alten Silos: Der Lieferant baut die Lösung und übergibt sie für den Betrieb an den Kunden.

Dabei muss das nicht so sein. Auch externe IT-Lieferanten können gemäß der DevOps-Philosophie mit ihren Kunden (zusammen-) arbeiten. Konstantin Diener zeigt euch einige Muster und praktische Beispiele dafür.

Zielpublikum: Entwickler:innen, Product Owner, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten