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