Microservices kommen als Architektur-Idee gut an, Kubernetes etabliert sich als ihre Laufzeitumgebung - plus seiner Komplexität.

Praktisch ist jedoch, dass es auch mit eigenen Operatoren erweitert werden kann. Sie können im Test und Deployment der Services mit all ihren definierten Abhängigkeiten und deren Konfigurationen durch Automatisierung helfen. Dies rundet Microservices ab und erleichtert das Leben.

Lassen Sie sich in die Idee und die Entwicklung von Operatoren einführen.

Zielpublikum: Entwickler:innen, DevOps
Voraussetzungen: Basiskenntnisse in Go und Kubernetes
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Das Ausrollen von Microservices in einem Kubernetes-Cluster kann ein recht manueller Prozess sein, welcher sich mit externen Tools automatisieren lässt. Doch dies lässt von Service zu Service noch viel Freiraum zu, insbesondere in Bezug auf Abhängigkeiten wie Datenbanken, Message Queue und weiteren Tools.

Kubernetes Operatoren erlauben die Verlagerung der Automatisierung von außen nach innen. Die durch die Services zu nutzenden Tools und ihre Standardkonfigurationen lassen sich so zum Beispiel vordefinieren, sodass für das Rollout eines neuen Service nur mehr eine relativ begrenzte Konfiguration notwendig ist. Ebenso können Tests automatisch angestoßen werden. Die Einsatzzwecke sind vielfältig.

Die Session führt in die Idee der Operatoren ein, zeigt die Client-Bibliothek ebenso wie den Kubebuilder und nimmt dann in die Entwicklung eines Microservice Operators mit.

Wir bei intersoft bauen in Hamburg die Software für unsere Mutterfirma, die WWK-Versicherung in München. Entfernung: > 6 h Bahnfahrt. Alter der beteiligten Software-Komponenten: > 30 Jahre. Ältestes bekanntes Betriebssystem: BS2000. Kulturen: Bajuwaren und Wikinger. All das bietet eine Menge Zündstoff für Konflikte.

Wir berichten mitten aus der HOST-Migration der WWK auf zeitgemäße IT, über die Koexistenz moderner Produktentwicklungsteams mit alten 2-Monats-Releasezyklen. Und darüber, wie uns das Corona-Virus hilft, besser zu werden.

((d[-_-]b))

Zielpublikum: Legacy & Innovation lovers
Voraussetzungen: None
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die HOST-Migration ist ein gigantisches und definierendes Projekt der WWK und muss bis 2023 abgeschlossen sein. Neben der ganz alten HOST-IT und der ganz neuen IT gibt es auch noch viel gewachsene Java-Software, die schon an den Rändern vergilbt. Insgesamt stehen wir damit vor einer entscheidenden Herausforderung für die Firma und vor einer Situation, die viele Unternehmen in ähnlicher Form kennen sollten. Neben den technischen Herausforderungen finden wir auch die organisatorischen und die kulturellen spannend. Wir berichten über:

Die entstehende Architekturarbeit zwischen Teams und Konzern.

Traditionelle Quality Gates in einem neuen gemeinsamen interkulturellen KANBAN Board.

Die schrittweise Verzahnung des Münchner Operations-Teams mit den Hamburger Entwicklern.

Wie sich QA im gesamten Prozess aus einem Test-Dungeon entwickelt

Wie ein Programm-Manager 3 Jahre vor der Rente beginnt, von Helm-Charts zu reden

Wir berichten davon, was schieflief und wo wir im Januar 2021 stehen werden

Das Vorhaben der HOST-Ablösung befindet sich nun schon im zweiten Jahr und wir haben gerade eine schlimme Frust-Phase hinter uns und ehrgeizige Meilensteine vor uns. Um von Frust auf Erfolg zu gehen, haben wir uns im Februar/März 2020 eng getaktete und frühe Liefertermine gesetzt. Interessanterweise hat das bei allen Stakeholdern zu viel Vertrauen geführt und die beteiligten Teams motiviert. Und dann kam Corona, und anstatt einer neuen Depression erleben wir, dass es besser läuft als erwartet. Auf einmal ist die gesamte Company gleich weit voneinander entfernt. Die Zusammenarbeit Hamburg, München und zurück läuft viel besser als vormals. Die Teams sind engagiert und hängen sich richtig rein. Meetings sind so effizient wie kaum zuvor.

Im Februar berichten wir dann live, wie es gelaufen ist und weiter geht.

Vor allen Dingen die Verzahnung von Produkt > Dev > QA > OPS in einen gemeinsamen schneller drehenden Prozess ermöglicht uns den Erfolg.

After years of introducing “CI”/CD-Pipelines, after using Jenkins, CircleCI, Docker and K8s, your teams still don’t deliver software within minutes? And your customers still know about bugs before you do? Well, maybe you’re doing it wrong.

We’ll share our experiences on how to incrementally get organisations and systems to be able to leverage all the things associated with “continuous everything”. We argue for solutions tailored to individual situations, and more connected to software craftsmanship than to buzzwords and boxed solutions.

Target Audience: Everyone with the challenge to get functionality to customers - quick
Prerequisites: Some knowledge about general software development
Level: Advanced

Extended Abstract:
After years of introducing “CI”/CD-Pipelines, after using Jenkins, CircleCI, Docker and K8s, your teams still don’t deliver software within minutes? And your customers still know about bugs before you do?

Maybe designing the perfect world during your first sprint just doesn’t cut it. The beautiful docker scaling idea just doesn’t work, because the “microservice” can only run in one instance at a time. The testautomation framework the Ops team provided can unfortunately not test your windows application. Your elasticsearch needs more and more space, but none of the developers have removed a single exception notification. The awesome buildpipeline with the included tests has a great dashboard that shows a red build continuously, but no one cares and you still do hotfixes on the production system. And your last major “refactoring” branch has been running green for the last two month, but you just can’t merge it back into your production code without breaking a few minds.

Well, maybe you’re doing it wrong.

Companies that successfully employ continuous delivery usually don’t excel in their tools. They excel in the architecture of their software, they excel in the way the people in the company work together, they excel in the way everyone actually understands what they are doing. In such environments people are not afraid of magic things that might happen in some unknown system, but leverage tools to automate things they themselves know how to do - so good that it gets boring and thus these tasks are better done by tools.

We’ll share our experiences on how to incrementally get organisations and systems to be able to leverage all the things associated with “continuous everything”. We argue for solutions tailored to individual situations, and more connected to software craftsmanship than to buzzwords and boxed solutions.

YAML seems to be the predominant way to describe our Kubernetes workloads. For each and every microservice we have to declare pods, deployments, services and a lot more. Now multiply this by several environments and deployment variants. The result often is excessive YAML bloat that leads to insufficient dev-prod parity, frustration and low developer productivity. So make sure to join this talk if you want to learn how to continuously deliver quality software and have happy Cloud-native developers on your team again.

Target Audience: Developers, Architects, Tech Leads, SREs
Prerequisites: Basic knowledge and experience with tools and practices of Cloud-native DevOps
Level: Advanced

Extended Abstract:
In this session we will have a closer look at several developer focused tools like Buildpacks, Helm, Kustomize, Skaffold and Tilt. These tools aim to improve and optimize the inner development loop by reducing the amount of YAML and the required steps from source to deployment significantly.