Veröffentlicht: von

Für alle Abschlussarbeiten vereinbare ich mit den Studierenden ein 2-wöchentliches Statusgespräch. Dies gilt auch für die vorbereitenden Praxisprojekte für die Bachelorarbeit.

Ab diesem Semester veranstalten meine Mitarbeiter und ich zusätzlich ein Projekttreffen (Mittwochs vormittags alle 4 Wochen), bei dem jeder Studierende, der ein Projekt oder eine Abschlussarbeit im thematischen Umfeld „ArchiLab / Microservices“ bearbeitet, seinen/ihren Stand kurz (ca. 10 min pro Person) vorträgt. Zusätzlich stellt auch das ArchiLab-Team seinen aktuellen Stand vor. Dieses Treffen findet im Raum 1522 statt.

Die aktuellen Termine und Teilnehmer für Statusgespräche und das Projekttreffen finden Sie hier: Termine Status- und Projekttreffen

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit. Praxisprojekte und/oder Bachelorarbeiten können auch im Verbund mit mehreren Studierenden bearbeitet werden.

Worum geht es?

Dokumentation ist in der Regel ein ungeliebtes Thema. Die agile Community hat dieses Thema entformalisiert und pragmatischer gemacht, kämpft aber immer noch mit der richtigen Mischung aus „Der Code ist die Dokumentation“ und „Wir pflegen ein Extra-Architektur-Dokument“.

ThoughtWorks hat LightWeight Architecture Decision Record in den Status „Adopt“ seines Technology Radars erhoben (https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records). Was heißt das konkret und in der gelebten Praxis?

Inhalt

Ziel der Arbeit ist eine umfassende Literatur-, Technologie- und Empiriestudie (Expertenbefragungen). Am Ende sollte ein Vorschlag mit einem oder mehreren sinnvollen Varianten zur Dokumentation stehen.

Ein praktischer Anwendungsfall, in dem die gewählte Lösung anhand eines Beispiels (als Prototyp) in einem Produktivsystem umgesetzt wird, sollte die Arbeit abrunden. Als Produktivsystem kann dabei die konsequent und kompromisslos als System von Microservices ausgelegte Lehr- und Lernplattform ArchiLab darstellen.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit. Praxisprojekte und/oder Bachelorarbeiten können auch im Verbund mit mehreren Studierenden bearbeitet werden.

Worum geht es?

Aus Sicht eines effizienten System-Monitorings wäre es sehr attraktiv, Machine-Learning-Techniken zu nutzen, um Ausfälle/Störungen von bestimmen IT-Komponenten oder -Services frühzeitig vorhersagen zu können.

ThoughtWorks klassifiziert diese Technik als „zu beobachten“ (Assess), siehe https://www.thoughtworks.com/radar/techniques/algorithmic-it-operations.

Inhalt

Die Arbeit sollte zunächst eine umfassende Literatur- und Technologierecherche zu diesem Thema durchführen. Dann sollte ein Forschungsdesign für einen Prototypen konzipiert werden, um einen Proof-of-Concept umzusetzen und das Potential dieser Technik zu bewerten.

Ein praktischer Anwendungsfall, in dem die gewählte Lösung anhand eines Beispiels (als Prototyp) in einem Produktivsystem umgesetzt wird, kann die Arbeit abrunden. Als Produktivsystem kann dabei die konsequent und kompromisslos als System von Microservices ausgelegte Lehr- und Lernplattform ArchiLab darstellen.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit. Praxisprojekte und/oder Bachelorarbeiten können auch im Verbund mit mehreren Studierenden bearbeitet werden. Ebenso kann das Thema mit mehreren Studierenden als Informatikprojekt bearbeitet werden.

Worum geht es?

Ein API-Gateway stellt APIs für Clients und/oder externe IT-Systeme zur Verfügung. Das hat mehrere Nutzeffekte:

  • Service Composition: Verschiedene interne Services können zu einem (ggfs. Client-spezifischen) Service komponiert werden
  • Versionierung: man kann eine Version eines Service gegen eine neue austauschen, ohne dass der externe Consumer dies mitbekommt. Wenn die neue Version eine geänderte Schnittstelle beinhaltet, kann das API-Gateway eine Konversion implementieren
  • Protokoll-Übersetzung: So kann etwa der externe Client eine REST-Schnittstelle vorfinden, während intern eine Message Queue verwendet wird.
  • Mocking: Statt dem echten Service für Servicezwecke einen Mock verwenden

Bei komplexen Microservice-Landschaften wird Service Discovery zu einer Notwendigkeit, um nicht zu viel manuellen Konfigurations- und Wartungsaufwand zu haben.

