Problembeschreibung
Eine Microservice-Architektur verfolgt den Ansatz, ein IT-System (in der Regel eine webbasierte Anwendung) als Suite von weitgehend unabhängigen vertikalen Modulen aufzubauen. Diese können (weitgehend) unabhängig voneinander deployed und betrieben werden und benötigen nur ein Minimum an zentraler Kommunikationsinfrastruktur. Kommunikation zwischen Front- und Backend erfolgt über leichtgewichtige Protokolle wie etwa REST.
Dieser Architekturstil erlaubt es, ganze Anwendungslandschaften nach Geschäftsfähigkeiten zu segmentieren. Die resultierenden Teilfunktionalitäten können dann in Form von Microservices implementiert und lose gekoppelt werden. So entstehen Systeme von Anwendungen, die einerseits miteinander kommunizieren, und andererseits jeweils mit einem Höchstmaß an Unabhängigkeit entwickelt und gewartet werden können.
Eine Microservice-Architektur bietet sich daher besonders an, um Softwareprojekte an der Hochschule (wie dem Campus Gummersbach) zu realisieren. Es ist offensichtlich sinnvoll, Systeme zur Verwaltung von Räumen, Praktika, Veranstaltungen, Projekten, Prüfungen etc. miteinander zu vernetzen. Andererseits werden diese Anwendungen von verschiedenen Gruppen mit verschiedenen Technologien gepflegt. Eine enge Abstimmung ist an der Hochschule weder sinnvoll noch durchsetzbar.
Um solchen Projekten ein Maximum an Freiheit bei Technologiewahl und Umsetzungsform zu gewähren, wäre ein Architektur-Blueprint für Basistechnologien zur Umsetzung von Services und Koppelung von Schnittstellen eine große Hilfe. Dies soll im Rahmen dieses Projekts an einem konkreten Beispiel konzipiert und pilotiert werden.
Projektbeschreibung
Ziel des Projekts ist es, für die Applikationslandschaft „Campus Gummersbach“ einen Architektur-Blueprint, basierend auf dem Microservices-Ansatz, zu konzipieren.
Dieses Konzept soll am Beispiel der Projektbörse Campus GM pilotiert und iterativ-inkrementell erarbeitet werden.
In der Master-Veranstaltung Anforderungsmanagement (SS17) wurde hierfür eine Anforderungsspezifikation (Lastenheft) erstellt. Darauf aufbauend hat die Master-Veranstaltung FAE eine Architekturspezifikation (Pflichtenheft) erstellt. Im SS 18 wurde in einem Guided Project mit der eigentlichen Implementierung der Projektbörse begonnen, erste Microservices wurden umgesetzt und nötige Infrastruktur geschaffen.
Die Teams des folgenden Guided Projects übernehmen die Verantwortung für einzelne (bereits bestehende) Microservices und kümmern sich sowohl um Weiterentwicklung/Betrieb der Services als auch der Entwicklungs- und Ausführungsinfrastruktur. Je nach Bedarf werden neue Microservices entwickelt, Umsysteme eingebunden und die Infrastruktur verfeinert. Die entwickelten Microservices basieren dabei auf dem Spring Boot Framework (Java).
Diese Pilotanwendung wird genutzt, um den entwickelten Architektur-Blueprint zu verfeinern, zu validieren und offene Fragen zu identifizieren.
Projektmethodik
Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen. Die Teams werden hierbei durch wissenschaftliche Mitarbeiter in der Rolle des Scrum Masters betreut. Die agilen Teamprozesse werden gemäß Typ-A-Definition von Prof. Stumpf methodisch begleitet. Das Projekt wird in (vermutlich vierwöchige) Sprints gegliedert. Axel Burghof von Capgemini wird bei den Sprint Reviews zugegen sein.
Learning Outcomes
- Praxiserfahrung mit Microservice-Architekturen
- Erfahrung in der Konzeption und Pilotierung eines praxisnahen, umfangreichen Softwareprojekts
- Gelegenheit zur konkreten Verwendung von „Bleeding Edge“ Technologien
- Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
- Expertise in Kommunikation und Dokumentation
- Teamwork- und Projektmanagement-Erfahrung
Voraussetzungen
- Programmierkenntnisse
- Grundkenntnisse Linux
- Interesse an professioneller Software-Entwicklung
- Interesse an der Softwarearchitektur
- Interesse an komplexen Aufgabenstellungen und methodischem Vorgehen
- Bereitschaft sich eigenständig in neue Frameworks, Tools und Konzepte einzuarbeiten
- Bereitschaft, Teamarbeit tatsächlich physisch gemeinsam (im gleichen Raum, „collocated“) durchzuführen, um zu einem agilen Team zu reifen
- Bereitschaft, gemäß agiler Vorgehensweise durch geeignete Tools Transparenz über den eigenen Beitrag zur Gruppenleistung zuzulassen
Externe Projektpartner
–
