Downloaden Sie, um offline zu lesen
MEAN SCS in der Cloud
- 1.
- 2. MEAN SCS inder Cloud Von den Anforderungen zur Umsetzung
- 3. Anforderungen „ Kunde istAnbieter 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 funktionaleAnforderungen: „ 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 kleinenSchritte „ 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 „ Kapselnvon 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 „ Waswollen 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 „ Passthier 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 „ Entkopplungauch auf UI Ebene notwendig
- 12. Allgemeiner Architekturansatz Microservices „ Zusätzlichzur Businesslogik gibt es eine UI Komponente „ Eigentlich eigene komplette Webanwendungen „ Microservice -> Self Contained Systems (SCS) (http://scs-architecture.org)
- 13. Allgemeiner Architekturansatz Self ContainedSystems „ 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 derSCS 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 vonDaten „ Im Portal § z.B. Usersettings (z.B. Sprache) „ In den Services (optional) § z.B. aufbereitete aggregierte Daten etc.
- 16. Allgemeiner Architekturansatz Kommunikation zwischenPortal 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 zwischenPortal 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 zwischenPortal 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 zwischenPortal 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 Azureals 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 MEANStack (mean.io)
- 23. Die Umsetzung Der MEANStack 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 MEANStack 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 MEANStack 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 Maus 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 derService 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 aufUI Ebene Ausgangspunkt: „ Mehrere WebApps (SCSs) sollen in Form von Widgets in eine andere WebApp (Portal) integriert werden
- 31. Die Umsetzung Integration aufUI Ebene Mehrere Ansätze diskutiert: „ Ansatz 1: Dynamische Komponenten in Angular „ Ansatz 2: WebComponents „ Ansatz 3: IFrame
- 32. Die Umsetzung Integration aufUI 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 aufUI 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 aufUI 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 aufUI 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 aufUI 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 inden 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.
- 39.
- 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 „ VieleFeatures „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 Architekturansatzhat 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