Das gesamte Konferenzprogramm auf einem Blick? Kein Problem, alle Programminhalte finden Sie hier jetzt auch als praktische PDF-Broschüre ganz bequem zum durchscrollen, downloaden oder ausdrucken:
Zur PDF-Broschüre
Track: DevOps – The Balance between Dev and Ops
- Dienstag
07.02. - Donnerstag
09.02.
Immer häufiger werden Anwendungen auf einem Kubernetes-Cluster betrieben. Umso wichtiger ist die Absicherung gegen Angriffe von außen, aber auch innerhalb des Clusters.
Wir demonstrieren anhand von praktischen Beispielen, wie mit wenigen Schritten ein Cluster abgesichert werden kann. Ausreden, warum nicht mehr Sicherheit möglich ist, gibt es dann nicht mehr.
Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse in Kubernetes und Security, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
In den letzten Jahren hat sich Kubernetes als Plattform für Anwendungen etabliert. Es verspricht, das Deployment deutlich zu vereinfachen, birgt aber auf der anderen Seite eine höhere Komplexität.
Oft wird der Betrieb auf einem Kubernetes-Cluster als zusätzliche Aufgabe auf das Entwicklungsteam übertragen, ohne die entsprechende Expertise aufzubauen. Das Wissen um Kubernetes bleibt dann lückenhaft, das Management des Clusters steht nicht im Fokus. In der Konsequenz stehen viele Kubernetes-Cluster ungeschützt im Netz.
Im Vortrag konzentrieren wir uns auf den Aspekt der Sicherheit eines Kubernetes-Clusters gegen Angriffe von außen, aber auch innerhalb des Clusters. Dabei gehen wir Schritt für Schritt durch die verschiedenen Schichten und zeigen anhand praktischer Beispiele, mit welchen Maßnahmen der Cluster abgesichert werden sollte.
Dehla Sokenou fühlt sich in allen Phasen der Software-Entwicklung zu Hause, besonders im Testen. Bei WPS - Workplace Solutions ist sie als Test- und Qualitätsmanagerin und Software-Architektin tätig.
Mehr Inhalte dieses Speakers? Schaut doch mal bei SIGS.de vorbei: https://www.sigs.de/experten/dehla-sokenou/
Adrian Metzner ist seit 2014 als Software-Entwickler unterwegs. Schwerpunkte sind dabei Sicherheit und DevOps. Bei WPS - Workplace Solutions ist er als Software-Architekt und Trainer für das ISAQB Cloud-Infra Modul tätig.
Ein Erfolgsmuster zur Umsetzung von DevOps ist Site Reliability Engineering (SRE). Sie fördert objektiv die Zusammenarbeit zwischen Teams in einem skalierenden Umfeld. Besonderheit: Die System-Zuverlässigkeit wird zum Nummer 1 Feature! In diesem Vortrag werden die SRE-Prinzipien erläutert und SRE-Praktiken veranschaulicht. Abgerundet wird der Vortrag durch die Veranschaulichung des Aufbaus von Betriebsmodellen mit SRE.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundkenntnisse in agilen Methoden und Betriebsmodellen
Schwierigkeitsgrad: Anfänger
Halil Hancioglu ist als Solution Architect für die OPITZ CONSULTING Deutschland GmbH tätig. Er verfügt über langjährige Erfahrung in der Erstellung von individuellen Enterprise-Applikationen und der Einführung von DevOps-Praktiken. Seine Stärken liegen in der Analyse und der Restrukturierung von Abläufen mit besonderem Fokus auf SRE, DevOps, Continuous Delivery und Infra-as-Code.
Vortrag Teilen
Vortrag Teilen
The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production yet. What do you need to keep in mind for your instrumentation infrastructure?
* Quick OpenTelemetry overview.
* Tradeoffs between the three architectures you use with OTel (depending on your vendor): vendor exporter vs OTel Collector vs OTel protocol support
* Sampling, including head vs tail based, and how to keep it representative and / or useful.
Target Audience: Architects, Developers
Prerequisites: Software development knowledge and some monitoring experience is also helpful
Level: Advanced
Extended Abstract:
The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production. What do you need to keep in mind for your instrumentation infrastructure? OpenTelemetry is THE emerging standard for monitoring and creating more observable systems. Starting with an overview, this talk then dives into two areas that make a big difference in cost, flexibility, and insights:
Firstly, the three possible integration architectures with vendor exporter, OpenTelemetry Collector, and native protocol support; and why a combination of Collector and native protocol are the most common choice today.
Secondly, sampling or how to get the big picture from a subset of the data (and cost). Here the tradeoffs evolve around head- vs tail-based sampling and how to keep the collected data representative and / or useful. It generally comes down to simpler and cheaper with the head-based approach, while the tail-based one is potentially more useful with higher overhead. And now it's time to roll it out in production!
Philipp Krenn lebt für technische Vorträge und Demos. Nachdem er mehr als zehn Jahre als Web-, Infrastruktur- und Datenbank-Entwickler gearbeitet hat, ist er mittlerweile Developer Advocate bei Elastic — dem Unternehmen hinter dem Open Source Elastic Stack, bestehend aus Elasticsearch, Kibana, Beats und Logstash. Auch wenn er in Wien zu Hause ist, reist er regelmäßig durch Europa und darüber hinaus, um über Open-Source-Software, Suche, Datenbanken, Infrastruktur und Sicherheit zu sprechen.
---------
Philipp Krenn lives to demo interesting technology. Having worked as a web, infrastructure, and database engineer for over ten years, Philipp is now a developer advocate and EMEA team lead at Elastic — the company behind the Elastic Stack consisting of Elasticsearch, Kibana, Beats, and Logstash.
Vortrag Teilen
I will share our hands-on experience with a cloud native (container) transformation that is currently unfolding. Technically, implementing an Open Shift Container Platform (bare metal) is pretty challenging. Doing this in a way that we will have pretty stuff in our data centers and at the same time making sure that our technical possibilities are actually being used effectively by product developers ... is a different challenge all together.
Join this session if you'd like to hear what we figured out about the people side of this kind of change!
Target Audience: Architects, Management, Developers, Operational Heroes, Product Owners, Agile Coaches, Scrum Masters
Prerequisites: Basic knowledge of DevOps concepts
Level: Advanced
Extended Abstract:
In this session I will share our hands-on experiences implementing a container-based architecture in our organisation. Choosing to implement Open Shift (bare metal) as your container platform is pretty difficult and challenging technically. It is also rather exciting and not too difficult to find smart people willing to help you build and run this new platform. However, it turns out that there is far more to this challenge than just the technology. Therefore, we are adopting an evolutionary implementation approach - stringing together small experiments - towards a flexible, more experimental and proactive culture that will allow us to actually benefit from the technical possibilities our new platform offers. This session is our story of our evolutionary and experimental approach and what we discovered along the way that works in this kind of transformation. Our main "discovery" is that even though at first it seemed mostly a technical transformation, it actually is far more of a human challenge.
We are right in the middle of this transformation so in this talk, I will bring you the latest and most valuable insights and experiences regarding this organisational and cultural transformation that is needed to turn the potential of our container platform into actual value for our organisation. We will summarise our ideas in a practical "this might work" list (bear in mind however there are no best practices, just patterns that might work in your specific situation).
An example of an experiment that turned out useful in our situation is: "create a small separate team that will drive this change". In our organisation we strive to build end-to-end teams, so at first we tried to get this new platform started from within the regular Infra DevOps team (as a huge Epic on the backlog). But people however got swamped in work and annoyed by all the context switching this required. Team members got tired and frustrated with the huge amounts of work, sky high ambitions and lack of progress. So, in the end we did a small experiment by creating a separate, dedicated, core team to get things going. This experiment turned out to be successful (and was thus extended) because it allowed team members to focus on the development of the platform and to build, document and share their experiences along the way, so that this team is also able to incrementally onboard the other teams along the way. Busy OPS-teams and product teams can't just develop the new platform on the side, next to all their other ongoing work. Building a container platform is epic and needs dedicated time and focus, also to keep people in their best energy.
I will share some of our most useful experiments and experiences, all having to do with the human side of this container transformation.
This session is not meant for decision making on going cloud native or not. If you do go cloud native, please bear in mind it is still about people, most of all!
Maryse Meinen is a product leader, currently working in a product owner role, building a full-blown container platform for a new IT infrastructure, together with an awesome team. She is also an active practitioner of Stoic philosophy, trying to live according to values like "humans are made for cooperation", "wisdom" and "perseverance". Always keeping an eye on the human aspect of our work, she strives to humanise our workplace a bit more every day.
Vortrag Teilen
Mit Terraform, Ansible/Nixos und Continous Deployment per Knopfdruck zum Betrieb.
In diesem Vortrag betrachten wir Herausforderungen, die bei der Inbetriebnahme von Software aufkommen und setzen Infrastructure as Code mit Terraform, Ansible/NixOS und Continous Deployment beispielhaft um. Wir legen für ein Beispielprojekt live Infrastruktur an, konfigurieren diese und spielen die Software darauf. Bei allen Schritten gehen wir auf die Vorteile und die wenigen Nachteile von Infrastructure as Code ein.
Zielpublikum: Architekt:innen, Entwickler:innen, Admins, DevOps
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Mit Terraform, Ansible/Nixos und Continous Deployment per Knopfdruck zum Betrieb. Der Mehrwert jeder Software kann frühstens erlangt werden, wenn sie betrieben wird. In vielen Fällen ist das dann der Fall, wenn sie auf entsprechender Infrastruktur installiert und betriebsbereit ist. Dafür benötigen wir die Infrastruktur, müssen diese mit Betriebssystemen und nötigen Softwarekomponenten versehen und konfigurieren. Dies ist bei kleinen Systemen oft trivial, doch bei zunehmender Komplexität stellt sich schnell heraus, dass der Aufbau und die Wartung einer stabilen Infrastruktur schwierig ist.
Daher sollen alle nötigen Schritte automatisiert werden, nachvollziehbar sein und jederzeit reproduzierbar durchgeführt werden können. Dafür kommt Infrastructure as Code zum Einsatz. Alle nötigen Definitionen und nötigen Schritte werden mit Konfigurationsdateien, als Code oder mit Domain Specific Languages (DSL) zum eigentlichen Quellcode der Software festgehalten.
Mit Terraform wird die Infrastruktur an sich definiert. Dabei wird z. B. festgelegt, wie viele virtuelle Maschinen mit welchen Ressourcen benötigt werden, wie die Netzwerk- und IP-Konfiguration erfolgen oder in welchem Rechenzentrum die Software betrieben werden soll.
Sobald die Infrastruktur vorhanden und zugänglich ist, muss diese konfiguriert werden. Mit Ansible und NixOS gibt es zwei Ansätze jeden Installations- und Konfigurationsschritt zu definieren und automatisch zur Anwendung zu bringen.
Im Betrieb stellt man sich dann der nächsten Herausforderung: Software muss häufig und regelmäßig aktualisiert werden. Eine Automatisierung ist nahezu unumgänglich. Mit Continuous Deployment und als Code definierten Schritten in z. B. Github Actions gelangt die Software vollautomatisch auf die Infrastruktur.
In diesem Vortrag betrachten wir Herausforderungen, die bei der Inbetriebnahme von Software aufkommen und setzen Infrastructure as Code mit Terraform, Ansible/NixOS und Continous Deployment beispielhaft um.
Wir zeigen das Werkzeug Terraform, mit dem Infrastruktur providerabhängig definiert und einheitlich angewendet und erstellt werden kann. Mit Ansible oder NixOS stellen wir eine (oder beide) Möglichkeiten vor, das Betriebssystem eines Servers mit Quellcode und Konfigurationsdateien automatisiert zu konfigurieren.
Mit einem kurzen Einblick einer möglichen Continous Deployment Konfiguration in Github Actions zeigen wir eine weitere Möglichkeit, Code zu schreiben, anstatt händische Arbeit zu verrichten.
Bei allen Schritten gehen wir auf die Vorteile und die wenigen Nachteile von Infrastructure as Code ein. Ein größeres Augenmerk liegt auf der Dokumentationseigenschaft von Infrastuktur, die auf diese Weise definiert werden. Dies erspart viel weitere Arbeit im Betriebskonzept. Sofern zeitlich machbar wird im Vortrag live Infrastruktur angelegt, konfiguriert und eine Software darauf aufgespielt werden.
Tim Digel (Netze BW GmbH)
Seit 2010 Web Development, IT Operations
2007-2016 Uni Tübingen, Diplom Mathematik
2016-2021 Software developer for Active Group, functional programming (Elixir, Scala, F#, Scheme, ...)
Seit 2021 Software developer für Netze BW, functional programming with Elixir, IT Operations (Azure Cloud, Ansible, Terraform, CI/CD)
Vortrag Teilen
Software containerisiert auszuliefern, ist mittlerweile sehr etabliert. Selbst bei Beachtung gängiger Best Practices ist es jedoch schwierig, Docker-Images reproduzierbar und sicher zu machen. Mögliche Folgen sind beispielsweise Versionskonflikte oder plötzlich fehlschlagende CI-Pipelines.
Mit dem Package-Manager Nix kann man einen großen Teil dieser Probleme vermeiden. Insbesondere das Nix-Tooling rund um Docker ermöglicht eine schmerzfreie Erstellung vollständig reproduzierbarer und minimaler Docker-Images.
Zielpublikum: Entwickler:innen, Architekt:innen, Dev-Ops-Ingenieure
Voraussetzungen: Docker-Basiswissen
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Es wird eine kurze Einführung in die Nix-Toolchain und -Programmiersprache geben. Wir schauen uns ein Beispielprojekt an, in dem verschiedene Technologien zum Einsatz kommen. Dabei identifizieren wir gemeinsam diverse Problem einer sehr naiven Dockerisierung des Projekts, und versuchen im Anschluss, diese mit einer "nixifizierten Variante" zu lösen. Als Resultat erhalten wir cache-freundlich minimale und reproduzierbare Docker-Images ‒ baubar sogar ohne Docker-Installation.
Grundlegende Erfahrung mit Docker wird vorausgesetzt. Vorwissen zu Nix ist keine Notwendigkeit.
Johannes Maier ist Software-Architekt bei der Active Group GmbH in Tübingen. Dort arbeitet er mit funktionalen Programmiersprachen, vorzugsweise Haskell, und nutzt dabei Nix, um komplexe Abhängigkeiten zu bändigen und Continuous Deployment zu erreichen. Wenn er nicht gerade mit seinen Kindern Lego baut, lötet er an seiner nächsten Tastatur oder konfiguriert Emacs.
Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"
Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Kubernetes-Kenntnisse, allgemeine Entwicklungskenntnisse
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"
Dieser Vortrag geht am Beispiel einer Java-Anwendung die typischen Entwicklungsschritte von der Ablage im VCS bis hin zum Deployment auf einem Cluster aus Sicht einer Entwicklerin durch.
Sandra Parsick ist Java Champion und arbeitet als freiberufliche Software-Entwicklerin und Consultant im Java-Umfeld. Seit 2008 beschäftigt sie sich mit agiler Softwareentwicklung in verschiedenen Rollen. Ihre Schwerpunkte liegen im Bereich der Java Enterprise-Anwendungen, Cloud, Software Craftsmanship und in der Automatisierung von Softwareentwicklungsprozessen. Darüber schreibt sie gerne Artikel und spricht auf Konferenzen. In ihrer Freizeit engagiert sich Sandra Parsick in verschiedenen Programmkomitees und Community-Gruppen.
Vortrag Teilen
Vortrag Teilen
Angetrieben durch Bewegungen wie Fridays For Future hat sich unser Fokus wieder auf die Klimaveränderung gerichtet. Unternehmen achten immer mehr darauf, klimaneutral zu werden und/oder klimaneutrale Produkte zu liefern.
Was hat das eigentlich für Auswirkungen auf unser herkömmliches IT-Verständnis? Machen wir einfach weiter wie bisher? Gibt es Einflüsse auf die DevOps-Bewegung?
Dieser Vortrag versucht Aufklärung und gibt erste Schritte, wie wir unsere Denkweise anpassen können.
Zielpublikum: Alle DevOps-Fans, Entscheider
Voraussetzungen: Cloud Verständnis, DevOps
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
DevOps und eigentlich auch die agile Bewegung stellen eine hohe Valueorientierung in den Fokus, und zwar Valueorientierung für den Kunden.
Ist das überhaupt noch gültig? Oder können wir bestehende Methodiken wie Wertstromanalysen noch weiterhin benutzen?
Zudem schauen wir uns an, wie uns Cloudprovider helfen bei der Unterstützung, CO2-Emissionen erst mal zu verstehen. Wie schon in Gemba, heißt es zunächst, den Verbrauch zu sehen und danach Maßnahmen zur Verbesserung durchzuführen.
Was können Maßnahmen sein? Da werden wir uns auch paar Beispiele ansehen. Unter anderen neue Faktoren in der Auswahl einer Cloudregion.
Justus Graumann hat es nach dem Studium in die IT-Branche verschlagen und seit 20 Jahren ist er, meistens im Java-Bereich, für verschiedene Unternehmen tätig. Seit nun mehr einigen Jahren ist er an verschiedenen Transformationsprojekten in der SwissRE beteiligt und gerade dabei, in seiner Domaine IT DevOps-Themen voranzutreiben. Nebenbei hält er auf diversen Konferenzen & MeetUps Vorträge.
Vortrag Teilen
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 die automatisierten Build-Prozesse 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, Entscheider
Voraussetzungen: Grundlegende Kenntnisse von Architekturdokumentation und für automatisiertes Build-Management
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Dokumentation wird häufig vernachlässigt. Mit dem Docs-as-Code-Ansatz wird die in Softwareprojekten relevante Dokumentation genau wie Quellcode behandelt, in der Versionsverwaltung abgelegt, mit leichtgewichtigen Entwicklerwerkzeugen (IDE/Texteditor, Build-Tools, CI/CD-Pipelines) bearbeitet und in die Softwareentwicklungsprozesse integriert. Die Inhalte können redundanzfrei verwaltet und manche Informationen aus Modellen oder dem Quellcode generiert werden. Durch die Verwendung leichtgewichtiger Text- und Grafikformate lassen sich die Ergebnisse einfach zielgruppenorientiert zusammenstellen. Die Verarbeitung erfolgt automatisiert über die schon vorhandenen Build-Prozesse.
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 Architekturregeln regelmäßig automatisiert zu testen. Die Zuhörer erfahren in diesem Vortrag an konkreten Beispielen, wie sie mit Documentation as Code starten können, welche typischen Fallstricke sie umschiffen und mit welchen konkreten Tools sie am besten arbeiten sollten.
Falk Sippach ist bei der embarc Software Consulting GmbH als Software-Architekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group-Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Falk.Sippach
Vortrag Teilen
Fast jeder kennt das Problem, dass die Konfiguration eines Systems oft (weit) vom gewünschten Zustand (desired state) abweicht. Statt den Zustand (nur) zu dokumentieren oder programmatisch herzustellen, kann man ihn bei GitOps auch deklarativ beschreiben, z. B. mit Terraform, und in Git ablegen. Änderungen lassen sich als Workflow z. B. über eine Pipeline-Engine realisieren.
Der Workflow ermöglicht den flexiblen Roll-Out von Änderungen. Ursprünglich wurde GitOps auf Kubernetes realisiert, das Konzept lässt sich aber auf andere Systeme übertragen.
Zielpublikum: Architekt:innen, Entwickler:innen, Site Reliabilty Engineers
Voraussetzungen: Dev- oder Ops-Kenntnisse
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Der Vortrag erläutert das Konzept von GitOps am Deployment einer einfachen Anwendung und der dazugehörigen Infrastructure as Code mit Terraform. Dabei werden die typischen Abläufe von Deployments als Workflow auf einem Git-Repository über eine Pipeline realisiert, angelehnt an das bekannte two-phase-commit Pattern aus verteilten Transaktionen:
• Vorbereitung des Deployments (prepare)
• (Optionale) Qualitätssicherung des Deployments (review, test)
• Durchführung des Deployments (perform/commit)
Zur Qualitätssicherung kann explizit ein personalisiertes Review (4-Augen-Prinzip) gehören. Darauf aufbauend lässt sich auch ein Rollback auf einen früheren Zustand durchführen (reverse commit).
Der Autor hat ein solches System mehrfach außerhalb von Kubernetes implementiert bzw. solche Implementierungen benutzt. Damit lässt sich zeigen, dass das Konzept, das ursprünglich für Kubernetes gedacht war und in mehreren Implementierungen vorliegt, auch außerhalb von Kubernetes nutzbar ist.
Gerd Aschemann arbeitet kontinuierlich daran, die Grenze zwischen Dev und Ops aufzuheben. Als freiberuflicher Software-Architekt aktualisiert und erweitert er permanent die agile Kultur und den Technologie-Stack seiner Kunden durch zeitgemäße Methoden und Komponenten. In den letzten Jahren hat er in mehreren Cloud-nativen Software-Projekten die Transition zu Continuous Delivery vorangetrieben.
Vortrag Teilen