PROGRAMM

Die im Konferenzprogramm der SEACON digital 2021 angegebenen Uhrzeiten entsprechen der Central European Summer Time (CEST).

Per Klick auf "VORTRAG MERKEN" innerhalb der Vortragsbeschreibungen können Sie sich Ihren eigenen Zeitplan zusammenstellen. Sie können diesen über das Symbol in der rechten oberen Ecke jederzeit einsehen.

Gerne können Sie die Konferenzprogramm auch mit Ihren Kollegen und/oder über Social Media teilen.

Der Track+ besteht aus Präsentationen der Sponsoren und unterliegt somit nicht der Qualitätssicherung des Fachbeirates.

Bitte beachten Sie, dass es für vereinzelte Workshops eine Teilnehmerbeschränkung gibt. Weitere Infos hierzu finden Sie in den Workshop-Beschreibungen. 

Thema: Microservices

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Mittwoch
    21.04.
  • Donnerstag
    22.04.
, (Mittwoch, 21.April 2021)
12:20 - 13:00
Mi 1.3
Überwache Microservices einfach mit schlanken Datensonden
Überwache Microservices einfach mit schlanken Datensonden

Ein System aus Microservices agiert meist in offenen Umgebungen und kann dabei seine Konfiguration ändern. Für Entwicklung und Betrieb eines derartigen Systems ist eine Überwachungsstrategie unabdingbar. Betriebssysteme überwachen aber nur Systemdaten zur Nutzung der Betriebsmittel. Im Mittelpunkt des Vortrages steht die Überwachung von Anwendungsdaten mit Sonden, die sich einfach und unauffällig in Microservices integrieren. Spezielle Sondenprogramme bestimmen, was eine Datensonde wann mit welchen Anwendungsdaten macht, z.B. aufzeichnen, messen, prüfen, eskalieren oder auch ändern für synthetische Transaktionen, Fehlerinjektionen, Ablaufinterventionen, zur Klärung von Was-Wäre-Wenn Fragen, oder zum Nachstellen von aufgezeichneten Abläufen (Record&Replay). Ursprünglich wurden Datensonden für fehlertolerante, zeitgesteuerte Echtzeitsysteme entwickelt. Ihr Einsatz kommt auch in Frage für ereignisgesteuerte Systeme, mit oder ohne Microservices.

Zielpublikum: Entwickler, Tester, Architekten, Produktmanager
Voraussetzungen: Elementare Programmierkenntnisse erleichtern das Verständnis der geplanten Demonstrationen
Schwierigkeitsgrad: Advanced

Extended Abstract:

Microservices, die in offenen Systemumgebungen agieren und miteinander, in wechselnden Konfigurationen kommunizieren, müssen überwacht werden, im Labor und im Feld. Betriebssysteme überwachen jedoch nur Betriebsmittel, z.B. zur automatischen Lastverteilung oder zur Aufzeichnung von Daten für Loganalysen. Anwendungsspezifische Daten stehen aber in Variablen im Geschäftskern eines Microservices. Verpackt in unauffällige Datensensoren, die wie native Variablen erscheinen, können Datensonden auf diese anwendungsspezifische Daten zugreifen. Sondenprogramme legen fest, wann was mit oder durch diese Daten zu tun ist. So lassen sich Daten selektiv aufzeichnen, prüfen, bewerten und auch ändern ohne dass dafür die Implementierung eines überwachten Microservices geändert werden muss. Einfache Programmiertechniken und wenige Module mit definierten Schnittstellen genügen zur Implementierung von Kernfunktionen der Datensonden und Sondenprogramme. Die Module sind so strukturiert und entkoppelt, dass mit Datensonden auch Sondenteile überwacht werden können, z.B. die Laufzeit von Sondenprogrammen. Letzteres ist hilfreich, wenn Datensonden für Tests von Echtzeitsystemen eingesetzt werden, um den ungewünschten Sondeneffekt (probe effect) in den Griff zu bekommen, der andernfalls Tests invalidieren kann. Sondenprogramme können nicht nur Datenströme analysieren, sondern auch neue Datenströme generieren, etwa mit Hilfe von Datenfiltern oder durch Berechnung abgeleiteter Daten.

Mit Datensonden entstehen also Systeme aus zuverlässig überwachbaren Microservices. Deren Datensonden operieren lokal, in einem Microservice, oder kommunizieren mit eigenständigen, als spezielle Microservices operierende Datensonden, die eine globale Sicht haben auf mehrere, überwachbare Microservices. Datensonden wurden eingesetzt, z.B., zum Testen der Fehlertoleranz einer redundant ausgelegten X-by-Wire Fahrzeugsteuerung, zum Prüfen von invarianten Eigenschaften einer Robotersteuerung und für eine Sicherheitsintervention als letzte Option, und zum Absichern von Non-Stop Software Updates ebenfalls für einen Roboter, der von industriellen Microservices (move arm, pick object, place object ...) gesteuert wird.