Besonders interessant wäre daher eine Kombination von Service Discovery und einer API-Gateway-Implementierung. Die internen Services sollten dabei die Möglichkeit haben, APIs als Public oder Private zu kennzeichen. Die Services könnten dann entsprechend automatisch zur Verfügung gestellt werden.

Inhalt

In dieser Arbeit sollten zunächst die Anforderungen an ein solches kombiniertes API Gateway definiert werden. Dafür sind Literaturrecherche und Expertenbefragungen denkbar.

Auf dieser Basis sollte dann eine Implementierung umgesetzt werden. Ziel sollte zunächst ein funktionsfähiger Prototyp, mit Perspektive auf ein Minimum Viable Product, sein. Wenn das Projekt gut verläuft, ist auch die Veröffentlichung als Open Source eine Perspektive.

Ein praktischer Anwendungsfall, in dem die gewählte Lösung anhand eines Beispiels (als Prototyp) in einem Produktivsystem umgesetzt wird, kann die Arbeit abrunden. Als Produktivsystem dient dabei die konsequent und kompromisslos als System von Microservices ausgelegte Lehr- und Lernplattform ArchiLab.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit. Praxisprojekte und/oder Bachelorarbeiten können auch im Verbund mit mehreren Studierenden bearbeitet werden.

Worum geht es?

Microservices ermöglichen eine sehr lose gekoppelte und daher potentiell gut dezentral änderbare Architektur. Konsequent auf eine gesamte IT-Landschaft angewendet, gewinnt man ein hohes Maß an Flexibilität.

Diese Art der losen Kopplung passt zunächst einmal nicht gut auf IT-Landschaften, die von sehr langen, komplexen Prozessen geprägt ist, die sich quer durch die gesamte Landschaft ziehen. Diese Art von Strukturen findet man beispielsweise bei Versicherungen. Ein Schadensprozess läuft durch viele komplexe IT-Systeme (Vertragsmanagement, CRM, Schadensystem, In-/Exkasso, etc.). Daher sind Versicherungs-IT-Landschaften in der Regel von einem klassischen SOA-Ansatz geprägt, bei dem Prozesse zentral in einer Prozess-Engine abgebildet werden und von dort dann die dedizierten IT-Systeme über Service-Schnittstellen aufrufen. Man spricht hier von Orchestrierung des Prozesses, da dieser zentral gesteuert abläuft.

Wie modelliert man so eine IT-Landschaft als Microservices? Ist das überhaupt sinnvoll? Die Frage ist von hoher praktischer Relevanz. Die Standard-Antwort der MS-Community ist das Prinzip der Choreographie, bei dem die einzelnen MS durch passendes Servicedesign den Prozess implizit abbilden, z.B. mit dedizierten Abort-Events.

Zwei einander widersprechende Ansätze sind in den nachfolgenden beiden Blog-Posts (der zweite ist eine Antwort auf den ersten) abgebildet.

Kurz zusammengefasst skizziert der erste Post einen Hybrid-Ansatz, der Microservices und eine SOA-ähnliche Orchestrierung zusammenführt. Der zweite Post skizziert die Entsprechung als reine MS-Choreographie. Beide Posts widersprechen einander. Wer hat Recht? Dazu soll diese Arbeit eine Antwort geben.

Inhalt

Die Arbeit sollte zunächst analysieren, ob man Geschäftsprozesse nach bestimmten Kriterien klassifizieren kann, anhand deren man eine Entscheidung für eins der beiden Paradigmen „Orchestrierung“ vs. „Choreographie“ treffen kann. Ein praktisches Prozessbeispiel sollte definiert werden, das eine gewisse realistische Komplexität simuliert, gern anhand eines Versicherungs-Beispiels.

Dann sollte für die Bewertung ein Kriteriensystem definiert werden, anhand dessen sich die beiden Paradigmen bewerten lassen. Beide Paradigmen sollten prototypisch implementiert und anhand der Kriterien verglichen werden. Abschließend sollte eine Empfehlung ausgesprochen werden.

Ein praktischer Anwendungsfall, in dem die gewählte Lösung anhand eines Beispiels (als Prototyp) in einem Produktivsystem umgesetzt wird, kann die Arbeit abrunden. Als Produktivsystem kann dabei die konsequent und kompromisslos als System von Microservices ausgelegte Lehr- und Lernplattform ArchiLab darstellen.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit. Praxisprojekte und/oder Bachelorarbeiten können auch im Verbund mit mehreren Studierenden bearbeitet werden. Ebenso kann das Thema mit mehreren Studierenden als Informatikprojekt bearbeitet werden.

Worum geht es?

