Konferenzprogramm

 

 

 

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

 

 

Thema: DevOps

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    06.02.
  • Dienstag
    07.02.
  • Mittwoch
    08.02.
  • Donnerstag
    09.02.
, (Montag, 06.Februar 2023)
18:30 - 20:00
Nmo 4
Closing the Developer Experience Gap of your Container Platforms
Closing the Developer Experience Gap of your Container Platforms

Due to the lack of user focus, lots of container platforms have a big developer experience GAP.

That's not only because building a Kubernetes platform is complex but also because deploying applications on Kubernetes requires expertise in many Container and Kubernetes concepts.
Developers today shouldn’t have to care how their applications run and focus on adding business value.

In this session, we will explore some of the powerful open source technologies available within the Kubernetes ecosystem to close the developer experience gap.

Target Audience: Developers, DevSecOps
Prerequisites: Basic knowledge in Kubernetes and software development
Level: Advanced

Extended Abstract:
Due to the lack of user focus, lots of container platforms have a big developer experience GAP.

That's not only because building a Kubernetes platform is complex but also because deploying applications on Kubernetes requires expertise in many Container and Kubernetes concepts. And once developers learn them, they still must spend a lot of time maintaining containers, writing YAML templates, and orchestrating many moving Kubernetes parts.

Like in the days when the Waterfall model was the standard for software development, developers today shouldn’t have to care where and how their applications run and focus on adding business value by implementing new features.

In this session, we will explore some of the powerful open source technologies available within the Kubernetes ecosystem to close the developer experience gap.

Timo Salm is based out of Stuttgart in southwest Germany and in the role of the first VMware Tanzu Solutions Engineer for Developer Experience in EMEA with a focus on VMware Tanzu Application Platform and commercial Spring products. In this role, he’s responsible for educating customers on the value, vision, and strategy of these products, and ensuring that they succeed by working closely on different levels of abstractions of modern applications and modern infrastructure.
Before Timo joined Pivotal and VMware, he worked for more than seven years for consulting firms in the automotive industry as a software architect and full-stack developer on projects for customer-facing products.

Timo Salm
Timo Salm
flag VORTRAG MERKEN

Vortrag Teilen

, (Dienstag, 07.Februar 2023)
09:00 - 10:45
Di 9.1
In wenigen Schritten zum sicheren Kubernetes-Cluster
In wenigen Schritten zum sicheren Kubernetes-Cluster

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.

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.

DevOps-Betriebsmodelle mit Site Reliability Engineering etablieren
DevOps-Betriebsmodelle mit Site Reliability Engineering etablieren

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.

Dehla Sokenou, Adrian Metzner
Halil Hancioglu
14:00 - 14:45
Di 9.2
Klimawandel trifft DevOps – DevGreenOps
Klimawandel trifft DevOps – DevGreenOps

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.

Justus Graumann
Justus Graumann
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 9.3
If it is About Cloud Native Transformation ... It Is Still About People! (Experience Report)
If it is About Cloud Native Transformation ... It Is Still About People! (Experience Report)

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.

Maryse Meinen
17:45 - 18:45
Di 7.4
DDD und DevOps sind das perfekte Team – warum?
DDD und DevOps sind das perfekte Team – warum?

Diese Session zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und warum man beide Ansätze kombinieren sollte. Wir werden dabei auf die kulturellen Aspekte beider Ansätze eingehen und herausarbeiten, dass die Kombination aus DevOps und DDD zu sehr gut geschnittenen cross-funktionalen Teams mit Ende-zu-Ende-Verantwortung für einen klar abgegrenzten fachlichen Bereich führt.

Der Vortrag zeigt zudem auf, welche Wege sie beschreiten können, damit aus einem "you build it, you run it" ein "you design it, you build it and you run it" wird.

Zielpublikum: Architekt:innen, Projektleiter:innen, Entscheider
Voraussetzungen: DevOps- und DDD-Grundlagen sind vorteilhaft
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Das DevOps-Versprechen "You build it, you run it" wird mittlerweile in zahlreichen Unternehmen ernst genommen und erfolgreich etabliert. Durch die enge Zusammenarbeit zwischen Entwicklung und Betrieb können zahlreiche Hürden überwunden und Release-Prozesse beschleunigt werden.

