Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Ein Praxisbericht Daniel Bremer-Tonn daniel.bremer-tonn@akquinet.de Mean SCS in der Cloud
MEAN SCS in der Cloud Von den Anforderungen zur Umsetzung
Anforderungen „ Kunde ist Anbieter von medizinischen Geräten „ Aufsammeln und Aufbereitung der Daten „ Jede Menge datenbas...
Anforderungen Zusammengedampfte nicht funktionale Anforderungen: „ Langlebige zentrale Plattform „ Services mit den fachli...
Vorgehen Taktik der kleinen Schritte „ Schnelle Bereitstellung erster Versionen mit minimalen Funktionsumfang „ Aktive Ein...
Allgemeiner Architekturansatz „ Portalanwendung „ … und n Microserivces
Allgemeiner Architekturansatz Microservices „ Kapseln von Fachlichkeiten in abgeschlossen Diensten „ Unabhängig von einand...
Allgemeiner Architekturansatz Microservices „ Der „klassische“ Ansatz „ Datenaufbereitung im Service „ Darstellung und gra...
Allgemeiner Architekturansatz Microservices „ Was wollen wir ? § Unabhängige Services mit unabhängigen Zielgruppen § Servi...
Allgemeiner Architekturansatz Microservices „ Passt hier nicht ! „ UI Anteil im Portal: Neuer Service -> Neues Portal Rele...
Allgemeiner Architekturansatz Microservices „ Entkopplung auch auf UI Ebene notwendig
Allgemeiner Architekturansatz Microservices „ Zusätzlich zur Businesslogik gibt es eine UI Komponente „ Eigentlich eigene ...
Allgemeiner Architekturansatz Self Contained Systems „ Lose Kopplung auf beiden Ebenen: Frontend und Backend „ Technologie...
Allgemeiner Architekturansatz Orchestrierung der SCS vom Portal aus „ Portal muss wissen welche SCS es gibt „ Lösung: Serv...
Allgemeiner Architekturansatz Speicherung von Daten „ Im Portal § z.B. Usersettings (z.B. Sprache) „ In den Services (opti...
Allgemeiner Architekturansatz Kommunikation zwischen Portal und SCS „ Datenaustausch zwischen Portal und SCS ist notwendig...
Allgemeiner Architekturansatz Schnittstellen zwischen Portal und SCS (Backend) „ Portal ruft Rest-Endpunkt des SCS auf „ …...
Allgemeiner Architekturansatz Schnittstellen zwischen Portal und SCS (Frontend) „ Portal kann clientseitige Events an SCS ...
Allgemeiner Architekturansatz Kommunikation zwischen Portal und Service „ Bisher nicht benötigt: Kommunikation SCS -> Port...
Die Umsetzung Microsoft Azure als Grundlage
Die Umsetzung Der Technologiestack „ Auswahl einerseits durch „Vorgaben“ seitens der Zielplattform (Azure) „ … andererseit...
Die Umsetzung Der MEAN Stack (mean.io)
Die Umsetzung Der MEAN Stack und Azure „ IaaS vs PaaS ? „ Empfehlung: Höherer Abstraktionsgrad in den Cloudservices bietet...
Die Umsetzung Der MEAN Stack und Azure WebApps „ Automatisches Deployment von nodejs Anwendungen kompliziert „ Erster Ansa...
Die Umsetzung Der MEAN Stack und Azure WebApps und Docker „ Mit WebApps for Container einfache dockerbasierte Deployments ...
Die Umsetzung Das M aus MEAN und Azure „ CosmosDB als native Azure Resource im Angebot § Multi-Model Database Service § u....
Die Umsetzung CosmosDB Erfahrungen „ CosmosDB != MongoDB § Nicht alle Features unterstützt (z.B. Unique constraints) „ Emp...
Die Umsetzung Umsetzung der Service Registry „ Azure API Management im Angebot „ Mächtiges API Gateway für REST Endpunkte ...
Die Umsetzung Authentifizierung / Autorisierung „ Azure Active Directory / B2C als zentrales Identitiymanagment „ OAuth 2....
Die Umsetzung Integration auf UI Ebene Ausgangspunkt: „ Mehrere WebApps (SCSs) sollen in Form von Widgets in eine andere W...
Die Umsetzung Integration auf UI Ebene Mehrere Ansätze diskutiert: „ Ansatz 1: Dynamische Komponenten in Angular „ Ansatz ...
Die Umsetzung Integration auf UI Ebene „ Ansatz 1: Dynamische Komponenten in Angular § Nicht gut dokumentiertes Features v...
Die Umsetzung Integration auf UI Ebene „ Ansatz 1: Dynamische Komponenten in Angular § Nicht gut dokumentiertes Features v...
Die Umsetzung Integration auf UI Ebene „ Ansatz 1: Dynamische Komponenten in Angular „ Ansatz 2: WebComponents § Coole neu...
Die Umsetzung Integration auf UI Ebene „ Ansatz 1: Dynamische Komponenten in Angular „ Ansatz 2: WebComponents § Coole neu...
Die Umsetzung Integration auf UI Ebene „ Ansatz 1: Dynamische Komponenten in Angular „ Ansatz 2: WebComponents „ Ansatz 3:...
Die Umsetzung Datenimporte in den SCS „ Datenbeschaffung / Aufbereitung Aufgabe des SCSs „ Nächtlich laufende Importjobs a...
Die Umsetzung
Erfahrungen Abschließende Erfahrungen
Erfahrungen MEAN Stack Backend (node, express, mongoose ) „ Callback basiertes Implementieren (Promises, async/await) gewö...
Erfahrungen MEAN Stack Frontend (angular) „ Buildprozess § Nutzung von Angular CLI (keine Auskopplung nach WebPack etc) ->...
Erfahrungen Docker und „Seiteneffekte“ „ Erste positive Erfahrungen mit Docker - Deploymentartefakten „ Lokale Drittsystem...
Erfahrungen Microsoft Azure „ Viele Features „frei Haus“ gegenüber on-Premise Lösungen „ Services von Azure sehr unterschi...
Ausblick „ Bisherige Architekturansatz hat sich bewährt „ Anpassungen im Detail notwendig (z.B. Datastore Performance) -> ...
Upcoming SlideShare
Loading in …5
×

MEAN SCS in der Cloud

37 views

Published on

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.

Published in: Software
no profile picture user

  • Be the first to comment

  • Be the first to like this

MEAN SCS in der Cloud

  1. 1. Ein Praxisbericht Daniel Bremer-Tonn daniel.bremer-tonn@akquinet.de Mean SCS in der Cloud
  2. 2. MEAN SCS in der Cloud Von den Anforderungen zur Umsetzung
  3. 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. 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. 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. 6. Allgemeiner Architekturansatz „ Portalanwendung „ … und n Microserivces
  7. 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. 8. Allgemeiner Architekturansatz Microservices „ Der „klassische“ Ansatz „ Datenaufbereitung im Service „ Darstellung und grafische Aufbereitung durch das Portal
  9. 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. 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. 11. Allgemeiner Architekturansatz Microservices „ Entkopplung auch auf UI Ebene notwendig
  12. 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. 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. 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. 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. 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. 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. 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. 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. 20. Die Umsetzung Microsoft Azure als Grundlage
  21. 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. 22. Die Umsetzung Der MEAN Stack (mean.io)
  23. 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. 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. 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. 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. 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. 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. 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. 30. Die Umsetzung Integration auf UI Ebene Ausgangspunkt: „ Mehrere WebApps (SCSs) sollen in Form von Widgets in eine andere WebApp (Portal) integriert werden
  31. 31. Die Umsetzung Integration auf UI Ebene Mehrere Ansätze diskutiert: „ Ansatz 1: Dynamische Komponenten in Angular „ Ansatz 2: WebComponents „ Ansatz 3: IFrame
  32. 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. 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. 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. 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. 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. 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. 38. Die Umsetzung
  39. 39. Erfahrungen Abschließende Erfahrungen
  40. 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. 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. 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. 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. 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

×