Pool² Dokumentation

Einführung

Jeder Supporter findet heute seinen Weg zu VcA über den Pool. Daher ist das Tool zu einem zentralen Bestandteil unseres Netzwerks geworden. Ob nun das nächste Festival mit sinnstiftender Aktivität füllen, die gesammelten Spenden dokumentieren oder einfach informiert bleiben - all dies läuft mittlerweile über den Pool und so erlaubt das System das dezentrale Wachstum von VcA. Während die neuen Funktionen, wie etwa Email-Newsletter der Crews, unser Zusammenwirken vereinfacht und teilweise sogar erst ermöglicht haben, versuchten wir den Pool so zu gestalten, dass dieser unseren Bedürfnissen entspricht. Soziales und technisches System haben sich also gegenseitig beeinflusst und sind mittlerweile stark miteinander verwoben.

Viva con Agua ist erfolgreich, weil sehr viele Menschen mit Spaß und Kreativität aktiv werden können. Wir erhalten unsere Motivation, indem wir immer wieder Neues zu probieren, aber uns dabei nicht selbst übernehmen. Denn das Wachstum von VcA basiert nicht auf der Vergrößerung einzelner Aktionen, sondern auf der Vermehrung unterschiedlicher Aktionen. Die dezentrale Organisation, welche der Pool erlaubt, ist somit auch Garant für den Erfolg von VcA.

Gleichzeitig ist die dezentrale Struktur auch die größte Hürde für die Weiterentwicklung des Pools (also die Anpassung des Pools an unser soziales System). Denn wie sollen die vielen verschiedenen Entwicklungen in den Crews, die teilweise auch im Konflikt miteinander stehen, in einem technischen Tool zusammenfließen? Eine Crew braucht dringend einen Chat, um schnell Informationen weiterzugeben, die nächste Crew hätte gerne Abstimmungshilfen, um wirklich faire Entscheidungen zu treffen, verzichtet aber explizit auf Chats, damit das Persönliche zwischen den Supportern nicht zu kurz kommt. Die Umsetzung solcher verschiedenen Anforderungen ist nicht alleine komplex, sondern erfordert auch ein gut koordiniertes, größeres Team an Entwicklern. Für eine gemeinnützige Organisation ist der damit verbundene finanzielle Aufwand nicht zu bewältigen.

IT Projektkultur

Wir haben uns vorgenommen genau die Elemente der VcA Projekte im IT-Umfeld umzusetzen, welche für den Erfolg maßgeblich sind. Das bedeutet, Beteiligte sollten intrinsisch motiviert sein sowie Spaß und Freude an der Realisierung des Projekts haben. Außerdem ist der Pool² eine Komposition kleiner, dezentral organisierter und möglichst unabhängiger Projekte.

Zur Realisierung der angestrebten Kultur sehen wir uns mit diversen Herausforderungen konfrontiert: Zunächst müssen Menschen gefunden werden, die an einer kontinuierlichen technischen Weiterentwicklung in Symbiose mit dem sozialen System interessiert sind. Dabei können ähnlichen Strukturen wie in Open Source Communities entstehen, studentische Arbeiten integriert werden oder Organisationen im Sinne des All-Profit Gedanken einen Beitrag leisten. Zudem muss die Unabhängigkeit der Beteiligten ermöglicht werden. Es gilt also die notwendige Einarbeitung gering zu halten und die Unabhängigkeit von Technologien weitestgehend zu gewährleisten. Auch die Schnittstellen zur Koordination zwischen den Teams sollten frei gestaltet werden können, so dass verschiedene Projektmanagement-Stile unterstützt werden.

Architektur

Die zuvor beschriebene Herausforderungen möchten wir ganzheitlich und in Zusammenhang betrachten. Daher sollte die Entscheidung über eine Architektur nicht alleine die funktionalen Anforderungen an den Pool² beachten, sondern eben auch Trennung der Projektteams hinsichtlich Technologie und Koordination gewährleisten. Neben klassischen monolithischen Architekturen, betrachten wir daher auch stark in Komponenten separierte Varianten und die Auswirkungen der jeweiligen Architekturen auf die Projektkultur. Nach Conway designed eine Organisation stets Systeme, welche die Kommunikationsstrukturen in der entwickelnden Organisation wiederspiegeln, was für Open Source Communities bereits häufig bestätigt werden konnte. Da wir eine möglichst lose Struktur im Projekt anstreben, werden wir also auch lose Kommunikationsstrukturen zwischen den einzelnen Projektteams im Projekt wiederfinden. Dem folgend wird der Pool² also ebenfalls eine sehr lose Struktur in seiner Architektur aufweisen (viele unabhängige Komponenten).

