Das Interesse an Microservice Architekturen scheint ungebrochen. Eine Sonderform sind die sogenannten Self Contained Systems (SCS), als vollumfängliche Microservice Variante (Microservice mit UI). Im Zuge eines Kundenprojektes hatten wir die Chance eine Portallösung zu entwickeln mit deren Hilfe Self Contained Systems auf einfache Art und Weise integriert werden sollen. Spannende Aspekte waren dabei der MEAN Stack (MongoDB, Express, Angular, NodeJS) und Microsoft Azure als Cloudplattform. Dieser Talk zeigt, wie sich diese Aspekte zu einem großen Ganzen zusammengefügt haben und welche Erfahrungen wir auf dem Weg dorthin machen durften.

1. Ein Praxisbericht
Daniel Bremer-Tonn
daniel.bremer-tonn@akquinet.de
Mean SCS
in der
Cloud

2. MEAN SCS in der Cloud
Von den Anforderungen zur Umsetzung

3. Anforderungen
„ Kunde ist Anbieter von medizinischen Geräten
„ Aufsammeln und Aufbereitung der Daten
„ Jede Menge datenbasierter Dienste in der Entwicklung
„ Plattform als zentraler Einstieg für Kunden
„ Ziel in erster Linie Visualisierung von Daten
„ Integration verschiedenster Datendienste in Form von Widgets
„ Dashboard Funktionalität (Zusammenstellung von Widgets etc)

4. Anforderungen
Zusammengedampfte nicht funktionale Anforderungen:
„ Langlebige zentrale Plattform
„ Services mit den fachlichen Features
§ Services sollen von verschiedenen Anbietern entwickelt werden können
§ Unterschiedlichste Anwendergruppen
„ Entkoppelte Releases von Portal und Services
„ Zielplattform: Microsoft Azure

5. Vorgehen
Taktik der kleinen Schritte
„ Schnelle Bereitstellung erster Versionen mit minimalen Funktionsumfang
„ Aktive Einbindung von UX Team
„ Einholen von Feedback und Erweiterung der Funktionalitäten
„ MVP (Minimum Viable Product) -> MMP (Minimal Marketable Product)
„ Start mit Rumpfportal und einem Service

6. Allgemeiner Architekturansatz
„ Portalanwendung
„ … und n Microserivces

7. Allgemeiner Architekturansatz
Microservices
„ Kapseln von Fachlichkeiten in abgeschlossen Diensten
„ Unabhängig von einander in Sachen
§ … Skalierbarkeit
§ ... Parallele Teams
§ … Release-Erstellung / Deployment
§ … Technologiewahl für die Umsetzung
„ Normalerweise nur Datenlieferanten bzw. reine Businesslogik

8. Allgemeiner Architekturansatz
Microservices
„ Der „klassische“ Ansatz
„ Datenaufbereitung im Service
„ Darstellung und grafische
Aufbereitung durch das Portal

9. Allgemeiner Architekturansatz
Microservices
„ Was wollen wir ?
§ Unabhängige Services mit unabhängigen Zielgruppen
§ Services sollen unabhängig verändert werden können
§ Neue Services kommen hinzu
§ … und alte Services gehen
„ Aber Portal selber soll davon unabhängig sein und eigenen Lebens- und
Entwicklungszyklus haben

10. Allgemeiner Architekturansatz
Microservices
„ Passt hier nicht !
„ UI Anteil im Portal: Neuer Service -> Neues Portal Release L
„ Portal und Services sind nicht
unabhängig und stark gekoppelt
auf der UI-Ebene

11. Allgemeiner Architekturansatz
Microservices
„ Entkopplung auch auf
UI Ebene notwendig