Dr. Joachim Fröhlich, ACM Senior und IEEE Member, arbeitet als Senior Engineer für Siemens Technology und beschäftigt sich mit Techniken, Methoden und Prozessen für Entwicklung und Test von Software für verlässliche Systeme.
Joachim Fröhlich
Joachim Fröhlich
Vortrag: Mi 1.3
Themen: Microservices
flag VORTRAG MERKEN

Vortrag Teilen

14:15 - 14:55
Mi 1.4
Event-driven Architecture in der Allianz-Beratungssoftware
Event-driven Architecture in der Allianz-Beratungssoftware

Der Betrag diskutiert, ob und wie man event-getriebene Architekturen in einer Beratungssoftware einsetzen kann. Dabei wird der Boge von den Geschäftsanforderungen bis hin zur technischen Umsetzung gespannt. Warum wurde für diese Beratungssoftware der event-getriebene Ansatz gewählt? Es werden sowohl die geschäftlichen als auch die technischen Anforderungen diskutiert, die zur Wahl dieses Architekturansatzes geführt haben. Der event-getriebene Ansatz erwies sich als der richtige, um eine Entkopplung der Systeme und ein gesamthaftes Bild der einzelnen Aktivitäten für den Benutzer sicherzustellen.

Zur ganzen Geschichte gehören natürlich auch die Irrungen und Wirrungen, die wer auf diesem Weg durchlebt haben. Darüber berichtet der Beitrag.

Zielpublikum: Architekten, Entwickler, Entscheider, Projektleiter
Voraussetzungen: keine
Schwierigkeitsgrad: Advanced

Extended Abstract:

Die Beratungssoftware der Allianz Gruppe wird in den Agenturen eingesetzt, um Kunden gezielt und individuell beraten zu können. Dabei ist es wichtig dem Berater auf der einen Seite Hilfe und Richtung in den teilweisen komplizierten Produkten anzubieten und auf der anderen Seite die notwendige Flexibilität des Verkaufsprozesses nicht einzuschränken.

Technisch erlauben Events, die Informationen von sehr unterschiedlichen Systemen ohne eine enge Kopplung, dem Agenten zur Verfügung zu stellen. Der Gesamtprozess muss nicht den Einzelsystemen bekannt sein, sondern wird vielmehr aus den verschiedenen Informationen erst gebildet.

Dadurch erreicht man eine hoch flexible und entkoppelte Architektur, ohne auf Gesamtübersichten und strukturierte Darstellungen verzichten zu müssen.

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.
Annegret Junker
Annegret Junker
Vortrag: Mi 1.4
flag VORTRAG MERKEN

Vortrag Teilen

, (Donnerstag, 22.April 2021)
12:20 - 13:00
Do 3.3
Die Corona-Warn-App unter der Lupe
Die Corona-Warn-App unter der Lupe

Leuchtturmprojekt, Kostengrab, Hoffnungsträger und wichtiger Baustein in der Pandemiebekämpfung - das deutsche Corona-Warn-App-System (kurz CWA) besteht nicht nur aus den recht prominenten iOS- und Android-Apps. Zur Umsetzung von Use Cases wie der persönlichen Risikoermitttlung oder dem Melden von (positiven) Testergebnissen, gehört auch eine vielteilige Server-Lösung. Sie basiert auf einem zeitgemäßen Architekturstil und einem aktuellen Technologie-Stack. Und wurde unter hohem Zeitdruck federführend von SAP und Deutscher Telekom realisiert. 

Das öffentliche Interesse an diesem Projekt ist hoch, die Transparenz bei der Entwicklung erfreulicherweise ebenfalls. Der Quellcode ist Open Source und auch die Dokumentation offen zugänglich. Wir diskutieren die prägenden architekturrelevanten Anforderungen und die getroffenen Entscheidungen. Zum Abschluss bewerten wir die gewählten Lösungsansätze und arbeiten Stärken, Hindernisse und Kompromisse heraus.

Zielpublikum: Architekten, Entwickler, Entscheider
Voraussetzungen: keine speziellen, Kenntnisse moderner Softwarearchitekturen sind hilfreich
Schwierigkeitsgrad: Basic

Falk Sippach arbeitet bei der embarc Software Consulting GmbH als Software-Architekt, Berater und Trainer. Bereits seit über 15 Jahren unterstützt er in meist agilen Software-Entwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln sowie bei Vorträgen und unterstützt bei der Organisation diverser Fachveranstaltungen.
Falk Sippach
Falk Sippach
flag VORTRAG MERKEN

Vortrag Teilen

14:15 - 14:55
Do 1.4
Aus der Rubrik 'Spaß mit Microservices': Transaktionen
Aus der Rubrik 'Spaß mit Microservices': Transaktionen

Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler technischer Transaktionen an, auch Saga-Pattern genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt seine praktische Verwendung an verschiedenen Beispielen.

Zielpublikum: Architekten, Entwickler
Voraussetzungen: Kenntnisse zu Microservices
Schwierigkeitsgrad: Basic

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, wobei neben Design- und Architektur-Fragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.
Lars Röwekamp
Lars Röwekamp
Vortrag: Do 1.4
Themen: Microservices
flag VORTRAG MERKEN

Vortrag Teilen

Zurück