Fehler beim Erstellen des Vorschaubildes: Datei fehlt

Abbildung der Funktionen des Pools in Komponenten des Pool²

Eine moderne Form einer losen Architektur basiert auf Microservices. Ein Microservice ist dabei eine eigenständige Anwendung, welche in einem eigenen Prozess läuft und eine starke Kohäsion bzgl. eines Bounded Context aufweist. Zudem steht ein solcher Service dauerhaft in Verbindung mit anderen Microservices und verwendet dabei eine leichtgewichtige Kommunikation, wie etwa RESTful webservices. Eine Menge solcher Microservices wird Microservice Architektur genannt.

Da Microservices weitgehend unabhängig voneinander agieren, ist eine freie Wahl der Technologie für jeden einzelnen Service gegeben (mit geringen Einschränkungen, die nachfolgend in #Konzepte aufgeführt werden. Auch beschränkt sich der Einarbeitungsaufwand auf die Schnittstellen, welche gezwungenermaßen gut dokumentiert sind. Auch koordinative Abhängigkeiten sind stark eingeschränkt und so bietet eine derartige Architektur die Möglichkeit die zuvor beschriebene Projektkultur zu etablieren.

Die funktionalen Anforderungen an den Pool² werden im ersten Schritt durch den Funktionsumfang des ersten Pool definiert. Abbildung 1 zeigt die Projektion der Funktionen des Pool auf Microservices des Pool². Drops ist für die Nutzerverwaltung verantwortlich, während Stream die Finanzen und Waves die Aktionen hält. Bloob dient der Kommunikation. Diese Services bilden alleine die offensichtlichen funktionalen Anforderungen ab. #Konzepte führt weitere, zumeist nicht-funktionale Anforderungen sowie die weiteren Microservices ein, die diese Anforderungen realisieren. Zudem sind andere nicht-funktionale Anforderungen abzubilden. So benötigt etwa jedes Kollaborationstool ein Awareness-System, welches die Nutzer übereinander informiert (etwa durch Notifications).

Eine Microservice Architektur impliziert diverse Herausforderungen, die in monolithischen Architekturen nicht auftreten würden. Das Pool² Projekt in Zusammenarbeit mit der Humboldt-Universität zu Berlin dient der Vorbereitung einer Microservice Architektur und von Konzepten, mit deren Hilfe die Herausforderungen angegangen werden können. Wie etwa kann eine Shared Session zwischen den Microservices hergestellt werden, so dass die Supporter sich nicht in jedem Microservice einzeln authentifizieren müssen? Wie genau sieht die Kommunikation der Microservices aus? Wie lässt sich diese absichern? Wie kann sichergestellt werden, dass die verschiedenen Services, die auch von verschiedenen Kooperationspartnern erstellt werden einem einheitlichen Corporate Design (CD) folgen, ohne das dabei doppelter Code entsteht und die Wartbarkeit des System erschwert wird? Diese und weitere Fragen sollen im Abschnitt #Konzepte diskutiert werden. Die entstehenden Diskurse sollen dabei stets auch eine Lösung aufzeigen.

Konzepte

Nachfolgend werden grundlegende Konzepte aufgeführt, die eine Implementierung der zuvor beschriebenen, angestrebten Lösung auf technischer Ebene erlauben. Die Liste von Konzepten wird dabei kontinuierlich erweitert und dient einer ersten Orientierung, wenn ein neuer Microservice entwickelt werden soll.

Bezeichnung	Beschreibung	Status
Dynamic UI Fragment Composition	In einer dezentralen Microservice Architektur ist die Implementierung der Nutzeroberfläche eine Herausforderung. Da ein zentraler Service starke Abhängigkeiten aller anderen Services zu diesem einen Service erzeugt, ist dies für die angestrebte Projektkultur keine Lösung. Somit muss jeder Service seine eigene Nutzeroberfläche implementieren können, dabei ist aber ein Corporate Design (CD) zu beachten und Code Duplizierung zu vermeiden. Das vorliegende Konzept beschreibt, wie diese Ziele erreicht werden können.	Draft
Business Object Exchange	Ein Microservice übernimmt die Verantwortung für (mehrere) Business Objects (BO). Diese müssen gegebenenfalls an andere Microservices weitergegeben werden, da diese zusätzliche Informationen zur Durchführung der bereitgestellten Operationen benötigen. Das vorliegende Konzept beschreibt den Austausch der BOs basierend auf RESTful webservices.	Draft
Shared Session	Innerhalb vieler Microservices werden Nutzer identifiziert werden müssen. Damit nicht jeder Microservice eine eigenen Authentifizierung implementieren muss und damit die Wartbarkeit des Gesamtsystem erschwert und außerdem den Nutzern kein eigener Login für jeden Microservice zugemutet wird, soll eine Shared Session implementiert werden. Das vorliegende Konzept beschreibt die Shared Session basierend auf einem OAuth2 Handshake zwischen den Microservices, so dass nur ein Service eine tatsächliche Session mit dem Nutzer halten muss.	Draft
Task-based role system and access control	Klassische Modelle der Zugriffsverwaltung, basierend auf statischen Rollen die einem Nutzer zugewiesen werden können, sind auf das dynamische soziale System von Viva con Agua nicht anwendbar. Allein das Prinzip der Open Participation, welches bei Viva con Agua gelebt wird, verbietet eine starre Implementierung von Rollen mit implizit definierten Zugriffsrechten und daraus resultierenden Aufgaben. Das vorliegende Konzept beschreibt eine Zugriffskontrolle, basierend auf der Assoziation von Nutzern zu Aufgaben. Dabei wird eine Menge von Aufgaben eine dynamische Rolle beschreiben und so das soziale System von VcA angemessen gespiegelt.	Draft
Action-based extension of user representation	Dem Prinzip der Open Participation bei VcA gerecht werdend, sollen Nutzer im Rahmen der Registrierung so wenig Informationen wie nötig angeben müssen. Einige Aktivitäten im Pool² erfordert jedoch mehr Wissen über den Nutzer. So wird etwa bei der Anmeldung für ein Festival die Handynummer und das Geburtsdatum benötigt. Die angestrebte Microservice Architektur soll es ermöglichen dynamisch neue Funktionen dem Pool² hinzuzufügen. Somit kann der Pool² zur Laufzeit um Funktionen erweitert werden die mehr Informationen über den authentifizierten Nutzer erfordern, als dieser bisher angegeben hat. Diesem Problem begegnet das vorliegende Konzept mit einer dynamischen Erweiterung der Stammdaten des Nutzers immer zu genau dem Zeitpunkt, zu dem der Nutzer eine Funktion nutzen möchte. Dabei wird der Datensatz stets nur um die fehlenden Informationen erweitert.	Draft
Intra-Microserves authentication	Bei der Kommunikation zwischen den verschieden Microservices im VcA Pool², müssen diese die Möglichkeit haben sich untereinander zu authentifizieren. Beispielsweise ist es für Drops wichtig zu wissen, ob ein Microservice der eine Shared Session anfordert, auch wirklich Bestandteil des Netzwerkes ist. Andernfalls könnte ein „man in the middle“ die Shared Session abfangen und somit auch im Namen des Nutzers agieren. Realisiert wird die Authentifizierung über einen eigenen Microservice „Sluice“. Das Konzept beschreibt dabei das vorgehen von Sluice und die Auswirkungen auf verschiedene Kommunikationsebenen im Pool².	Draft

Infrastruktur

Deskription Infratsruktur:

• Pool² overview - Beschreibung der Kommunikation und des Zusammenspiels der einzelnen Microservice.
• Deployment - Funktionsweise des Docker-Netzwerk und Beschreibung des Deployment.

Server:

• Stage Server (HU): https://vca.informatik.hu-berlin.de