Darüber hinaus wollen wir mit einer agilen Denkweise weg von einem traditionellen Projektdenken hin zu einem Produktdenken kommen. Für Letzteres ist jedoch eine weitere Fähigkeit relevant: das Wissen über die Geschäftsdomäne.

Hier kommt die Softwarearchitekturdisziplin Domain-driven Design (DDD) ins Spiel, die eine sehr enge Zusammenarbeit zwischen Domänenexpert:innen und Entwicklungsteams propagiert.

Dieser Vortrag gibt Ihnen einen Überblick über Domain-driven Design und zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und welche Vorteile sich aus der Kombination der beiden Ideen ergeben. Darüber hinaus wird kurz erörtert, wie Microservices mit Domain-driven Design harmonieren. Zusammenfassend werden wir im Laufe der Präsentation sehen, dass aus einem "you build it, you run it" dank Domain-Driven Design ein "you design it, you build it and you run it" werden kann.

Michael Plöd ist Fellow bei INNOQ. Seine aktuellen Interessengebiete sind Microservices, Domain-driven Design, Alternativen zu alt eingewachsenen Softwarearchitekturen, Event Sourcing und Präsentationstechniken für Entwickler und Architekten. Michael ist zudem Autor des Buchs „Hands-on Domain-driven Design - by example“ auf Leanpub.

Michael Plöd
Michael Plöd
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 9.4
Infrastructure as Code – Betrieb ohne Handarbeit
Infrastructure as Code – Betrieb ohne Handarbeit

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)

Tim Digel
Tim Digel
flag VORTRAG MERKEN

Vortrag Teilen

, (Mittwoch, 08.Februar 2023)
09:00 - 10:45
Mi 3.1
Beyond Taming Technical Debt
Beyond Taming Technical Debt

Discipline, determination, a highly visible area, and a few sticky notes, are all you need to move beyond problems with technical debt.

Target Audience: Developers, Project Leader, Designers, Product Owners, Decision Makers
Prerequisites: Basic Knowledge of Software Development Process
Level: Basic

Extended Abstract:
## Making great software is challenging
It doesn't matter how qualified a team is, it will never be able to produce perfect, flawless, entirely bug-free software.
While teams are discovering how to build the right software in the right way, the environment the team operates in changes.
This results in a constant reorientation of the product, and the corresponding software solution, which will cause gaps between how things work, and how they should work.
Unfortunately, the market won't wait infinitely until teams have addressed these issues in the software, and organizations tend to run out of patience too.
That is why teams often have to move forward with designs and code that are ... let's call them sub-optimal.
These gaps, they are technical debt: a loan against the future, where things will be fixed, at some point ... Hopefully.
According to a global survey performed by Stripe, Inc. amongst software engineers in 2018, researchers found that **engineers estimate to spend 17,3 hours per week on addressing technical debt**.
That same research established that developers work about 41.1 hours per week. With that in mind, addressing technical debt constitutes well over a third of the time a typical engineer spends per week.
**If engineers are spending that much time, how could they better utilize their attention?**
Why do they seem unable to gain control over this metric and push it downwards?
While technical debt sounds nice and predictable: "you just have to pay interest", it really is like a loan with a mobster, and not with a bank.
It will show up unannounced at your doorstep at 3.30 in the morning, demanding that you pay up now!
How can you prevent being surprised by this goon?! And what can you do to leverage the benefits of borrowing against the future?
Because when the conditions are right, taking out a loan and paying it back Tomorrow might just help you ship a better product today.

## Imagine...
- A lightweight process to discover technical debt without a big investment up front
- A data-driven approach to identify the technical debt that needs attention right now
- A system that is easy to introduce, and simple to enforce
- Something that will guide engineers to articulate technical debt in terms of our roadmap
- Which will ultimately improve the flow of work in your organization

## The Wall of Technical Debt™️
A few years ago [Mathias Verraes coined the term "_The Wall of Technical Debt_"][1]. During this presentation Marijn Huizendveld will show you how to institute such a process for managed technical debt. Doing so will provide you with a safety net that allows you to make "naive" design choices every now and again to ship your ideas as fast as possible, without sacrificing sustainable delivery in the long run.
[1]: verraes.net/2020/01/wall-of-technical-debt/