Visuelle Programmiersprachen erlauben die Programmierung von Funktionalität durch visuelles „Zusammenstecken“ von Bausteinen per Drag&Drop. Diese Art der Programmierung gilt als intuitiv erlernbar und ist damit auch für weniger technologieaffine Personen nutzbar. Wikipedia listet allein mehr als 100 verschiedene visuelle Programmiersprachen.

Genau genommen könnte man auch BPMN den visuellen Sprachen zuordnen. BPMN wird klassischerweise von der Fachseite verwendet, um Geschäftsprozesse visuell zu spezifizieren. Die entstehenden Prozessdiagramm können ohne weitere Transformation von Prozess-Engines direkt ausgeführt werden.

Dies ist auch die Inspiration für diese Idee für ein Projekts / eine Abschlussarbeit: Wie wäre es, wenn die Fachseite (oder zumindest jemand, der kein ausgewiesener Microservice-Experte ist) die Geschäftslogik eines MS mittels visueller Programmierung definiert? Der „Boilerplate“-Anteil eines MS (z.B. REST-API, Load Balancer, Resilience, …) kann dann in Form eines Standard-Chassis zugeführt werden.

Inhalt

In dieser Arbeit soll zunächst recherchiert werden, welche der vielen visuellen Programmiersprachen sich für die beschriebene Verwendung in einem Microservice eignen (BPMN und Workflow-Engines sollten dabei mit berücksichtigt werden).  Dafür ist ein Anforderungskatalog zu erstellen und eine Technologie-Recherche durchzuführen. Eine „Shortlist“ sollte dann per Proof-of-Concept praktisch verprobt werden.

Als zweite Hauptaufgabe sollte ein Standard-Chassis für die anfallenden „Boilerplate“ Aufgaben eines MS definiert und analog wie oben verprobt werden.

Abschließend sollte eine Empfehlung ausgesprochen werden. Ein praktischer Anwendungsfall, in dem die gewählte Lösung anhand eines Beispiels (als Prototyp) in einem Produktivsystem umgesetzt wird, kann die Arbeit abrunden. Als Produktivsystem dient dabei die konsequent und kompromisslos als System von Microservices ausgelegte Lehr- und Lernplattform ArchiLab.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit. Praxisprojekte und/oder Bachelorarbeiten können auch im Verbund mit mehreren Studierenden bearbeitet werden.

Worum geht es?

Microservices sind von ihrer Definition her Technologie-agnostisch. Das Umsetzungsteam hat – im Rahmen der strategischen Leitplanken der IT-Organisation – Freiheit in der Technologiewahl. Das schließt natürlich auch die Programmiersprache ein.

Aber gibt es tatsächlich signifikante Unterschiede, wenn man auf diese Ebene heruntersteigt? Oder ist „Java doch für alles gut“? Es gibt eine Anzahl zu klärender Fragen:

  • Welche Standards muss eine Programmiersprache mitbringen, damit man sinnvoll überhaupt einen Microservice implementieren kann?
  • Gibt es signifikante Vorteile / Nachteile bei verschiedenen Sprachen?
  • Wie sieht es mit der Verfügbarkeit von Frameworks in bestimmten Sprachen aus?
  • Wie gut funktioniert die Einbindung in eine Continuous-Integration-Pipeline?

Inhalt

In dieser Arbeit soll eine Bewertungsmethodik für Microservice-Teams entstehen, mit der diese schnell entscheiden können, welche Sprache für die Problemstellung interessant ist.

Dazu sollten Evaluierungskriterien vorab festgelegt werden. Weiterhin müssen sinnvolle „Klassen“ von Services definiert werden (nach Literaturrecherche und/oder empirischen Expertenbefragungen).

Darauf aufbauend werden eine Anzahl von Proof-of-Concept-Implementationen umgesetzt und gemäß der Kriterien bewertet. Abschließend wird daraus die Methodik definiert, die z.B. aus einem Satz von „wenn – dann“ Regeln bestehen kann, gepaart mit Technologieempfehlungen.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit. Alternativ, wenn sich mindestens zwei Teilnehmer finden, auch als Informatikprojekt.

Worum geht es?

Bei der Implementierung von Clients ist ein Mobile Client heutzutage in der Regel gesetzt. Allerdings steht man immer vor der Entscheidung, ob es eine native App sein muss, oder ob auch ein Responsive Web Client genügt.

Bestimmte Anwendungen funktionieren nur mit nativen Apps, beispielsweise gewisse Zugriffe auf Systemfunktionen. Allerdings handelt man sich unter Umständen einen signifikanten Entwicklungs- und Wartungsaufwand ein. Eine Responsive Web App ist einfacher zu realisieren, bietet aber nicht ganz den gleichen Standard in Punkto User Experience und Funktionsumfang.

