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: Software Development
- Montag
06.02. - Dienstag
07.02. - Mittwoch
08.02. - Donnerstag
09.02.
This highly interactive workshop is all about software architecture - with Spring Boot, the Java microservice framework. Using an example application, we will discuss and try out the following topics in code:
- REST API design
- Hexagonal architecture
- Bean validation
- Single sign-on with Keycloak
- Role-based security
- Optimistic locking with ETags
- OWASP dependency check
- Structured JSON Logging
- Error handling
- Integration tests with Cucumber
- Architecture tests with ArchUnit
- Local deployment with Docker
- Reverse proxy with NGINX
Please install the following software before the workshop (if not already available):
- Java 17+
- Gradle 7.3+
- Docker 19+
- git
- an IDE of your choice (like IntelliJ IDEA)
On Windows, we also highly recommend you install the Windows Subsystem for Linux 2+.
Target Audience: Software Architects, Software Engineers, Java Developers
Prerequisites: Basic knowledge in Java, Interest in software architecture
Level: Advanced
Extended Abstract:
Prerequisites:
This workshop is highly interactive. You will benefit greatly from trying it out for yourself as well.
Please install the following software before the workshop (if not already available):
- Java 17+
- Gradle 7.3+
- Docker 19+
- git
- an IDE of your choice (like IntelliJ IDEA)
On Windows, we also highly recommend you install the Windows Subsystem for Linux 2+.
The example application "Chameleon" that will be used in this workshop has been designed as an educational example project for learning the basics of the Spring Boot ecosystem. But project "Chameleon" tries to be more than just a simple "hello world". It has all the needed parts in place to be as close to a "real world" production-ready software as possible.
Project "Chameleon" currently contains the following features:
General
- Backend with Spring Boot
- Yaml configuration file
- Hexagonal architecture
- Build with Gradle
- Local deployment with Docker
- Reverse proxy with NGINX
REST API
- Definition of RestController with GET, POST, DELETE and PATCH
- Description of REST API with OpenAPI
- Swagger UI
- Dtos
- Model mapper
- Bean validation
- Global error handler
- Local error handler
- Request ids
- Optimistic locking with ETags
Database
- Storage in relational database with PostgreSQL
- JPA, JpaRepository (Spring Data)
- Database migration with Flyway
Security
- Integration of SSO (single sign-on) with Keycloak
- Role-based security (JSR250)
- OWASP dependency check
Logging
- JSON logging
- Structured logging
- Logging of request ids
- Logging of user and roles
Testing
- Unit tests with JUnit 5
- Assertions with Google Truth
- Architectural unit tests with ArchUnit
- Coverage report of unit tests with JaCoCo
- Integration tests with Cucumber
Dr. Christoph Ehlers is the Head of Software Engineering at ConSol. As a project lead, agile coach and software architect, he ensures the successful completion of IT projects. After studying computer science at the University of Passau, where he also earned his doctorate, Christoph Ehlers found his way to ConSol more than seven years ago. He is particularly interested in software architecture and databases. Caution: His enthusiasm for technology is contagious!
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/christoph.ehlers
Approval testing is a technique that helps you to get a difficult codebase under test and begin to control your technical debt. Approval testing works best on larger pieces of code where you want to test for multiple things and interpreting failures is challenging.
In this hands-on session we'll introduce a commonly-used Approval testing tool for Java and through hands-on exercises learn to get control of some example code. The same tool is also available for many other programming languages, see https://approvaltests.com/
Bring a laptop.
Max. number of participants: 30
Target Audience: Developers, Architects
Prerequisites: Basic knowledge of Java and unit testing, bring a laptop
Level: Basic
Extended Abstract:
Introducing Approval Testing (55 minutes)
- Code Review: examine existing test case, discuss strengths & weaknesses
- Demonstration: Convert an assertion-based test to use Approval testing
- Hands-on exercise: Add some tests using Approvals.Java.
Break (5 minutes)
Approval Test Design (50 minutes)
- Presentation: Approval testing characteristics and design patterns
- Exercise: Using the default XML printer with Approvals.Java
- Demonstration: Using scrubbing with an XML printer
- Discussion: when to print, when to scrub
Printer Design (30 minutes)
- Exercise: Designing a printer for a domain object
- Presentation: Case studies
- Q&A (10 minutes)
Emily Bache is an independent consultant and Technical Coach. She works with developers, training and coaching effective agile practices like Refactoring and Test-Driven Development. Emily has written two books and teaches courses on platforms including Pluralsight and O’Reilly. A frequent conference speaker, Emily has been invited to keynote at prestigious developer events including EuroPython, Craft and ACCU. Recently Emily founded the Samman Technical Coaching Society, a not-for-profit organisation which aims to support and inspire technical coaches around the world.
Die Allianz ist ein weltweit agierender Versicherungskonzern, der auch mit vielen Partnern zusammenarbeitet. Diese Partner sind sowohl im Verkauf – z. B. Versicherungsmakler – oder auch im Schadensfalle – z. B. Autowerkstätten – aktiv.
Um die Geschäfte einfach und verlässlich durchführen zu können, verlangt es eine hohe Automatisierung. Diese Automatisierung verlangt nach einem API Ecosystem, das durch Partner einfach und effizient genutzt werden kann.
Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Prinzipielle Architekturkenntnisse, Prinzipielle Kenntnisse in API-Design
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Der Beitrag diskutiert den Weg der Allianz zu eine API Ecosystem und beleuchtet Stolperfallen genauso wie die Erfolge.
- Die ersten Ideen
- Das erste Proof of Concept
- Ein standardisiertes Vorgehen
- Wo wir sind und wie es weitergeht
Annegret Junker ist Lead Architect bei Allianz Deutschland. Sie arbeitet seit mehr als 30 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt. Derzeit arbeitet sie in einem großen Versicherungs-Projekt als übergreifende Architektin.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Annegret.Junker
Vortrag Teilen
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.
Vortrag Teilen
For a technology company, building a strong engineering culture is essential for long-term success. Today's software industry is growing so fast that a large proportion of developers will inevitably have less than 5 years experience. At the same time, many software systems contain code that is ten, twenty or even thirty years old.
It's a constant challenge to communicate a healthy culture to newcomers and prevent technical debt from getting out of control. Technical coaching is all about tackling those issues: culture and skills.
Target Audience: Developers, Architects
Prerequisites: None
Level: Basic
Extended Abstract:
The Samman method is a concrete coaching method for spreading skills and culture within an engineering organization. There are two main parts to the method:
- Learning Hour
- Ensemble working
In the learning hour the coach uses exercises and active learning techniques to teach the theory and practice of skills like Test-Driven Development and Refactoring. In two-hour Ensemble sessions the whole team collaborates together with the coach in applying agile development techniques in their usual production codebase.
In combination with strong technical leadership, the Samman method can enable the spread of skills and culture to bring a healthy engineering organization to the next level.
Emily Bache is an independent consultant and Technical Coach. She works with developers, training and coaching effective agile practices like Refactoring and Test-Driven Development. Emily has written two books and teaches courses on platforms including Pluralsight and O’Reilly. A frequent conference speaker, Emily has been invited to keynote at prestigious developer events including EuroPython, Craft and ACCU. Recently Emily founded the Samman Technical Coaching Society, a not-for-profit organisation which aims to support and inspire technical coaches around the world.
"Ich hatte keine Zeit, den Zaun zu flicken" - Dieses Zitat kennt wohl jeder, und doch ertappen wir uns selbst, unseren Zaun nicht geflickt, sondern stattdessen die Hühner gesucht zu haben.
Doch wie ändere ich das?
Dieser Vortrag zeigt mit dem Konzept der MLCs ein Tool auf, dieser Falle zu begegnen und sich selbst und andere in den Modus des kontinuierlichen Lernens zu versetzen.
Am Ende haben die Zuhörenden einen ersten MLC durchlaufen und ein Tool erlernt, um sich und anderen den Freiraum zum Lernen zu erschaffen.
Zielpublikum: Coaches, Entscheider, Projektleiter:innen, Transformation Manager, Architekt:innen, Lebenslange Lernende
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Micro-Learning-Cycles sind kein theoretisches Konstrukt, sie sind tatsächlich aus der Notwendigkeit entstanden, trotz vollem Terminkalender Zeit zum Lernen zu finden.
Neben der Vermittlung und Anwendung von MLC zeigt die Referentin auch aus der Praxis, wo sie MLCs einsetzte, was funktionierte und wo auch Limitierungen sind.
Ihr Motto „You go first! – Nimm dein Leben in die Hand!", steht für ihr Tun: Rein in den nachhaltigen Erfolg durch Eigenverantwortung und Selbstführung.
Anne Hoffmann unterstützt Menschen und Organisationen dabei, erfolgreich ihre Ziele zu erreichen. Als Expertin für Selbstführung und mit ihrem Motto „You go first!“ erinnert sie daran, dass nachhaltiger Erfolg durch hohe Eigenverantwortung insbesondere dann entsteht, wenn diese Selbstführung vorgelebt wird.
Anne benutzt oft Spiele, um Erkenntnisse weiterzugeben.
Es ist eine weitverbreitete Erfahrung, dass nur wenige Wege zu einer erfolgreichen Software-Architektur / zu einem erfolgreichen Projekt führen, aber viele Wege zu Problemfällen. Von welchen Ingredienzen hängt aber deren (Miss-)Erfolg ab?
Speziell gefragt: Welche Mittel haben Software-Architekten & -Entwickler in der Hand, um eine erfolgreiche Lösung zu erstellen? Und woran lässt sich erkennen, dass etwas gehörig schiefläuft?
Zielpublikum: Software-Entwickler:innen, Software-Architekt:innen
Voraussetzungen: Erfahrung mit Software-Architektur und Software-Engineering
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Es ist eine weitverbreitete Erfahrung, dass nur wenige Wege zu einer erfolgreichen Software-Architektur / zu einem erfolgreichen Projekt führen, aber viele Wege zu Problemfällen. Wichtig ist insbesondere, von Anfang an die richtigen Weichen zu stellen und möglichst frühzeitig zu erkennen, ob etwas faul ist im Staate Dänemark. Software-Architekten sind dem aber nicht hilflos ausgeliefert, sondern haben im Gegenteil die Möglichkeit, die Entwicklung maßgeblich zu einem Erfolg zu führen.
Von welchen Ingredienzen hängt aber deren (Miss-)Erfolg ab? Speziell gefragt: Welche Mittel haben Software-Architekten & -Entwickler in der Hand, um eine erfolgreiche Lösung zu erstellen? Woran lässt sich erkennen, dass etwas gehörig schiefläuft? Welche Eingangsvoraussetzungen müssen gegeben sein?
Prof. Dr. Michael Stal arbeitet in der Technology-Organisation der Siemens AG, wo er sich mit Software-Architekturen, Geschäftsmodellen und KI beschäftigt. Er ist Professor an der University of Groningen und Chefredakteur von JavaSPEKTRUM.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.stal
Vortrag Teilen
Fast 20 Jahre nach dem Start von Domain-driven Design (DDD) ist der Ansatz weit verbreitet - aber das ist noch keine Garantie dafür, dass DDD-Projekte auch erfolgreich beendet werden.
Dieser Vortrag zeigt typische Fehler, Missverständnisse und Probleme, die bei Domain-driven Design und insbesondere bei Strategic Design auftreten. Natürlich diskutiert die Präsentation auch, wie man solche Probleme sinnvoll lösen kann, um vielleicht nicht nur ein Scheitern zu verhindern, sondern sogar einen echten Erfolg zu landen ...
Zielpublikum: an Software-Architektur Interessierte
Voraussetzungen: Grundlegendes Verständnis von Software-Architektur
Schwierigkeitsgrad: Anfänger
Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff
Bei der Erstellung von Software werden großartige Technologien, Programmiersprachen und Werkzeuge eingesetzt. Aber leider wird oft aus den Augen verloren, dass der entscheidende Faktor nicht die Technologie, sondern die Domäne ist.
In diesem Vortrag zeige ich euch, wie ihr die Domäne in eurer vorhandenen Software wiederentdecken und als wichtiges Mittel der Architekturverbesserung einsetzen könnt.
Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Projektleiter:innen, Requirement Engineers
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Bei der Erstellung von Software werden großartige Technologien, Programmiersprachen und Werkzeuge eingesetzt. Das ist gut und richtig. Aber leider wird oft aus den Augen verloren, dass der entscheidende Faktor nicht die Technologie, sondern die Domäne ist. Wenn wir die Fachsprache und die Geschäftsprozesse nicht in der Software abbilden, dann hilft sie unseren Anwender:innen nicht bei ihrer Arbeit. Keine Technologie der Welt kann uns davor schützen.
In diesem Vortrag zeige ich euch, wie ihr Probleme in eurer vorhandenen Software mit Domain-Driven Design angehen könnt.
Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS - Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Seit 1998 entwickelt sie qualitativ hochwertige Softwaresysteme mit ihren Teams. Carola hält regelmäßig Vorträge auf Konferenzen, schreibt Artikel und hat ein Buch zum Thema „Langlebige Software-Architekturen“ veröffentlicht.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal
Vortrag Teilen
Vortrag Teilen
Measuring quality requires many questions to be answered. The most obvious ones may be: “What is quality?”, but also “How can we measure it?”, “Which metrics are most accurate?”, “Which are most practical?”.
In this talk, I share some general motivations for measuring quality. I review commonly used metrics that claim to measure quality, I rate them with regards to how they may be helpful or harmful to achieve actual goals. I give some examples how the weaknesses of one metric might be countered by another one to create a beneficial system.
Target Audience: Developers, Project Leader, Manager, Decision Makers, Quality Engineers, Testers, Product Owners
Prerequisites: Basic Software Project Experience, Rough Understanding of Software Development
Level: Advanced
Extended Abstract:
Measuring quality requires many questions to be answered. The most obvious ones may be: “What is quality?”, but also “How can we measure it?”, “Which metrics are most accurate?”, “Which are most practical?”.
In my experience, one question is often not answered or postponed until it is too late: “Why do we want to measure quality?” Is it because we want to control how well our developers are performing? Is it to detect problems early? Is it to measure the impact of changes? Is it the product or the process we care about? Is it to improve locally in a single team or globally across the company? Is there a specific problem that we are trying to solve, and if so, which one?
Instead of trying to define what software quality is – which is hard and depends on a lot of factors – we should first focus on the impact of our measuring. Some metrics may work great for one team, but not for the company as a whole. Some will help to reach your team or organizational goal, some will not help at all, and some will even have terrible side effects by setting unintended incentives. Some can be gamed, others might be harmful to motivation. Consider an overemphasis on lead time, which can lead to cutting corners. Or measuring the number of bugs found, which can cause a testers versus developers situation.
In this talk, I share some general motivations for measuring quality. I review various commonly used metrics that claim to measure quality. Based on my experience, I rate them with regards to how they may be helpful or harmful to achieve actual goals and which side effects are to be expected. I give some examples how the weaknesses of one metric might be countered by another one to create a beneficial system.
Michael Kutz has been working in professional software development for more than 10 years now. He loves to write working software, and he hates fixing bugs. Hence, he developed a strong focus on test automation, continuous delivery/deployment and agile principles.
Since 2014 he works at REWE digital as a software engineer and internal coach for QA and testing. As such his main objective is to support the development teams in QA and test automation to empower them to write awesome bug-free software fast.
UI testing is an essential part of software development. But the automation of UI tests is still considered too complex and flaky.
This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. It will be shown which kind of representations are used by today's test tools and how the addressing of elements in the UI is done.
In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented.
Target Audience: Developers, Testers
Prerequisites: Basic Knowledge of UI-Testing
Level: Advanced
Extended Abstract:
UI testing is an essential part of software development. Despite technological progress, the automation of UI tests is still considered too complex to function completely without manual intervention.
In addition to classical selector-based approaches, more and more image-based methods are being pursued.
This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. In particular, current problems and future developments will be discussed. Furthermore, it will be shown which kind of UI representations are used by today's test tools and how the addressing of elements in the user interface is done.
In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented on the basis of current research.
Johannes Dienst is Developer Advocate at askui. His focus is on automation, documentation, and software quality.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Johannes.Dienst
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
Zero Trust Architecture has become the norm for how to modernize IT security in an age of growing network complexity and fewer ways to define hard network boundaries. Today, APIs are a standard way of how organizations expose both technical and business capabilities. But what does it mean for an API to be "Zero Trust Ready"?
In this presentation we look at some of the general patterns that APIs need to follow for Zero Trust readiness. We also look at some concrete practices for how to follow those patterns in your own APIs and API landscape.
Target Audience: Architects, Developers, API Designers, API Program/Platform Managers, Security Leads
Prerequisites: Basic knowledge of API terminology
Level: Advanced
Liad is a technologist that specialises in digital transformation and innovations.
For years he has been guiding and assisting organisations through their digital transformation journey. Enabling them to make the necessary changes needed when integrating digital technology into all areas of the business, with the goal of driving operational efficiency and value to customers, whilst supporting them through the technological and cultural changes.
With a strong background in networking and cybersecurity, having worked with service providers, Content Delivery Network (CDN) companies and top security vendors.
He has been helping companies, mostly technology startups and FinTechs, to understand the value of their digital assets and then pivot towards a strategy that will best allow them to innovate whilst maintaining security and control over their data. Liad is Vice President Pre-Sales Consulting at Axway.
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
Erklärbare KI (Explainable AI, kurz XAI) ermöglicht es, automatisiert situations- und zielgruppenspezifische Begründungen für die Empfehlungen, Prognosen und Entscheidungen von KI-Systemen zu erzeugen.
Hierdurch lassen sich nicht nur Nachvollziehbarkeit und Akzeptanz automatisierter Entscheidungen bei Endanwender:innen steigern, sondern auch Reaktions- und Handlungsmöglichkeiten aufzeigen. Anhand praxisnaher Beispiele demonstrieren wir, wie die Methodenvielfalt Erklärbarer KI für das UX-Design genutzt werden kann.
Zielpublikum: Produktdesigner, UX-Designer, Projektverantwortliche, Datenwissenschaftler, Entscheidungsträger
Voraussetzungen: Grundkenntnisse im UI/UX-Design
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Methoden der Erklärbaren KI (Explainable AI, kurz XAI) werden vor allem zur Analyse und Kontrolle von komplexen KI-Systemen eingesetzt. So nutzen Data Scientists Ansätze wie Partial Dependence Plots oder SHAP, um zu ergründen, welchem Teil der Eingabedaten ein Machine-Learning-Modell besondere Bedeutung zugemessen hat.
Doch Erklärbare KI lässt sich auch zur Gestaltung der User Experience für Endanwender:innen nutzen. “Warum erhalte ich ausgerechnet diese Empfehlung?” “Woran wurde bei dieser E-Mail ein Phishing-Verdacht erkannt?” “Warum ist der prognostizierte Verkaufspreis meiner Immobilie so niedrig?” Fragen dieser Art stellen sich häufig, wenn Nutzer:innen mit Anwendungen und Prozessen in Kontakt kommen, bei denen im Hintergrund ein KI-System am Werk ist, das auch für seine Entwickler:innen eine “Black Box” darstellt.
Erklärbare KI ermöglicht es, automatisiert situations- und zielgruppenspezifische Begründungen für KI-Entscheidungen zu erzeugen. Hierdurch lassen sich nicht nur Nachvollziehbarkeit und Akzeptanz automatisierter Entscheidungen steigern, sondern auch Reaktions- und Handlungsmöglichkeiten aufzeigen.
Neben einer allgemeinen Einführung in das Thema “User-Centric Explainable AI” demonstrieren wir anhand von praxisnahen Beispielen, wie die mittlerweile verfügbare Methodenvielfalt Erklärbarer KI ausgeschöpft und zur Gestaltung der Interaktion von Endanwender:innen genutzt werden kann.
Kilian Kluge arbeitet als Co-Gründer von Inlinity daran, mit Explainable AI Anwendungsbereiche für KI-Systeme zu erschließen, in denen bislang regulatorische oder unternehmerische Risiken einem Einsatz entgegenstehen. Zuvor war er mehrere Jahre als IT-Berater und Entwickler in der deutschen Finanzbranche tätig und hat an der Universität Ulm zu nutzerzentrierter KI promoviert.
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
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.
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
API Expand Contract ist ein Pattern zur Weiterentwicklung von APIs. Aber was verbirgt sich hinter der Idee? Wie kann ich damit eine API weiterentwickeln, ohne dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Kenntnisse in der API-Entwicklung, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Der Thoughtworks-Technologie-Radar empfiehlt, das Pattern „Expand-Contract“ auf APIs anzuwenden.
Aber was verbirgt sich hinter der Idee?
Und wie kann ich das in der Praxis realisieren?
Wie kann ich sicherstellen, dass trotz Weiterentwicklung alle meine Clients weiterhin funktionieren und dennoch APIs unabhängig vom Server aktualisiert werden können - und das Ganze am besten ohne, dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?
Welche Versionierungsstrategie sollte ich in welcher Situation fahren und wie implementiere ich die verschiedenen Strategien geschickt?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.
Arne Limburg ist Lead Architect bei der open knowledge GmbH in Oldenburg. Er verfügt über mehrjährige Erfahrung als Entwickler, Architekt und Trainer im Enterprise- und Microservices-Umfeld. Zu diesen Bereichen spricht er regelmäßig auf Konferenzen und führt Workshops durch. Darüber hinaus ist er im Open-Source-Bereich tätig, unter anderem als PMC Member von Apache Meecrowave, Apache OpenWebBeans und Apache DeltaSpike und als Urheber und Projektleiter von JPA Security.
Microservices sind der Hammer, aber nicht alles ist ein Nagel. Trotzdem ist man leicht in der Versuchung, immer diesen Hammer auszupacken, wenn man eine gut modularisierte Software-Architektur zimmern will. Genau das hatten wir mit unserem System auch vor. Wir erzählen euch die Geschichte, warum wir unsere erste Entscheidung revidiert und mit modularen Monolithen ein passenderes Architektur-Werkzeug für uns gefunden haben.
Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlagen zu Architektur- und Designpatterns
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Woran lässt sich erkennen, ob das jeweilige Architekturproblem in die Kategorie „Nagel“ fällt oder nicht? Das kommt auf die Rahmenbedingungen an: Hat man die Domain schon so gut verstanden, dass die Modellgrenzen oder „Bounded Contexts“ klar sind? Ist es wichtig, einzelne Bausteine unabhängig ausrollen zu können? Wenn nicht, können Modulare Monolithe anstelle von Microservices zwei Vorteile bringen: Erstens verbinden sie ein einfaches Deployment mit einer fachlichen Modularisierung. Damit gewinnt man die Flexibilität, den Code einfach umzubauen. Zweitens spart man sich den Verwaltungs-Overhead von Microservices, ohne dabei den Weg zu einer stärkeren Trennung zu verbauen.
Das klingt attraktiv, aber der Teufel steckt im Detail. Wie stellt man sicher, dass die einzelnen Module getrennt bleiben und kein „Big Ball of Mud“ entsteht? Wie kann man auf der anderen Seite eine Kommunikation zwischen den Modulen erlauben, um fachliche Abhängigkeiten abzubilden?
Wir zeigen euch an unserem System, wie wir die Trennung der fachlichen Module, aber auch die Kommunikation zwischen ihnen umgesetzt haben, auf welche Probleme wir gestoßen sind, welche Lösungen wir gefunden haben und welche Kompromisse wir eingegangen sind.
Damit möchten wir euch einen Eindruck vermitteln, welche Herausforderungen wir mit dem Werkzeug „Modularer Monolith“ meistern konnten, damit ihr es ebenfalls in euren Architektur-Werkzeugkoffer aufnehmen könnt.
André Kappes ist seit 2015 Software Craftsman aus Leidenschaft. Auf seiner Suche, wie man handwerklich gute Software entwickelt, sammelt er immer wieder neue Erkenntnisse rund um Clean Code und Test-driven development, um Software-Architektur, Domain-Driven Design und Continuous Delivery. Zu seinem Glück hat er in jedem seiner bisherigen Projekte zuhauf spannende Fragen gefunden und neue Einsichten bekommen. Er begleitet derzeit ein internes Ausbildungsprojekt als technischer Coach.
Vortrag Teilen
Vortrag Teilen
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.
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.
Vortrag Teilen
Integration war und ist immer noch relevant - vielleicht mehr denn je. Insbesondere, wenn wir über Anwendungsmodernisierung sprechen. In Zeiten von Cloud- und Microservice-Architekturen müssen wir neu darüber nachdenken, wie wir Integrationsherausforderungen bewältigen können. Klassische ESB-Lösungen sind meist veraltet - was aber ist die Alternative?
Anhand der Erfahrungswerte aus unserem eigenen IT-Modernisierungsprojektes, werde ich vorstellen, wie Integrationsherausforderungen heute mit Hilfe moderner Technologien adressiert werden können.
Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Cloud, Integration, API, Events
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Integration ist ein wichtiges Thema. In jedem Modernisierungsprojekt existieren entsprechende Herausforderungen, die nach einer entsprechenden Integrationsstrategie verlangen.
In der Regel starten wir ja nicht auf der grünen Wiese, sondern müssen die alte und neue Welt zusammenbringen. Auch ein Monolith kann nicht im Rahmen eines Big Bang Ansatzes einfach mal eben so abgelöst werden.
Im Kontext des Vortrages werde ich von unserem eigenen IT Modernisierungsprojekt berichten, im Kontext dessen wir einen über 30 Jahre gewachsenen Oracle Forms Monolithen in einem inkrementellen Vorgehen ablösen und durch SaaS-Lösungen ersetzen wollen. Die Integration zwischen alter und neuer Welt erfolgt basierend auf modernen Technologiekonzepten wie Containern, API Gateway, Service Mesh und Event Hub mit Kubernetes als zentrale Runtime Plattform.
Dies ermöglicht uns perspektivisch mehr Flexibilität und Agilität sowie eine Steigerung der Developer Productivity durch die Verwendung entsprechender Konzepte und Technologien sowie eine hochgradige Automatisierung im Kontext der Applikationsbereitstellung.
Sven Bernhardt arbeitet für OPITZ CONSULTING als Chief Architect im Corporate Development Team. In seiner Rolle ist er für das Management des Technologieportfolios und die Entwicklung von Best Practices und Guidelines verantwortlich. Darüber hinaus unterstützt Sven seine Kollegen bei der Implementierung von Softwarelösungen in Kundenprojekten.
Er spricht regelmäßig auf Konferenzen über Technologie- und Architekturthemen und teilt seine Gedanken und Erfahrungen in Artikeln und Blogbeiträgen.
Bücher:
2017 | Dynamikrobuste Architekturen der Digitalisierung: Architecting for the Digital World!
2015 | Design Principles for Process-driven Architectures Using Oracle BPM and SOA Suite 12c
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/sven.bernhardt
Die Welt der operativen, transaktionalen Systeme und der analytischen Systeme ist seit jeher getrennt. Unterschiedliche SW-Entwicklungsparadigmen, andere Technologien, andere Datenmodelle, usw. prägen die jeweiligen Systeme. Statt Silos zu bauen, geht es darum, eine Balance zu finden zwischen Dev und Data: DevDataOps? Wie können Data Mesh und Data Lakehouse dazu beitragen?
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Die Welt der operativen, transaktionalen Systeme und der analytischen Systeme ist seit jeher getrennt. Unterschiedliche SW-Entwicklungsparadigmen, andere Technologien, andere Datenmodelle, usw. prägen die jeweiligen Systeme. Statt Silos zu bauen, geht es darum, eine Balance zu finden zwischen Dev und Data: DevDataOps? Wie können Data Mesh und Data Lakehouse dazu beitragen?
Data Mesh ist ein Ansatz, der mit Prinzipien wie domänengetriebener Entwicklung, Produktorientierung oder Self-Service Infrastruktur die Welten verschmelzen möchte. Beim Data Lakehouse stehen dagegen technische Eigenschaften im Mittelpunkt der Veränderungen gegenüber gängigen Architekturen. DevDataOps wird von beiden Architekturen unterstützt – die Gewichtung ist jedoch grundverschieden. Auch die Anforderungen an die Umsetzung sind unterschiedlich: Data Mesh führt beispielsweise organisatorische Änderungen nach sich. Im Vortrag werden solche Fragestellungen anhand praktischer Erfahrungen vertieft.
Andreas Buckenhofer arbeitet als Lead Expert "Vehicle Data Platforms" bei Mercedes-Benz Tech Innovation. Daten sind schon immer seine Leidenschaft. Er verfügt über langjährige Erfahrung in der Entwicklung datenintensiver Produkte. Sein Wissen gibt er gerne in internen Vorträgen weiter oder als Sprecher auf Konferenzen. An der DHBW hält er seit vielen Jahren eine Vorlesung über Data Warehousing und Data Management.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/andreas.buckenhofer
Vortrag Teilen
Vortrag Teilen
With GraphQL a modern and flexible way of providing APIs for our data is emerging.
The clients specify which data they need, the provisioning of data becomes more flexible and dynamic. Over-fetching or under-fetching are history.
But does this mean we have to rewrite all APIs to benefit? How can we retrofit a GraphQL API onto our existing API landscape?
We will explore three different approaches.
Target Audience: Architects, Developers
Prerequisites: Basic knowledge in API design and Java
Level: Advanced
Extended Abstract:
In this talk we explore three different alternatives:
- The Developer Way: Writing a GraphQL API layer by hand
- The Cloud-native Way: Using lightweight API gateways such as Gloo or Tyk
- The Serverless Way: Using Cloud Provider native services
We will look at all three approaches conceptually and justify when and why each makes sense. Additionally, we will show in a live demo how GraphQL APIs can be added to an existing REST API.
Sonja Wegner is Lead Software Architect at QAware. Her current focus is on design and implementation of complex systems and software architectures.
Stefan Schmöller is Senior Software Engineer at QAware. He is mainly interested in Java frameworks and microservice architectures.
Vortrag Teilen
Irgendwann trifft es mal jeden. Anwendungen veralten automatisch, egal, ob ein oder zehn Jahre alt, ob sie "fertig" entwickelt sind oder nicht. Die Gründe sind vielschichtig: Die Programmiersprache entwickelt sich weiter, Bibliotheken brauchen ein Update, Good Practices entwickeln sich weiter. Diese Wartungsarbeiten werden nicht gerne gemacht, da sie scheinbar unnötige Aufwände erzeugen und zum Teil recht stupide sind. Ignoriert die Entwicklerin sie, dann sammelt sie automatisch technische Schulden und die Aufwände sind in der Zukunft höher.
Zielpublikum: Entwickler:innen, Architekt:innen, Entscheider
Voraussetzungen: Allgemeine Entwicklungskenntnisse
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Irgendwann trifft es mal jeden. Anwendungen veralten automatisch, egal, ob ein oder zehn Jahre alt, ob sie "fertig" entwickelt sind oder nicht. Die Gründe sind vielschichtig: Die Programmiersprache entwickelt sich weiter, Bibliotheken brauchen ein Update, Good Practices entwickeln sich weiter. Diese Wartungsarbeiten werden nicht gerne gemacht, da sie scheinbar unnötige Aufwände erzeugen und zum Teil recht stupide sind. Ignoriert die Entwicklerin sie, dann sammelt sie automatisch technische Schulden und die Aufwände sind in der Zukunft höher und bei Sicherheitslücken schmerzhafter.
Dieser Vortrag zeigt, was alles unter Wartungsarbeiten zu verstehen ist und in welche Probleme Unternehmen laufen können, wenn sie es unterlassen. Außerdem stellt es Vorgehensweise und Werkzeuge vor, die bei Wartungsarbeiten helfen können und somit zumindest den stupiden Teil reduzieren.
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
- The race for performance and the variety of specialized workloads drives the industry to build more parallel, more heterogenous (multi accelerator), and distributed computing systems.
- These systems introduce programming challenges and barriers of entry to developers.
- Software solutions can make technologies like AI accessible, safer and easier to use by wider communities.
- We will present some of the driving forces, world trends, challenges, and emerging solutions such as oneAPI, AI reference Kits, federated learning and more and demonstrate how SW can be made simpler, safer, and more profitable.
Guy Tamir is a technology evangelist at Intel Software and Advanced Technology group. His main areas of interest and expertise are Artificial Intelligence, Computer vision, Video processing, and Heterogeneous, multi-accelerator parallel computing. In addition, Guy is an active YouTuber with the OpenVINO and oneAPI video channel that just passed 3 million viewers recently. Guy holds an M.Sc. (EE, Technion) and MBA (Open University). Channel link: https://youtube.com/playlist?list=PLg-UKERBljNxsCltpcXU_Haz9xQSCN_SB
Walter Riviera is AI Technical Specialist EMEA Lead at Intel.
Walter joined Intel in 2017 as an AI TSS (Technical Solution Specialist) covering EMEA and he’s now playing an active role on most of the AI project engagements within the Data Centers business in Europe. He is responsible for increasing Technical and business awareness regarding the Intel AI Offer, enabling and provide technical support to end user customers, ISVs, OEMs, Partners in implementing HPC and/or Clouds solutions for AI based on Intel’s products and technologies. Before joining Intel Walter has collected research experiences working on adopting ML techniques to enhance images retrieval algorithms for robotic applications, conducting sensitive data analysis in a start-up environment and developing software for Text To Speech applications.
Carsten Schuckmann is part of Accenture’s Cloud First Applied Intelligence group, who strives to help Accenture clients implement transformative cloud-first offerings, leading with a focus on technical innovations and TCO optimization. Carsten’s key focus is to enable growth across EMEA clients in cloud adoption and AI innovation through thought leadership.
Carsten works closely with Intel and other key ecosystems partners and providers to bring optimization solutions and technology recommendations to Accenture’s clients across various industries.
Vortrag Teilen
Wir entwickeln heute Software nicht mehr auf der grünen Wiese, sondern wir erweitern und verändern vorhandene Systeme. Dabei wird der Code immer komplexer und sammelt technische Schulden an. Im Entwicklungsteam ist uns das allen klar, aber wie erklären wir dem Management, dass es sinnvoll ist, frühzeitig technische Schulden abzubauen?
In diesem Vortrag berichte ich von meiner Erfahrung aus verschiedensten Kontexten und gebe Empfehlungen, wie die Kommunikationsbarriere zwischen Management und Entwicklungsteams übersprungen werden kann.
Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Projektleiter:innen, IT-Management
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger
Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS - Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Seit 1998 entwickelt sie qualitativ hochwertige Softwaresysteme mit ihren Teams. Carola hält regelmäßig Vorträge auf Konferenzen, schreibt Artikel und hat ein Buch zum Thema „Langlebige Software-Architekturen“ veröffentlicht.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal
Vortrag Teilen
Requirements engineering like testing require balance of value and risk. Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent.
This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study demonstrates an industry use of TDRE.
Target Audience: Project Managers, Architects, Analysts, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: None
Level: Advanced
Extended Abstract:
Requirements engineering like testing require balance. Balance is about balancing value and risk. Requirements must be good enough to mitigate risks but yet not overly specific to contain effort. Same for test, which though never complete needs to address those areas with highest risk.
Requirements engineering and testing belong together. Historically, testers have often only seen the requirements after the system has already been partially implemented. This had two serious disadvantages. On the one hand, insufficient requirements quality came far too late to the table. On the other hand, it was quite a lot of extra work without deriving suitable test cases in the context of requirements definition. A lot of additional work and long correction loops were the result.
Only an agile balance of risk-oriented coverage and testable requirements can improve test effectiveness. Such risk-oriented work also optimizes requirements engineering. Instead of paralysis by analysis in defining numerous requirements, test-driven requirements engineering (TDRE) focusses on specifying what is necessary and of high risk or high value.
TDRE is straight-forward: Test cases are developed in parallel to the requirements. Thus, the feasibility of the requirements is analyzed much faster than in the traditional sequential approach, in which tests are specified relatively late. The test cases are initially described in the same structure as the requirements and as a supplement to the respective requirements. This shifts Test-Driven Development (TDD), which has already proven itself as relevant agile methodology, to the specification level. Regression tests are attributed in order to prepare for later automation. The effort required for testing can be better estimated on this basis, and project and quality risks are thus reduced.
TDRE follows a triple peak model, which is connecting requirements (i.e., needs), design (i.e., solution) and test (i.e., the product).
It intertwines three perspectives:
• Market perspective: “How can I meet customer satisfaction and needs?”
• Design perspective: “How can I implement the solution to meet requirements?”
• Testing perspective: “How can I find a defect and cause the product to fail?”
Here some guidance from our projects, which we will further illustrate in this presentation:
• Every single functional requirement has at least one acceptance check, which is either fulfilled or not fulfilled and serves as the agile DoD (definition of done).
• Each individual quality requirement is described with numerical values that can be measured.
• Business rules are defined so that it can be determined whether they are true or false.
• Business and data objects are defined with all their attributes, types and states so that they can be set and validated at test time.
• System interfaces such as GUIs, reports and service interfaces are included in the requirements document so that values can be assigned to them.
• All use cases have pre- and post-conditions that can be generated and validated.
• All text is marked so that it can be automatically processed to generate test cases.
Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent. This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study from medical cybersecurity demonstrates an industry use of TDRE.
Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world in agile transformations. Before he had been working for ten years in global senior management positions. A trusted advisor and a member of several of industry boards, he is a professor at the University of Stuttgart and at Sorbonne in Paris. He authored several books including "Requirements Engineering" published by dPunkt and in China by Motor Press. He is serving on the editorial Boards of "IEEE Software" and "Journal of Systems and Software (JSS)".
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/christof.ebert
Daten endlich sinnvoll nutzen! Data Mesh befähigt Entwicklungsteams, innerhalb ihrer Domäne Datenanalysen selbstständig durchzuführen, um ihre Services selbstständig verbessern zu können. Über definierte Schnittstellen werden qualitativ hochwertige analytische Daten als Produkte auch anderen Teams zur Verfügung gestellt.
Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Daten endlich sinnvoll nutzen! Data Mesh befähigt Entwicklungsteams, innerhalb ihrer Domäne Datenanalysen selbstständig durchzuführen, um ihre Services selbstständig verbessern zu können. Über definierte Schnittstellen werden qualitativ hochwertige analytische Daten als Produkte auch anderen Teams zur Verfügung gestellt.
Data Mesh überträgt die Prinzipien aus DDD, Team Topologies und Microservices auf die Datenwelt. Es hat aber auch weitreichende soziotechnische Auswirkungen, und lassen sich die zusätzlichen Aufgaben überhaupt mit dem Projektalltag vereinbaren?
In diesem Talk beschreibt Jochen Christ von INNOQ, wie eine Data Mesh-Architektur in der Praxis umgesetzt werden kann, welche organisatorischen Transformationen notwendig werden und welche Technologien sich dabei eignen.
Jochen Christ ist Tech Lead bei INNOQ und ist Spezialist für Self-Contained Systems und Data Mesh. Jochen ist (Co-)Autor von datamesh-architecture.com, http-feeds.org, whichjdk.com und remotemobprogramming.org.
Vortrag Teilen
As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions. In this talk I will highlight some of the many ways that testing can help you to develop better software faster.
Target Audience: Developers
Prerequisites: Basic knowledge in Java
Level: Advanced
Extended Abstract:
Testing doesn't always get the attention it deserves in software development. Many developers claim to be bad at it, or are just not that interested. (These may or may not be related.)
As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions.
In this talk I will highlight some of the many ways that testing can help you to develop better software faster.
Marit van Dijk is a software developer with 20 years of experience in different roles and companies. She loves building awesome software with amazing people and has contributed to open source projects like Cucumber and various other projects. She enjoys learning new things, as well as sharing knowledge on programming, test automation, Cucumber/BDD and software engineering. She speaks at international conferences, webinars and podcasts, occasionally writes blog posts and contributed to the book "97 Things Every Java Programmer Should Know" (O’Reilly Media).
In this session I’ll examine some of the things that can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls.
I'll explain contract testing from the ground up. You'll learn how it can decouple micro-service dependencies during development, allowing your teams to work effectively. And I'll describe sophisticated, free, open-source tooling that helps integrate contract testing into your software lifecycle, giving you the confidence to release micro-services independently.
Target Audience: Architects, Developers, Decision Makers, Release Managers, DevOps
Prerequisites: English, basic software design/architecture, software lifecycle
Level: Advanced
Seb Rose has been a consultant, coach, designer, analyst and developer for over 40 years. He's now Developer Advocate with SmartBear Advantage, promoting better ways of working to the software development community.
Co-author of the BDD Books series "Discovery” and "Formulation" (Leanpub), lead author of “The Cucumber for Java Book” (Pragmatic Programmers), and contributing author to “97 Things Every Programmer Should Know” (O’Reilly).
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing-Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind?
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mithilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud-native-Anwendungen gerecht zu werden.
Ein Ausblick auf das Zusammenspiel mit GraalVM und Quarkus zeigt, dass Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.
Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Cloud Computing sowie ML/AI, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.
Webanwendungen ohne automatisiert getestete APIs machen im Betrieb und Weiterentwicklung schlechte Laune, egal, ob es um APIs zwischen Frontend und Backend, zwischen Microservices oder zu Drittparteien geht. Typischerweise beschreiben wir das erwünschte Verhalten der Anwendung, in dem wir uns selbst Beispiele als Testfälle ausdenken. Da geht mehr. In diesem Beitrag werfen wir einen Blick auf über "naive Integrationstests" hinausgehende Ansätze, von Contract Based bis hin zu KI-Unterstützung.
Zielpublikum: Entwickler:innen, Tester:innen
Voraussetzungen: Erfahrung in der Entwicklung und im automatisierten Testing von Webanwendungen
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Die Älteren unter uns werden sich noch an die Anfänge der Webentwicklung erinnern: Tester:innen klickten sich wieder und wieder durch umfangreiche Testpläne durch, die typischerweise nach dem Entwickeln erstellt wurden. Dieser Ansatz ist leider gerade in Konzernen immer noch nicht ausgestorben. Schlecht getestete Schnittstellen werden schnell zur Achillesferse gerade in modularen Architekturen und vor dem Wunsch, fertige Software schneller in die Produktion zu bringen. Consumer driven contract testing ist zumindest theoretisch mittlerweile in den Teams angekommen, neuere Ansätze wie Search based Software Testing oder Property based Testing sind dagegen noch exotisch.
Die Session will einen praxisorientierten Überblick über unbekanntere Verfahren geben.
Dorthe Luebbert ist in der IT seit der 5 1/4 Zoll Diskette dabei und interessiert sich für Webtechnologien und die Menschen, die diese bauen. Als Freelancerin in der IT schätzt sie den entspannten Feierabend dank guter Architektur, Softwarequalität und vernünftiger Prozesse.
Vortrag Teilen
Vortrag Teilen
Ursprünglich war agile Entwicklung und allen voran XP für Entwickler:innen gedacht. Inwiefern werden diese heutzutage noch von agilen Vorgehensweisen unterstützt? Diese Frage wird von Erik Dörnenburg mittels "25 Jahre XP: Die Balance zwischen neuen Technologien und bewährten Praktiken" und Ina Einemann durch "Take it Back" untersucht und in einem Panel mit Frank Buschmann diskutiert.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Software-Ingenieur:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Als Kent Beck vor fast 25 Jahren Extreme Programming (XP) beschrieb sah die IT-Industrie noch recht anders aus. Seitdem sind agile Ansätze und die Nutzung von Open Source Software Mainstream geworden, und die Public Cloud Anbieter haben sich und ihre Ökosysteme etabliert. Diese Trends haben unsere Fähigkeiten komplexe Software-Systeme zu entwickeln verbessert. Das eigentliche Handwerk – effektiv in einem Team beständig Software zu schreiben – ist aber genauso wichtig wie immer. In diesem Talk geht es um die Rolle, die XP für die moderne Software-Entwicklung spielt.
Das agile Manifest wurde vor über 20 Jahren von Entwicklern für Entwickler geschrieben. Mittlerweile fühlt es sich aber immer mehr an, als ob die agile Bubble eine eigene Welt ist, die von Scrum Mastern und Agile Coaches übernommen wurde. Developer nehmen eher passiv an den vorgeschriebenen Meetings teil, statt den Prozess aktiv zu gestalten.
Was läuft da schief? Und wie können wir das ändern?
In dieser Session geht es um Motivation, sinnvolle Konflikte und Empowerment.
Erik Dörnenburg ist Software-Engineer und leidenschaftlicher Technologe. Auf seiner inzwischen langen Reise durch die Tech-Branche ist Erik einer Fülle neuer Technologien begegnet. Dabei ist es ihm wichtig deren Potenzial zu bewerten und gleichzeitig bewährte Praktiken für die neuen Technologien zu adaptieren. Als Head of Technology bei Thoughtworks hilft er Kunden, ihre geschäftlichen Herausforderungen mit modernen Technologien, Plattformen und Praktiken zu lösen. Erik ist regelmäßiger Redner auf Konferenzen, hat an einigen Büchern mitgewirkt und unterhält mehrere Open Source Projekte. Er hat einen Abschluss in Informatik der Universität Dortmund und hat Computer Science und Linguistik am University College Dublin studiert.
Ina Einemann ist als Agile Coach bei der Open Knowledge GmbH in Oldenburg tätig. Ihr Tätigkeitsumfeld umfasst neben ihrer Arbeit als Scrum Master auch Aufgaben aus dem Bereich PO und Requirements Engineering. Sie beschäftigt sich mit agilen Methoden und Vorgehensmodellen und berät Teams bei der Umsetzung agiler Praktiken. Sie ist außerdem einer der Hosts des Podcast "Mein Scrum ist kaputt".
Frank Buschmann is a Senior Principal Engineer at Siemens Technology in Munich. His interests are in modern software architecture and development approaches for industrial digitization.
Vortrag Teilen
Qualitätsziele helfen uns, Architekturentscheidungen fundierter zu treffen. Die genau richtige Qualität ist jedoch oft subjektiv und ändert sich über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem bei langlebigen Softwaresystemen spannend.
In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, bei der wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich das ISO 25010-Qualitätsmodell sowie Wardley Mapping, um die passende Qualität nach Wichtigkeit und Evolutionsstufen zu finden.
Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Die Balance der passenden Qualitätszielen ist ein herausforderndes Thema. Qualitätsziele sind aber sehr wichtig in der Entwicklung passender Softwaresysteme. Sie helfen uns, Architekturentscheidungen fundierter zu treffen. Die „genau richtige Qualität“ hängt dabei stark vom Betrachtungspunkt verschiedener Stakeholder ab. Zudem ändern sich Ansprüche an die Qualitäten eines Softwaresystems über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem in langlebigen Softwaresystemen immer wieder spannend.
In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, wo wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich hierzu das ISO 25010-Qualitätsmodell sowie Wardley Mapping. Damit lassen sich notwendige Qualitäten nach ihrer Wichtigkeit und Evolutionsstufen von Softwaresystemen kommunizieren. Der Vortrag verzahnt die evolutionäre Sicht auf Softwarequalität mit Beispielen aus der Praxis und zeigt, wie sich damit die richtige Balance zwischen zu viel und zu wenig Qualität gestalten lässt.
Markus Harrer arbeitet seit mehreren Jahren in der Softwareentwicklung und ist vor allem in konservativen Branchen tätig. Als Senior Consultant hilft er, Software nachhaltig und wirtschaftlich sinnvoll zu entwickeln und zu verbessern. Er ist aktiver Mitgestalter in Communities zu den Themen Software Analytics, Softwarearchitektur, Softwaresanierung und Java. Zudem ist er akkreditierter Trainer für den iSAQB Foundation Level und dem Advanced-Level-Modul IMPROVE.
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort. Wirklich? Warum haben wir dann Schwierigkeiten, POs/Projektleiter/Abteilungsleiter vom notwendigen Budget zu überzeugen?
Im Vortrag zeigen wir, wie es datenbasiert besser geht. Wie man für Technische Schulden KPIs erfasst und wie man jeweils Code-, Architektur-, Test-Qualität, Team-Kollaboration mit den KPIs korreliert, um eine Kosten-Nutzen-Analyse durchzuführen. Trotz Microservices und DevOps - die Herausforderungen bleiben.
Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort, “es geht um Smells, Bugs, Bedarf an Refactoring, fehlende Tests …”. Zum Teil können wir deren Umfang und Bedarf sogar messen. Aber wie entscheiden wir, was wir zuerst angehen sollen? Wie und was messen wir, sodass andere Stakeholder uns überhaupt verstehen und wir POs, Projektleiter und Abteilungsleiter vom notwendigen Budget überzeugen können?
Im Vortrag zeigen wir, wie man datenbasiert bessere Antworten findet. Was man mit den Folgen der Technischen Schulden anfängt, Wartungs- und sich verstärkende Mehraufwände in der Entwicklung als KPIs erfasst und deren Hotspots im Code identifiziert. Wie man jeweils Code-, Architektur- und Test-Qualität usw. als Ursachen identifiziert und mit den KPIs korreliert. Und wie man Technische Schulden in der Architektur in Zahlen prognostiziert, um eine Kosten-Nutzen-Analyse durchführen zu können. Und wie sich Team-Kollaboration auch auf Technische Schulden auswirkt.
Diese Herausforderungen sind seit mehreren Jahrzehnten die gleichen. Daran haben auch Microservices nichts geändert.
Die Teilnehmer erhalten Antworten auf folgende Fragen:
• Was sind Technische Schulden genauer?
• Wie misst man die Folgen?
• Wie sieht eine effektive Ursachenanalyse aus?
• Wie überzeuge ich andere Stakeholder von der Notwendigkeit?
• Wie wirkt sich Team-Kollaboration auf Technische Schulden aus?
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
APIs sind die Bindeglieder moderner Architekturen und nicht selten integriert ein System APIs im zweistelligen Bereich. Damit die API-Integration nicht zur Irrfahrt wird, unterstützen API-Guidelines die Developer Experience. Mit einem Blick auf öffentliche Guidelines und APIs gibt der Vortrag einen Eindruck von der allgemeinen Situation und liefert Impulse für das eigene API-Management. Da es in der Regel zu kurz gegriffen ist, einfach öffentliche API-Guidelines zu referenzieren, geben wir Tipps für eigene API-Guidelines und deren Etablierung.
Zielpublikum: Architekt:innen und Entwickler:innen
Voraussetzungen: Erfahrung oder Interesse am Design von Remote APIs
Schwierigkeitsgrad: Anfänger
Extended Abstract:
APIs sind die Bindeglieder unserer modernen, verteilten Systemarchitektur und nicht selten liegt die Anzahl der APIs im zweistelligen Bereich, wenn ein System integriert werden muss. Damit der Überblick gelingt und die API-Integration nicht zur Irrfahrt wird, unterstützen API Style Guidelines bei einer besseren Developer Experience und sind ein wichtiger Bestandteil der API Governance.
Mit einem Blick auf öffentlich zugängliche API-Guidelines und der Analyse öffentlicher APIs werden wir uns einen Eindruck von der allgemeinen Situation verschaffen und liefern Impulse für das eigene API-Management und -Design.
Hierüber wird auch schnell klar, warum es in der Regel zu kurz gegriffen ist, einfach eine öffentliche API-Guideline zu referenzieren. Deshalb werden wir auch Wege zur eigenen API-Design-Guideline aufzeigen und Tipps geben, die bei der Etablierung im Unternehmen helfen werden.
Benjamin Klatt ist Integrationsarchitekt und Agile Coach. Seine Schwerpunkte liegen in der Digitalisierung von Produkten und Prozessen, Integrationsarchitekturen sowie neuen Arbeitsweisen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/benjamin.klatt
Constanze Klaar ist IT-Beraterin mit Fokus auf der Entwicklung von Java-basierten Enterprise-Anwendungen. Seit vielen Jahren setzt sie sich mit dem Design guter APIs und API-Management auseinander.
Vortrag Teilen
Heutzutage führt kein Weg an Single-Page Applications vorbei. Ob React, Angular, VueJS oder eines der anderen Frameworks. Die Standardantwort auf die Frage nach der Frontend-Architektur heißt SPA. Doch was kaum jemand bemerkt:
Die SPA-Idee ist legacy! Mit AngularJS wurde vor 10 Jahren diese Idee bereits umgesetzt.
Ich möchte im Vortrag zeigen, aufgrund welcher Frontend-Probleme man ursprünglich SPAs entwickelt hat und ob es für diese Probleme nicht heutzutage innovativere Lösungen gibt: Hier kommt Hotwire ins Spiel!
Zielpublikum: Architekt:innen, Entwickler:innen, Frontend, Backend
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Hier kommt Hotwire ins Spiel, das mit einer sehr schlauen, auf low-level Standards setzenden Lösung ganz neue Möglichkeiten für saubere Architekturen schafft, ohne die UX-Vorteile einer SPA zu verlieren!
Ganz anders als SPAs lässt sich mit Hotwire eine lose Kopplung und geringe Abhängigkeiten zwischen verschiedenen Teams wahren und so Skalierungsfähigkeit erhalten.
Wenn ihr die Technologie kennenlernen und gleichzeitig ihren positiven Effekt auf Teams und Abhängigkeiten erfahren wollt, dann kommt gern vorbei!
Benedikt Stemmildt ist CTO von TalentFormation. Er ist leidenschaftlicher Software-Architekt, Full-Stack-Entwickler und Speaker mit Begeisterung für Technologie, Architektur und Organisation.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/benedikt.stemmildt
Vortrag Teilen
You know the story, one dev in the team found out about this amazing new framework which will solve potentially aaaall your problems; but the product owner stops him right away. There is definitely no time until the next roadmap milestone is reached and you’re already late. We have introduced the tool Tech Radar – in two different organisational setups – to make technology strategy explicit.
In this talk I’ll share our learnings on how we made sure our teams don’t drown in legacy, train them on time for new tech and foster exchange across teams.
Target Audience: Architects, Developers, Team Lead
Prerequisites: Everyone interested in technology strategy
Level: Basic
Marita Klein works as Senior Cloud Architect at Bosch Engineering. She has worked in different domains and roles during her professional career: Frontend and Backend developer, Architect as well as team lead of a group of software engineers. In all these stations she has experienced the importance of technical exchange between experts and how making problems explicit and talking about them is the first step of a solution.
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
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.
Vortrag Teilen
Mit React kam die Welt der Webentwicklung zum ersten Mal mit der funktionalen Programmierung in Kontakt und war verliebt. Doch das Versprechen simpler, nachvollziehbarer Programmlogik wird bei komplexeren Anwendungen oft nicht eingelöst. Das grundlegende Problem ist, dass wir unsere Programmstücke im Frontend zwar Komponenten nennen, uns aber die wichtigste Zutat aus der funktionalen Programmierung fehlt, um diese Benennung rechtfertigen zu können: Komposition. Dass es auch anders geht, zeigt dieser Vortrag.
Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Grundlegendes technisches Verständnis moderner Frontend-Frameworks wie React, Vue, Angular etc.
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Ein Jahrzehnt ist es mittlerweile her, dass React das Frontend revolutionierte. Die Welt der Webentwicklung kam zum ersten Mal mit der funktionalen Programmierung in Kontakt und war verliebt. Doch das Versprechen simpler, nachvollziehbarer Programmlogik wird bei komplexeren Anwendungen oft nicht eingelöst. Wir greifen wieder auf Hilfsmittel zurück, die wir eigentlich abschütteln wollten: Globaler Zustand, mutierbare Daten. Das grundlegende Problem ist, dass wir unsere Programmstücke im Frontend zwar Komponenten nennen, uns aber die wichtigste Zutat aus der funktionalen Programmierung fehlt, um diese Benennung rechtfertigen zu können: Komposition.
Dass es auch anders geht, zeigt dieser Vortrag. Wir führen ein in die Welt komponierbarer Komponenten. Das ist eine Welt ohne Redux und ohne Callbacks, aber dafür mit guter Testbarkeit, exzellenter Wiederverwendbarkeit und hervorragendem seelischem Wohlbefinden. Wir setzen damit die Versprechen der funktionalen Programmierung fort, insbesondere für sehr komplexe Anwendungen.
Markus Schlegel ist Software-Architekt bei der Active Group GmbH in Tübingen. Wir entwickeln Software ausschließlich mit funktionaler Programmierung. Markus interessiert sich neben der funktionalen Programmierung auch für GUI-Design, Nebenläufigkeit und Formale Methoden.
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
Software Development based on a distributed architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. These requirements can be covered by language frameworks or the underlying platform.
This talk will walk through a comparison of various approaches with focus on frameworks, Kubernetes and extending options like Service Meshes and eBPF. The talk will be lecture style with demo.
Target Audience: Developers, Architects, DevOps
Prerequisites: Introductory style, basic IT and dev skills probably helpful, but not required
Level: Basic
Extended Abstract:
Software Development based on a cloud-native (or distributed) architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. Initially software frameworks provided dedicated implementations for API Gateways, Service Registries, Circuit Breakers and many more. These functionalities are declared as code dependencies and need to be set at build time.
With Kubernetes there are alternative options to address these requirements. Kubernetes provides concepts for service discovery, load-balancing and resilience. So-called service meshes extend this functionality with more granular network interaction. They are not part of the application code and can hence be added during runtime. A fairly new approach is emerging with the eBPF technology, which claims to enable service meshes with minimal overhead.
With this talk Matthias wants to explain "the why" of cloud-native application design and how various cloud-native technologies facilitate this. It shows the possibilities and limitations of technologies and which forms of integration can make sense. The talk mostly consists of graphical visualisations/explanations and contains a live demo.
Matthias Haeussler ist Principal Cloud Advocate bei der NovaTec Consulting GmbH und der Veranstalter des Stuttgart Cloud Foundry Meetups. Er berät Kunden bei deren Cloud Strategie und unterstützt aktiv Implementierungen und Migrationen. Daneben unterrichtet er Cloud Native Development an den Hochschulen für Technik in Stuttgart und Esslingen. Davor war er über 15 Jahre bei der IBM R&D beschäftigt. Er hält regelmäßig Vorträge auf nationalen sowie internationalen Konferenzen und Meetups wie z.B. WJAX, OOP, den IT Tagen sowie der KubeCon, IBM InterConnect & Cloud Foundry Summit.
Vortrag Teilen
Micro Frontends sind in aller Munde. Und dennoch: Die Integration mehrerer Single-Page Applications zu einem großen Ganzen ist nach wie vor eine Herausforderung!
Wir vergleichen die verfügbaren Optionen samt deren Konsequenzen. Danach werfen wir einen Blick auf die nächste Generation von SPA-Frameworks, die hierbei viele der heutigen Nachteile gekonnt kompensieren.
Am Ende kennen Sie die Optionen für die Integration von Micro Frontends und können sie für Ihre Projekte bewerten.
Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlagenwissen zu JavaScript von Vorteil
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Zunächst diskutieren wir anhand von Beispielen verschiedene Spielarten von Web Components, das Bootstrapping mehrerer SPAs sowie das Laden von Teilen anderer Anwendungen, wie es z. B. Module Federation oder SystemJS erlauben.
Im zweiten Teil besprechen wir, wie die SPA-Frameworks der nächsten Generation Server-side Rendering und Client-side Rendering gekonnt kombinieren. Hierdurch lassen sich viele Nachteile heutiger Ansätze zur Integration von SPA-basierten Micro Frontends umgehen.
Stellvertretend für diese aufkommenden neuen SPA-Frameworks nutzen wir qwik aus der Feder des Angular-Vaters und Vordenkers Misko Hevery.
Manfred Steyer ist Trainer, Berater und programmierender Architekt mit Fokus auf Angular, Google Developer Expert (GDE) für Angular und Trusted Collaborator im Angular-Team. Er unterstützt Firmen im gesamten deutschen Sprachraum, schreibt für O'Reilly, Heise und das Java-Magazin, spricht regelmäßig auf Konferenzen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/manfred.steyer
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
Leider muss dieser Vortrag aus persönlichen Gründen kurzfristig abgesagt werden.
Das große Gefahrenpotenzial, das den meisten Webanwendungen inhärent ist, ist vielen Webentwickler:innen nicht bewusst. Per JavaScript hätte man z. B. auch Low Level Lücken wie Meltdown ausnutzen können.
Ohne entsprechende Sicherheits-Mechanismen von altbekannten wie der Same-Origin-Policy bis hin zu neuesten Entwicklungen wie Cross-Origin-Resource-/Cross-Origin-Embedder-Policy würde das garantiert im Security-GAU enden.
In dieser Nightschool lernen wir die verschiedensten Browser-Sicherheits-Mechanismen kennen und richtig zu nutzen.
Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Erfahrung in der Entwicklung und Architektur von Webanwendungen
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Diesen Mechanismen sind zwei Dinge gemein. Erstens müssen sie irgendwo implementiert werden. Das ist üblicherweise im Browser der Fall. Und zweitens können sie oft auf die ein oder andere Weise gesteuert werden. Von den Resource-Ownern und den Entwickler:innen.
Ohne ein Verständnis der aktuellen Sicherheitsmechanismen im Web ist eine Entwicklung von sicheren Webanwendungen praktisch nicht möglich. Gleichzeitig gibt es eine Vielzahl von Mechanismen, die sich teilweise überlappen oder gegenseitig beeinflussen, sodass es nicht einfach ist, hier den Überblick zu behalten.
In diesem Vortrag lernen wir in kleinen Demos die verschiedenen Mechanismen und die Möglichkeiten (z. B. über HTTP-Header), diese zu steuern, kennen. Und auch, ob und welche Bedeutung sie außerhalb des Browsers haben.
Christoph Iserlohn ist Senior Consultant bei INNOQ. Er hat langjährige Erfahrung mit der Entwicklung und Architektur von verteilten Systemen. Sein Hauptaugenmerk liegt dabei auf den Themen Skalierbarkeit, Verfügbarkeit und Sicherheit.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Christoph.Iserlohn
Vortrag Teilen