Marijn Huizendveld – In a small backstreet of Tokyo lives a man named Aki, a 78 years old former chef. Aki spent most of his life trying to perfectly cook the rice he buys from his friend Mato. He's been at it for 57 years now, and still searches for ways to improve his cooking methods. There is probably not too much anybody else could tell Aki about cooking this specific type of rice. When it comes to his process, Aki's understanding is unrivaled.
After years of trial and error, Marijn Huizendveld could be called the Aki of Domain-Driven Design, due to his extensive background in both programming and strategy. He uses this experience to show teams and organizations how to recognize and act on problems and opportunities in an autonomous, self-learning fashion.

Maintenance and Evolution of Large Scale Software Systems – Business, Dev & Ops Challenges
Maintenance and Evolution of Large Scale Software Systems – Business, Dev & Ops Challenges

Even in the time of agile software development and devOps, maintenance and evolution of large-scale software systems remain challenging. This is not only caused by technical debt, but is heavily caused by lost knowledge, high complexity of micro-service architectures, difficult requirements management, not available documentation, and the complexity of communication among and coordination of the many stakeholders. In our session we will talk about the challenges we identified in our study and present new approaches to address these challenges.

Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: Project Management Experience, Software Maintenance
Level: Expert

Martin Kropp is professor for Software Engineering at the University of Applied Sciences Northwestern Switzerland. His interest is in everything that makes software development more efficient, build automation, testing, refactoring and development methodologies.

As a software engineer, Janick Rüegger worked in different teams from web development to platform engineering. In his master’s degree, he focuses on the challenges of large-scale software development.

Marijn Huizendveld
Martin Kropp, Janick Rüegger, Andreas Meier
Marijn Huizendveld

Vortrag Teilen

Martin Kropp, Janick Rüegger, Andreas Meier
flag VORTRAG MERKEN

Vortrag Teilen

, (Donnerstag, 09.Februar 2023)
09:00 - 10:45
Do 9.1
Nix geht über Docker
Nix geht über Docker

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.

Kubernetes Developer Survival Kit
Kubernetes Developer Survival Kit

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.

Johannes Maier
Sandra Parsick
Sandra Parsick
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 9.2
OpenTelemetry from an Ops Perspective
OpenTelemetry from an Ops Perspective

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.

Philipp Krenn
Philipp Krenn
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 9.3
Kontinuierlich und automatisiert dokumentieren – Docs-as-Code in der Praxis
Kontinuierlich und automatisiert dokumentieren – Docs-as-Code in der Praxis

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.

Falk Sippach
Falk Sippach
flag VORTRAG MERKEN

Vortrag Teilen

15:45 - 16:30
KeyDo 2
KEYNOTE: Making Sure the New Platform is Actually an Improvement
KEYNOTE: Making Sure the New Platform is Actually an Improvement

Since the dawn of software development, programmers have been perpetually occupied with migrating our "legacy" code to "the new platform". As soon as we finish, it is obsolete, and we need to start over. Today we are typically in the midst of moving to the cloud. We need DevOps, microservices, new frontend frameworks ... there is always some new tool that promises to deliver much better value than our existing solutions. Millions - even billions - are spent on these initiatives. Are they worth it? For whom?
In this presentation we will go through various strategies and their tradeoffs. How can we work with our code bases, staff and users to maximise the actual value delivered? The answer will depend on many things. Be conscious of what exactly you are aiming to achieve.

Christin Gorman has more than 20 years experience with hands-on software development. She is currently working on a large migration project in the Norwegian healthcare sector. She has worked for both startups and large enterprises, on systems varying from real-time control systems to e-commerce. What is important in one field is not necessarily important in others. Both in writing and in presentations, she is known for her entertaining way of raising questions about established truths, and making people think about why they are working the way they do.
Sometimes controversial, but never boring.

Christin Gorman
Christin Gorman
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 9.4
GitOps geht auch ohne Kubernetes
GitOps geht auch ohne Kubernetes

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.

Gerd Aschemann
Gerd Aschemann
flag VORTRAG MERKEN

Vortrag Teilen

Zurück