Soweit der triviale Teil. Jetzt der vielleicht interessantere: Kann man klare Kriterien definieren, wann die eine Lösung sich eher empfiehlt und wann die andere? Wie sehen diese Kriterien aus? Kann man Mobile Clients generell in Klassen einteilen, so dass eine bestimmte Klasse gut als Responsive Web App funktioniert, und die andere einen nativen Client nahelegt?

Inhalt

In dieser Arbeit sollen Technologien und Designpatterns für Mobile Clients verglichen werden, um zu einer möglichst allgemeinen Aussage bezüglich der obigen Problemstellung zu kommen. Idealerweise kann im Sinne einer Methodik ein Satz von „wenn – dann“ Regeln formuliert werden, gepaart mit Technologieempfehlungen.

Dazu sollten Evaluierungskriterien vorab festgelegt werden. Diese werden dann durch eine Anzahl von Proof-of-Concept-Implementationen beispielhaft umgesetzt. Eine Bewertung kann dann z.B. durch Usability Tests passieren.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit. Alternativ, wenn sich mindestens zwei Teilnehmer finden, auch als Informatikprojekt.

Worum geht es?

Aus Microservices bestehende IT-Landschaften sind maximal dezentral konzipiert, d.h. es gibt im Regelfall keine (oder nur eine sehr rudimentär) zentral steuernde Governance. Die Abhängigkeiten zwischen Microservices werden bewusst weniger stark überwacht als das in herkömmlichen, monolithischen Strukturen der Fall ist.

Umso wichtiger ist es in diesen dezentralen Strukturen, dass der Ausfall eines Service keinen Ripple Effect in der gesamten Service-Landschaft auslöst. Der einzelne Service muss in die Lage versetzt werden, mit dem Ausfall von anderen Services, deren Input er braucht, umzugehen. Man spricht in diesem Fall von Resilienz (Widerstandsfähigkeit) von Services.

Inhalt

In dieser Arbeit sollen Architekturmuster und Technologien recherchiert werden, die Resilienz in Microservice-Architekturen ermöglichen, wie beispielsweise Bulkhead oder Cicruit Breaker.

Als nächster Schritt sollte ein Szenario definiert werden, das eine große Menge von Microservices in einer realistisch großen IT-Landschaft wie der von Otto, Zalando, Netflix oder Amazon nahekommt – also mehrere 100 Services. Hier kann mit geeigneten Dummy-Services gearbeitet werden, die ein passendes Zufallsverhalten an den Tag legen. Als Host-Plattform käme ein kommerzieller Cloudanbieter wie AWS oder Google in Frage.

Anhand dieser Landschaft können Konzepte / Patterns / Technologien als Proof-of-Concept verprobt und nach vorher bestimmten Kriterien bewertet werden. Hierbei muss das Verhalten der gesamten Landschaft betrachtet werden.

Abschließlich soll die gewählte Lösung als Prototyp in einem Produktivsystem umgesetzt werden. Als Produktivsystem dient dabei die konsequent und kompromisslos als System von Microservices ausgelegte Lehr- und Lernplattform ArchiLab.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit.

Worum geht es?

Microservice-Architekturen werden in der Regel mit Continuous Delivery oder Continuous Deployment kombiniert, um die Flexibilität dieses Architekturstils für ein maximal schnelles Time-to-Market zu nutzen. Das macht den Umgang mit Produktivdaten zu einem außerordentlich heiklen Bereich. Einerseits werden durch ein Continuous Deployment neue Service-Instanzen unmittelbar in den Produktivbetrieb gebracht, es geht also schnell. Andererseits kann dabei durchaus ja z.B. eine Änderung des DB-Schemas vorgenommen werden. Es ist also große Sorgfalt angebracht.

Backup ist ein verwandtes Thema – wie kann möglichst als Querschnittsdienst (d.h. Dienste, die bei vielen Microservices in gleicher Weise vonnöten sind) sichergestellt werden, dass die Produktivdaten regelmäßig und verlässlich gesichert werden?

Inhalt

In dieser Arbeit sollen Architekturmuster und Technologien recherchiert werden, die den Umgang mit Datenmigration und Backup in Microservice-Architekturen erleichtern. Diese sollen als Proof-of-Concept verprobt, nach vorher bestimmten Kriterien bewerten und schließlich als Prototyp in einem Produktivsystem umgesetzt werden.

Als Produktivsystem dient dabei die konsequent und kompromisslos als System von Microservices ausgelegte Lehr- und Lernplattform ArchiLab.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.