Das Projekt
meddevo bietet Komplettlösungen für Medizinprodukte z. B. in den Bereichen smarte technische Dokumentation, Audit- und Zulassungsmanagement sowie erweitertes Qualitätsmanagement. Aufgrund der steigenden Anforderungen müssen regulatorische Angelegenheiten neu verwaltet werden. Durch meddevo kann sich der Kunde (wieder) auf die wesentlichen Aspekte seines Geschäfts konzentrieren – es werden Copy-Paste- und andere Fehler bei der Dokumentation und somit Kosten reduziert, und das bei immer strengeren Compliance-Anforderungen.
In einer ersten Version arbeitete meddevo auf einer Single-Server-Cloud-Umgebung und führte Entwicklungen in einer Container-Umgebung auf lokalen Servern aus, um eine sichere und handhabbare Migrationsumgebung und eine Multi-Account-Strategie nach AWS-Best-Practices zu schaffen. kreuzwerker unterstützte meddevo bei der Erstellung einer AWS Landing Zone, um Sicherheit, Compliance und Governance in großem Umfang zu gewährleisten. Darüber hinaus migrierte kreuzwerker die cloudnativen, Microservices-basierten Anwendungen von meddevo in die neue Umgebung.
Die Lösung
In einem eintägigen Workshop analysierten wir zunächst das bestehende Set-up, indem wir uns eingehend mit der Dokumentation beschäftigten und eine lokale Entwicklungsumgebung installierten, um die Kommunikation und das Verhalten der Komponenten zu verstehen. Als Nächstes beschäftigten wir uns mit der Struktur der AWS-Konten, dem Netzwerkaufbau, der Softwarearchitektur und dem Operating Modell.
Um die AWS-Multi-Account-Umgebung von meddevo an bewährte AWS-Muster anpassen, die Einrichtung der Multi-Account-Services automatisieren und präventive Guardrails implementieren zu können, entwarf kreuzwerker eine Landing-Zone-Lösung mit AWS Control Tower in einem neu geschaffenen AWS-Master-Account.
In der Designphase wandte kreuzwerker eine Re-Hosting-Migrationsstrategie (auch Lift-and-Shift) an, um die Microservice-orientierten Anwendungen von meddevo in die AWS-Cloud zu migrieren. Dabei wurden nur wenige Konfigurationen vorgenommen und die Kernarchitektur der Anwendung blieb unverändert. Zudem verfolgten wir einen Defense-in-Depth-Ansatz, bei dem alle verfügbaren Sicherheitsmechanismen auf den verschiedenen Anwendungsebenen genutzt wurden, etwa Security-Gruppen oder VPC-Endpunkte.
Im nächsten Schritt implementierte kreuzwerker die vorgeschlagene Landing-Zone-Lösung mit AWS Control Tower – mit den folgenden Funktionen:
- Einrichtung und Governance der Cloud-Umgebung mit mehreren Konten in AWS
- zentralisierte Mitarbeiter-Identitätsverwaltung und Verbundzugriff auf alle AWS-Konten mit AWS SSO (Single Sign-On) und Office 365 als Identitätsprovider
- zentralisierte CloudTrail- und AWS-Config-Datenerfassung in Amazon S3
- vorkonfigurierte präventive Guardrails zur Gewährleistung von Compliance und Governance
Die Infrastruktur wurde als Code mit wiederverwendbaren Modulen von Terraform und Terragrunt bereitgestellt. Dabei fungierte jedes Modul als Unterprojekt in einem GitLab-Repository. Der Terraform/Terragrunt-Code wurde in mehrere Segmente aufgeteilt, um eine getrennte und unabhängige Bearbeitung der einzelnen Module zu ermöglichen. Auf diese Weise kann meddevo die sich schnell verändernden Infrastrukturressourcen autark verwalten – mit eingeschränkten Berechtigungen und ohne Auswirkungen auf die restliche Infrastruktur. Zudem kann meddevo die Terraform-Zustände aller Child-Accounts zentral in einem einzigen Repository kontrollieren. Im Rahmen der Migration wurde keine zusätzliche Automatisierung, etwa eine Policy-basierte Pipeline für Änderungen, eingeführt, sondern auf einen späteren Zeitpunkt verschoben.
Für die Microservices-basierte, cloudnative Anwendung nutzte kreuzwerker viele AWS Managed Services, sodass die zugrunde liegende Infrastruktur nicht verwaltet werden muss. kreuzwerker stellte die Anwendungen von meddevo in AWS bereit und nutzte dabei die folgenden Ressourcen:
- AWS ECS Fargate zum Hosten von Docker-basierten Backend- und Frontend-Microservices
- verschlüsseltes AWS EFS für skalierbaren Cloudspeicher, auf den mehrere ECS-Services zugreifen
- ECS Service Discovery & Route53 für die Erkennung von Microservices
- interner Application Load Balancer vor dem Frontend und mehrere Backend-Microservices
- ECR-Container-Registry mit automatischem Bereinigungsverfahren für nicht gekennzeichnete Images
- Zugriff auf MongoDB Atlas erfolgt über einen privaten VPC-Endpunkt, damit Datenverkehr über AWS-Netzwerk läuft (nicht über das Internet)
Zusätzlich zu den AWS-Ressourcen wurden von kreuzwerker weitere Dienste von Drittanbietern eingebunden:
- Datadog als externe Logging- und Monitoring-Plattform für einen umfassenden Einblick in die Anwendung und ihre Metriken
- Gitlab CI für kontinuierliche Tests bei jedem Commit und CD für die Bereitstellung von Commits in Entwicklung und Betrieb
Von Anfang an arbeitete kreuzwerker eigenständig an der Migration unter Zuhilfenahme abgestimmter Synchronisations-Wegmarken. So konnten wir den jeweiligen Fortschritt mit den Tech-Team-Leiter’innen von meddevo abstimmen und sie zugleich in die Lage versetzen, den Betrieb nach Projektende eigenständig weiterzuführen. Das Projekt wurde – organisatorisch gesehen – von einem leitenden Ingenieur betreut, wobei häufig und zeitnah Informationen mit den Manager’innen ausgetauscht wurden.
Die Mitarbeiter’innen von kreuzwerker teilten ihr Wissen bei den Wegmarken, auf Screen-sharing-Sitzungen, in Telefonaten, technischen Dokumentationen und in einem abschließenden Übergabe-Workshop. Alle Analyse- und Design-Arbeitsschritte sind in einer Datenbank dokumentiert. Code und Dokumentation werden im meddevo-GitLab-Repository gepflegt.
Inhaltlich gesehen hat kreuzwerker das meddevo-Team mit Best Practices der AWS-Multi-Account-Set-ups vertraut gemacht – anhand von Vorschlägen, Erklärungen und Implementierungen.
Vorteile
meddevo verfügt nun über eine arbeitsfähige, sichere und konforme Multi-Account-Umgebung, die für jedes Konto innerhalb von AWS präventive Guardrails definieren kann. Darüber hinaus wurde die Microservices-basierte Infrastruktur von meddevo in cloudnative AWS-Anwendungen migriert. Durch den modularen Aufbau der Infrastructure-as-Code-Module ist es sehr einfach, diese zu erweitern und – anhand der beliebten Open-Source-Terraform-Module – zu aktualisieren. Durch die zusätzlichen CI/CD-Funktionen von Gitlab kann das Produkt leicht iteriert und können neue Funktionen schnell umgesetzt werden.
Fazit
Die Übernahme der AWS Landing Zone mit AWS Control Tower, das Abrufen von Docker-Images aus dem ECR-Repository von meddevo und die Einrichtung zentraler GitLab CI Commits in Entwicklung und Betrieb waren technische Herausforderungen, die die Teams von kreuzwerker und meddevo gemeinsam gemeistert haben.
Das Team von meddevo kann nun seine bestehenden AWS-Konten registrieren und in die Control-Tower-Umgebung verschieben sowie weitere Anwendungen in die AWS-Cloud migrieren.