Das Problem
Häufig liefern! Schnell liefern! Sicher liefern! – Dies waren die Ziele der Zusammenarbeit zwischen ZTech, der digitalen Abteilung der Ziegert-Gruppe, einem etablierten Immobilienunternehmen mit mehr als 35 Jahren Erfahrung, und kreuzwerker. ZTech hatte in den letzten Jahren eine Reihe von digitalen Plattformen für die Verwaltung von Immobilienvermögen erfolgreich aufgebaut und war nun bereit für das nächste Level: die Umwandlung der bestehenden Single-Tenant-Systeme in Multi-Tenant-SaaS-Plattformen.
kreuzwerker bietet als Partner optimalen Support und einen hervorragenden Service, um unser Wachstum zu unterstützen. Durch ihre Einführung bewährter Praktiken, die Optimierung der Infrastruktur und die Anwendung ihres Fachwissens konnten sie uns helfen, unser Angebot zu erweitern und Spitzenleistungen zu erzielen. Bruno Jensen, Engineer Manager
Das bestehende Set-up verfügte über perfekte Voraussetzungen: moderne cloud-native, ereignisgesteuerte, serverlose Architekturen, mehrere cross-funktionale Teams, die agil zusammenarbeiten, und eine klare Produktvision. Die Transformation von einer Single-Tenant- zu einer Multi-Tenant-Lösung ist allerdings nicht einfach. Deshalb bat ZTech kreuzwerker um Unterstützung dabei, sich für die Zukunft fit zu machen. Das bedeutete, die technischen Voraussetzungen zu schaffen für eine schnellere, durchsatzstärkere und qualitativ hochwertigere Bereitstellung – um damit die Entwicklungsteams für weiteres Wachstum zu rüsten.
Die Lösung
ZTech- und kreuzwerker-Teams arbeiteten eng zusammen, um verschiedene Maßnahmen in Form von Tools und Prozessen umzusetzen. Das Ergebnis ist eine schnellere, häufigere und sicherere Bereitstellung von Software – dadurch, dass die Automatisierung mit Infrastructure as Code erhöht, das CI/CD-Tooling auf eine effektivere Lösung migriert und die kognitive Belastung reduziert werden konnte. Die Schaffung von Vorbedingungen sowie die Migration vom traditionellen GitFlow-Prozess zu Continuous Deployment ermöglichten häufigere Bereitstellungen. Und schließlich führte die Fokussierung auf die Sicherheit und darauf, die Teams zu befähigen, die volle Verantwortung und eine DevOps-Mentalität zu übernehmen, dazu, die Bereitstellungen sicherer zu machen.
Schnell liefern!
Hindernisse beseitigen durch Automatisierung mit Infrastructure as Code
Ein Faktor, der eine hohe Durchlaufzeit d.h. der Zeit zwischen des Commits des Codes und dessen tatsächlichem Einsatz verursachte, war die Tatsache, dass häufig manuelle Änderungen an den AWS-Infrastrukturkomponenten erforderlich waren. Eine vollständige Automatisierung ist bei der Einführung eines neuen Produkts oft nicht geboten – es kann sich als unnötiger Aufwand erweisen, wenn sich der Featureumfang häufig ändert. Ab einem bestimmten Punkt werden das System und seine Abhängigkeiten jedoch so komplex, dass eine korrekte Umsetzung sehr zeitaufwendig ist. Dies gilt besonders für serverlose Architekturen, bei denen Infrastrukturkomponenten wie Queues, Streams und Datenbanken einen zentralen Teil der Anwendungslogik ausmachen. Denn Änderungen am Anwendungscode ziehen dann häufig eine Synchronisierung mit dem Infrastrukturcode nach sich – und umgekehrt.
Um den gewünschten Automatisierungsgrad zu erreichen, wurde Infrastructure as Code mit dem AWS Cloud Development Kit (CDK) und TypeScript eingeführt. Nachdem mit dem AWS Resource Manager ein Inventar aller vorhandenen Ressourcen erstellt worden war, konnten diese entweder in bestehende Stacks importiert oder von Grund auf neu erstellt und mit entsprechenden Migrations- und Cutover-Prozessen in Produktion gebracht werden. Der Infrastrukturcode wurde in die Code-Repositories der Anwendung aufgenommen und die Verwaltung des gesamten Lebenszyklus der Ressourcen wurde in die Build- und Deploymentpipelines der Anwendung integriert. Anschließend konnten alle Änderungen synchronisiert und wiederholbar, sicher und zuverlässig eingeführt werden – inklusive der Möglichkeit aller Beteiligten, Änderungen häufig und kleinteilig vorzunehmen.
Warum AWS CDK als Infrastructure-as-Code-Tool?
Wenn es um Infrastructure-as-Code-Tools geht, gibt es mehrere brauchbare Alternativen, z. B. Terraform, Pulumi, AWS CDK oder AWS CloudFormation. Die Wahl von AWS CDK als bestes Tool für diese Aufgabe erwies sich im Fall von ZTech aus folgenden Gründen als recht naheliegend:
- Einfache Einführung: Sowohl die React-Frontends als auch die Node.js-Backends wurden mit TypeScript implementiert, auf dem AWS CDK ebenfalls basiert. So konnten sich alle Entwickler:innen schnell einarbeiten und sich von Anfang an wohlfühlen.
- Reduzierung der Komplexität: Eines der wichtigsten bereits vorhandenen Frameworks war das Serverless Framework, das AWS CloudFormation verwendet. Da AWS CDK ein natives AWS-Tool ist, das sich auf AWS CloudFormation stützt, konnte die Zahl der zu verwaltenden Tools auf ein Minimum reduziert werden.
- Unterstützung einer sicheren und stabilen Infrastruktur: Die Teams arbeiteten autonom und cross-funktional und deckten den gesamten Lebenszyklus der Anwendung ab, ohne auf eine spezielle Plattform- oder ein DevOps-Team angewiesen zu sein. Da AWS CDK viele Bausteine mit sinnvollen Vorgaben bereitstellt, können Entwickler:innen problemlos und sicher komplexe AWS-Infrastrukturkomponenten unter Einhaltung der Best Practices erstellen.
- Gewährleistung langfristiger Wartbarkeit und Stabilität: Je komplexer die Infrastruktur-Set-ups werden, desto wichtiger ist es, sie wie jedes andere Stück Software zu behandeln. Dies ist mit AWS CDK möglich, da die Infrastruktur programmgesteuert beschrieben werden kann und über integrierte Testautomatisierungsfunktionen verfügt.
Steigerung der Entwicklungsleistung durch Ersetzen von CI/CD-Tools
Eine weitere unnötige Verzögerung verursachten die für die Build- und Deploymentpipelines verwendeten Tools – AWS CodeBuild und AWS CodePipeline. Die integrierten AWS-Services sind zwar gut geeignet für kleine Teams, die gerade mit AWS starten, aber für größere Teams mit fortgeschrittenen Prozessen nicht die beste Wahl.
Daher schlug kreuzwerker vor, auf das native CI/CD-Angebot des bereits verwendeten Versionskontrollsystems umzusteigen – in diesem Fall GitHub und GitHub Actions. Dieses bietet einen breiteren Funktionsumfang und fügte sich nahtlos in den Entwicklungs-Workflow der Teams ein. Dadurch wurde die Zahl von Kontextwechseln verringert und die Entwicklungsleistung erhöht. Im ersten Migrationsschritt stellten die kreuzwerker die Pipeline eines Dienstes als Proof-of-Concept um. Dies wurde in den Teams präsentiert, Fragen und Bedenken wurden diskutiert und mögliche Hindernisse beseitigt. Im Ergebnis waren die Teams von den Vorteilen überzeugt und in einer gemeinsamen Aktion wurden alle Pipelines erfolgreich auf GitHub Actions umgestellt, d. h. sie arbeiteten nun flexibler und schneller.
Verringerung der kognitiven Arbeitsbelastung durch weniger komplexen Code
Der letzte wichtige Schritt zur schnelleren Bereitstellung bestand darin, die Gesamtkomplexität so weit wie möglich zu reduzieren, um die kognitive Arbeitsbelastung der Teams zu verringern und es künftigen Entwickler:innen zu erleichtern, Änderungen umzusetzen. Dazu wurden einerseits das Architekturkonzept als solches und andererseits die Implementierungen der einzelnen Dienste gründlich analysiert. Die Überprüfung der Serverless-Expert:innen von kreuzwerker ergab, dass das gewählte Architekturkonzept den zu lösenden Geschäftsproblemen tatsächlich sehr gut entsprach. Daher wurde es nicht grundlegend verändert; allerdings ergab die Analyse, dass einige Komponenten auf niedriger Ebene vereinfacht werden konnten.
Warum ist Serverless eine gute Lösung?
- Serverless als Architekturansatz ist perfekt für asynchrone, ereignisgesteuerte Anwendungsfälle. Im Fall von ZTech passte der Ansatz gut, da kritische Anwendungsworkflows verschiedene, teilweise von Drittanbietern stammende Systeme miteinander verbanden und die asynchrone, ereignisgesteuerte Implementierung mit Amazon DynamoDB Streams, Amazon S3 Event Notifications, Amazon SQS und Amazon SNS eine belastbare Implementierung ermöglichte.
- Serverless als Function-As-A Service (FaaS), z. B. AWS Lambda, bringt viele Vorteile in Bezug auf Kosten, Skalierung und Leistung mit sich. Nachdem der allgemeine Datenverkehr und die Nutzungsmuster gründlich analysiert wurden, sprachen das Pay-by-Usage-Modell, die automatische Skalierung nach Bedarf und die integrierte Hochverfügbarkeit für die Wahl dieses Ansatzes.
- Serverless im Sinne von “transparente Server” ermöglicht es Entwickler:innen, sich auf ihre eigentliche Arbeit zu konzentrieren, anstatt Zeit mit nicht wertschöpfenden Aufgaben wie der Wartung der Infrastruktur, der Behebung vermeidbarer Sicherheitsprobleme oder der Durchführung von Back-up-Prozessen zu verbringen. Dies kann mit verwalteten Services wie AWS Fargate oder Amazon Aurora Serverless umgesetzt werden – ein oft gewählter Standard.
Die Mitarbeiter:innen von kreuzwerker nutzten ihr Wissen über die vorhandenen Frameworks sowie ihre langjährigen AWS- und Serverless-Erfahrungen, um die Teams dabei zu unterstützen, benutzerdefinierte Implementierungen durch Out-of-the-box-Lösungen zu ersetzen, veraltete Teile der Codebasis zu identifizieren und zu entfernen und mehr native Funktionen zu nutzen – im Ergebnis führte all dies zu einem besser wartbaren Code.
Häufig liefern!
Probleme schnell lösen durch bessere Überwachung
Nachdem eine der wichtigsten Voraussetzungen – die Automatisierung – vollzogen war, musste nur noch die Überwachung verbessert werden, um die Bereitstellungsfrequenz drastisch erhöhen zu können. Ein gutes Überwachungs-Set-up ist für die Aufrechterhaltung einer niedrigen mittleren Wiederherstellungszeit (MTTR) entscheidend, vor allem dann, wenn jeder Commit direkt für die Produktion freigegeben wird. Alle Anwendungen verfügten bereits über Logs, Metriken und Tracing. Doch ein Hauptproblem blieb bestehen: Produktionsfehler wurden häufig erst nach sorgfältiger manueller Überprüfung nach einer Freigabe aufgedeckt, was bei häufigeren Bereitstellungen nicht mehr leistbar war. Zudem war damit zu rechnen, dass es bei höherer Bereitstellungsfrequenz auch mehr Produktionsfehler geben würde. Um eine zügige Problemlösung zu gewährleisten, musste die Ursachenanalyse bei Produktionsproblemen verbessert werden.
Damit Ausfälle automatisch erkannt und gemeldet werden, definierten und implementierten kreuzwerker und ZTech gemeinsam Amazon CloudWatch-Alarme auf der Basis von technischen und geschäftlichen KPIs. Diese wurden in Microsoft Teams integriert, sodass Entwickler:innen auf Abruf in Notfällen sofort benachrichtigt werden. Um die Ursachenanalyse zu erleichtern, wurden Dashboards auf der Grundlage von standardisierten und benutzerdefinierten Metriken erstellt und die Logerfassung wurde standardisiert. Zudem konnten störende Fehlalarme durch sorgfältige Überprüfung und Anpassung von Fehlerszenarien erheblich reduziert werden. Durch die durchgeführten Maßnahmen waren alle Beteiligten in der Lage, das Tempo von Bereitstellungen zu erhöhen.
Einführung von Continuous Deployment
Nachdem alle genannten Maßnahmen erfolgreich durchgeführt worden waren, wurden die Anwendungen vom bisherigen GitFlow-Prozess auf Continuous Deployment umgestellt. Technisch gesehen bedeutete dies, den Main Branch zu löschen, den Develop Branch zum Standardbranch zu machen und die Deploymentpipeline so anzupassen, nach erfolgreicher Staging-Bereitstellung direkt nach Produktion ausgeliefert wird…
Sicher liefern!
Durch einen “Shift Left” Produktionsausfälle gering halten
Mit dem nun deutlich erhöhten Tempo wuchs auch die Möglichkeit von Sicherheitsrisiken. Obwohl Automatisierung, Überwachung und Vereinfachung bereits dazu beitrugen, Risiken zu mindern, wurden zusätzliche Maßnahmen ergriffen, um auf der sicheren Seite zu sein. Eine dieser Maßnahmen bestand in der Einführung von “Shift Left” bezüglich der Sicherheit. Um den Anteil fehlgeschlagener Änderungen gering zu halten, sollten Fehler so früh wie möglich und nicht erst in der Produktion gefunden werden. Dies ist besonders bei sicherheitsrelevanten Problemen wichtig. “Shift Left” umfasste mehrere Maßnahmen: So macht es die Einrichtung von Guardrails nahezu unmöglich, unsichere Operationen durchzuführen; durch die Bereitstellung von AWS CDK-Blueprints mit sinnvollen Vorgaben und Referenzimplementierungen für IAM-Richtlinien nach dem Prinzip der geringsten Berechtigung wird es erschwert, von bewährten Verfahren abzuweichen; und die Erweiterung der Build- und Deploymntpipelines mit automatischen Sicherheitswarnungen und -aktualisierungen mithilfe der Dependabot-Funktion von GitHub Action macht es sehr einfach, immer die Nase vorn zu haben.
Langlebigkeit durch gestärktes Vertrauen
Last but not least ist die sichere Auslieferung auch eine Frage des Vertrauens in die Fähigkeiten sowohl des Teams als auch des Systems. Dies kann schwieriger sein als erwartet, wenn die Teammitglieder mit einem unbekannten Technologie-Stack konfrontiert sind und bei den ersten Entscheidungen nicht involviert waren. Um das diesbezügliche Vertrauen in allen beteiligten Teams zu stärken und so die Grundlage für zukünftiges Wachstum zu schaffen, investierte kreuzwerker stark in Wissensaustausch und Enablement.
Mehrere Aktivitäten wurden eingeführt – z. B. interaktive Brown-Bag-Sessions und eine DevOps-Rotation – um theoretisches Wissen mit praktischer Erfahrung zu verbinden. Am wichtigsten war jedoch die fortlaufende enge Zusammenarbeit: kreuzwerker-Berater:innen waren in die ZTech-Entwicklungsteams integriert, sie initiierten und nahmen an Mob- und Pair-Programming-Sitzungen teil und standen jederzeit für On-Demand-Mentoring-Sitzungen und individuelles Coaching zur Verfügung. Mit der Zeit wurden die Teams selbstbewusster und kreuzwerker zog sich zurück. An ihre Stelle traten die Entwickler:innen von ZTech, die nun als Multiplikator:innen für Themen wie DevOps-Mentalität, spezifische technische Details der verwendeten Services und AWS-Best-Practices fungieren konnten.
Das Ergebnis
Mit den Tools, die wir jetzt – vor allem dank kreuzwerker – implementiert haben, wird es uns möglich sein, Geschwindigkeit, Durchsatz und Qualität zu verbessern. Jonathan Hansen, Head of Engineering & Agile
Die Kombination aller Maßnahmen – u. a. der erhöhte Grad der Automatisierung, die optimierte Produktivität der Entwickler:innen und das gesteigerte Vertrauen in das System – machen ZTech fit für die Zukunft: Die Teams sind nun in der Lage, qualitativ hochwertige Software in einem hohen Tempo für die ehrgeizige Produkt-Roadmap und für kommende technische Herausforderungen zu liefern. Die enge Zusammenarbeit zwischen ZTech und kreuzwerker hat die Teams befähigt, ihren bestehenden Serverless-Stack auf AWS, die eingeführten DevOps-Tools und die neu etablierten Prozesse zu nutzen und zu erweitern. Damit sind die Teams bei ZTech bestens darauf vorbereitet, in den kommenden Jahren häufig, schnell und sicher zu liefern.