12. Allgemeiner Architekturansatz
Microservices
„ Zusätzlich zur Businesslogik gibt es eine UI Komponente
„ Eigentlich eigene komplette Webanwendungen
„ Microservice -> Self Contained Systems (SCS)
(http://scs-architecture.org)

13. Allgemeiner Architekturansatz
Self Contained Systems
„ Lose Kopplung auf beiden Ebenen: Frontend und Backend
„ Technologiewahl für Frontend und Backend komplett frei
„ Integration auf UI Ebene im Portal

14. Allgemeiner Architekturansatz
Orchestrierung der SCS vom Portal aus
„ Portal muss wissen welche SCS es gibt
„ Lösung: Service Registry
„ Services registrieren sich
„ Portal fragt Registry ab und bekommt
URL zum Abfragen der Metadaten
des Services

15. Allgemeiner Architekturansatz
Speicherung von Daten
„ Im Portal
§ z.B. Usersettings (z.B. Sprache)
„ In den Services (optional)
§ z.B. aufbereitete aggregierte Daten etc.

16. Allgemeiner Architekturansatz
Kommunikation zwischen Portal und SCS
„ Datenaustausch zwischen Portal und SCS ist notwendig (z.B.
Konfigurationsänderungen im Portal mit Auswirkungen auf die SCSs etc.)
„ Idee: Einseitige Kommunikation Portal -> SCS
„ Kommunikation mit dem Service auf 2 Ebenen möglich
§ Portal -> SCS-Backend (REST)
§ Portal -> SCS-Frontend (Javascript und Events)

17. Allgemeiner Architekturansatz
Schnittstellen zwischen Portal und SCS (Backend)
„ Portal ruft Rest-Endpunkt des SCS auf
„ … für die Bereitstellung von Metadaten für das Portal
(Anzahl Widgets, Größenangaben, etc.)

18. Allgemeiner Architekturansatz
Schnittstellen zwischen Portal und SCS (Frontend)
„ Portal kann clientseitige Events an SCS senden
„ rein auf UI Ebene (Javascript Events)
„ z.B. aktuell für JWT Token Propagierung

19. Allgemeiner Architekturansatz
Kommunikation zwischen Portal und Service
„ Bisher nicht benötigt: Kommunikation SCS -> Portal
„ Aber: Zentrale Benachrichtigungskomponente im Portal angedacht
„ ... SCS schickt Meldungen an das Portal für zentrale Anzeige

20. Die Umsetzung
Microsoft Azure als Grundlage

21. Die Umsetzung
Der Technologiestack
„ Auswahl einerseits durch „Vorgaben“ seitens der Zielplattform (Azure)
„ … andererseits aus vorhandenem Know-How aus anderen Projekten
„ ... und etwas Politik
„ Backend: Nodejs (Typescript)
„ Frontend: Angular (Version 5/6)
„ Dokumentbasierter Storage: MongoDB

22. Die Umsetzung
Der MEAN Stack (mean.io)

23. Die Umsetzung
Der MEAN Stack und Azure
„ IaaS vs PaaS ?
„ Empfehlung: Höherer Abstraktionsgrad in den Cloudservices bietet mehr
Features und Integration
„ PaaS -> Azure App-Services (WebApp)
§ HA, Skalierungsoptionen
§ Deploymentslots ...
§ Native Unterstützung verschiedene Technologien
(u.a. nodejs ...)

24. Die Umsetzung
Der MEAN Stack und Azure WebApps
„ Automatisches Deployment von nodejs Anwendungen kompliziert
„ Erster Ansatz: GIT Repo als Austauschschnittstelle mit Azure
§ Source Code GIT -> BuildProzess -> Deployment GIT
„ Update: Mittlerweile auch FTP Zugriff möglich (ZIP File Upload)
„ Anfang des Jahres dann WebApps for Container

25. Die Umsetzung
Der MEAN Stack und Azure WebApps und Docker
„ Mit WebApps for Container einfache dockerbasierte Deployments möglich
„ Austausch via Docker Registry in Azure (oder andere)
„ Pros:
§ NodeJS Laufzeitumgebung direkt in eigener Hand
§ Runtime auch lokal jederzeit exakt reproduzierbar
„ Cons:
§ Pflege der eigenen Runtime (Security Patches etc)
„ Empfehlung: MEAN Apps via Docker deployen

26. Die Umsetzung
Das M aus MEAN und Azure
„ CosmosDB als native Azure Resource im Angebot
§ Multi-Model Database Service
§ u.A. Dokumentenbasiertes Modell via MongoDB-API
„ Passt perfekt zu unseren Anforderungen
und dem Stack
„ Anbindung seitens der Anwendung via Mongoose

27. Die Umsetzung
CosmosDB Erfahrungen
„ CosmosDB != MongoDB
§ Nicht alle Features unterstützt (z.B. Unique constraints)
„ Empfehlung: Automatisierte Tests gegen eine CosmosDB
und nicht lokal gegen eine MongoDB
„ CosmosDB kann in Sachen Performance überraschen
„ Empfehlung: Frühzeitig Lasttests durchführen!

28. Die Umsetzung
Umsetzung der Service Registry
„ Azure API Management im Angebot
„ Mächtiges API Gateway für REST Endpunkte
„ Nur kleines Featureset benutzt
§ Registrierung eines Services / Abfragen von Services
„ Weitere Feature: Authentifizierung/Autorisierung, QoS etc
„ Erfahrungen: Wenig Probleme bereitet, gute Dokumentation

29. Die Umsetzung
Authentifizierung / Autorisierung
„ Azure Active Directory / B2C als zentrales Identitiymanagment
„ OAuth 2.0 basierter Flow mit JWT Tokens
„ SCSs bekommen JWToken vom Portal übermittelt
„ Integration im Backend (nodejs) sehr einfach und problemfrei
§ Node Bilbiothek passport mit extra azure plugin
„ Integration im Frontend (angular) „anspruchsvoller“
§ Bibliothek noch im Preview (API changes etc)
§ Angular Integration sehr neu

30. Die Umsetzung
Integration auf UI Ebene
Ausgangspunkt:
„ Mehrere WebApps (SCSs) sollen
in Form von Widgets
in eine andere WebApp (Portal)
integriert werden

31. Die Umsetzung
Integration auf UI Ebene
Mehrere Ansätze diskutiert:
„ Ansatz 1: Dynamische Komponenten in Angular
„ Ansatz 2: WebComponents
„ Ansatz 3: IFrame

32. Die Umsetzung
Integration auf UI Ebene
„ Ansatz 1: Dynamische Komponenten in Angular
§ Nicht gut dokumentiertes Features von Angular -> Technisch riskant
§ Festlegung auf Angular als Web-Technologie für Portal und alle SCSs
„ Ansatz 2: WebComponents
„ Ansatz 3: IFrame

33. Die Umsetzung
Integration auf UI Ebene
„ Ansatz 1: Dynamische Komponenten in Angular
§ Nicht gut dokumentiertes Features von Angular -> Technisch riskant
§ Festlegung auf Angular als Web-Technologie für Portal und alle SCSs
„ Ansatz 2: WebComponents
„ Ansatz 3: IFrame

34. Die Umsetzung
Integration auf UI Ebene
„ Ansatz 1: Dynamische Komponenten in Angular
„ Ansatz 2: WebComponents
§ Coole neue Technologie
§ Angular Support damals unklar
§ Browserunterstützung fraglich (IE11, Polyfills)
§ Vom Bauchgefühl her: zu früh für den Einsatz
§ ... In einem Festpreisprojekt
„ Ansatz 3: IFrame

35. Die Umsetzung
Integration auf UI Ebene
„ Ansatz 1: Dynamische Komponenten in Angular
„ Ansatz 2: WebComponents
§ Coole neue Technologie
§ Angular Support damals unklar
§ Browserunterstützung fraglich (IE11, Polyfills)
§ Vom Bauchgefühl her: zu früh für den Einsatz
§ ... In einem Festpreisprojekt
„ Ansatz 3: IFrame

36. Die Umsetzung
Integration auf UI Ebene
„ Ansatz 1: Dynamische Komponenten in Angular
„ Ansatz 2: WebComponents
„ Ansatz 3: IFrame
§ „Unsexy und verschrien“
§ Recherchen -> verlässlicher Ansatz
§ POC im Vorhinein gemacht -> konnten alles
damit erfüllen (inkl. Responsivness)
§ Extra Motivation notwendig beim Kunden
§ Bisher so gut wie keine Probleme bereitet !

37. Die Umsetzung
Datenimporte in den SCS
„ Datenbeschaffung / Aufbereitung Aufgabe des SCSs
„ Nächtlich laufende Importjobs angedacht
„ Umsetzung mittels Azure Functions (Servless Architecture)
§ Unterstützt Javascript und C# ... Aber z.B. kein Java
§ Trigger via Cron, aber auch Queue Mechanismen
„ Erfahrungen:
§ Hier und da Ärger gemacht
§ Instabilitäten beobachtet (Abbruch von Functions etc)

38. Die Umsetzung

39. Erfahrungen
Abschließende
Erfahrungen

40. Erfahrungen
MEAN Stack
Backend (node, express, mongoose )
„ Callback basiertes Implementieren (Promises, async/await)
gewöhnungsbedürftig -> Aber im Angular Context schon
Berührungspunkte gehabt
„ Nodejs, Express und Mongoose sehr wenige Probleme bereitet
„ Gefühl: Ökosystem um node nicht auf dem Niveau der JVM Welt
„ Buildprozess selber zu machen (Verwöhnt durch Maven und Co aus der
Javawelt)
„ Aber: In der Zukunft, doch lieber wieder SpringBoot mit Java/Kotlin

41. Erfahrungen
MEAN Stack
Frontend (angular)
„ Buildprozess
§ Nutzung von Angular CLI (keine Auskopplung nach WebPack etc) -> hat
ausgereicht
„ Relativ hohe Lernkurve und fühlt sich nicht leichtgewichtig an
„ RX / Oberveables vs Promises: Beide Pattern genutzt (Teamentscheidung)
„ ... Ansonsten sind UI Themen irgendwie immer aufwendiger als Backend
Themen

42. Erfahrungen
Docker und „Seiteneffekte“
„ Erste positive Erfahrungen mit Docker - Deploymentartefakten
„ Lokale Drittsysteme via Docker schon länger im Einsatz (MongoDB etc)
„ Dockerisierter Buildprozess für CI Pipeline umgesetzt
§ Ziel ein zentraler performanter Jenkins Slave
„ Technische Dokumentation via ASCiiDoc
§ Automatischer Export nach Confluence

43. Erfahrungen
Microsoft Azure
„ Viele Features „frei Haus“ gegenüber on-Premise Lösungen
„ Services von Azure sehr unterschiedlich in Qualität und Umfang
„ Starke Weiterentwicklung der einzelnen Services (Silent Updates) und der
Plattform -> Vieles im Fluss (Schwierig Überblick zu behalten)
„ Hier und da noch enge Bindung an MS Technologien (C# etc.)
„ Stabilitätsprobleme (Docker-Registry)
„ Automatisiertes Aufsetzen kompletter Stages schwierig
„ Relativ schnell komplett abhängig von Cloudplattform

44. Ausblick
„ Bisherige Architekturansatz hat sich bewährt
„ Anpassungen im Detail notwendig (z.B. Datastore Performance) -> Aber
eingeplant (MVP -> MMP)
„ DevOps ist/wird gelebte Kultur
„ Enablen andere Zulieferer für zukünftige SCSs