Die Serie Evolutionäre Architekturen, Teil 3

„Auf zum Mond 🚀“

„Evolutionäre Architekturen“ ist eine vierteilige Blogserie, die zeigt, wie sich Lösungsdesigns und Entscheidungen entwickeln, wenn Unternehmen die verschiedenen Phasen des Lebenszyklus von Startups durchlaufen. In dieser Serie folgen wir dem treffend benannten Example Startup, dessen Idee darin besteht, eine „Fantasy-Aktienmarkt“-Anwendung zu entwickeln, die Fantasy-Sportligen ähnelt. Sie stellen sich vor, im Laufe eines Jahres vier „Turniere“ abzuhalten.

Im zweiten Blog wird beschrieben, wie das Startup mit der Weiterentwicklung seiner technischen Lösungen begann, während sich die Gründer auf die Mittelbeschaffung vorbereiteten. In Teil 3 werden wir erfahren, wie das Beispiel-Startup weitere Fortschritte bei der Optimierung seines Technologie-Stacks macht und sich gut für die Skalierung positioniert.

Effiziente Skalierung durch Umstellung auf eine Microservices-Architektur

Das Team für den Fantasie-Aktienhandel wächst und es werden neue Komponenten und Lösungen entwickelt. Mit der Erweiterung des technischen Portfolios treten bestimmte Lücken auf, die die Aufmerksamkeit des Teams erfordern.

„Alte Gewohnheiten lassen sich nur schwer ablegen“, und das Team beginnt zu erkennen, dass dies Probleme für das Wachstum seines Startups verursachen kann: Die aggressiven Zeitvorgaben und der Enthusiasmus, mit weniger mehr zu erreichen, führen zu steigenden technischen Verbindlichkeiten. Ein Aspekt dieser technischen Verschuldung ist die allmähliche Ausbreitung von Monolithen im Gegensatz zu der Microservice-Architektur, für die sich das Team ursprünglich entschieden hatte. Monolithische Aspekte wie Skalierbarkeit und Leistungsengpässe machen sich beim Testen und bei der Einführung neuer Funktionen bemerkbar. Glücklicherweise erkennt das Team schnell die Herausforderungen, die dieser monolithische Ansatz für die optimale Skalierung der Workloads mit sich bringt. Sie beschließen, einen Schritt zurück zu gehen und ihre Entwicklungspraktiken neu zu bewerten. Einer der Entwickler erinnert sich, dass der AWS Solution Architect (SA) einige dieser Probleme in einem früheren Gespräch vorausgesehen hatte. Das Team des Beispiel-Startups vereinbart einen Anruf mit AWS, um Unterstützung zu erhalten.

Die Auflösung von Monolithen und der Übergang zu einem auf Microservices basierenden Konzept ist ein umfassendes Thema. Daher empfiehlt der AWS SA einen Vertiefungstag zur App-Modernisierung für das Team des Beispiel-Startups. Der Vertiefungstag nutzt einen verwandten Workshop als Hintergrund, wobei der Schwerpunkt auf Workloads liegt, die für Startups relevant sind. Die Veranstaltung wird von fast allen Entwicklern des Unternehmens besucht und ist ein echter Wendepunkt. Im Laufe eines einzigen Tages lernt das Team, wie man Microservices richtig definiert, konzipiert und implementiert. Außerdem lernen sie, wie man eine schrittweise Migration von einer monolithischen Anwendung zu einer Reihe von Microservices durchführt, ohne alles auf einmal überarbeiten zu müssen. Das Team freut sich, dass es seine Fehler frühzeitig erkennt und einige bewährte Methoden kennenlernt, die ihnen künftig helfen werden. Der Lösungsarchitekt stellt auch ein AWS-Whitepaper zur Verfügung, das sich mit Modernisierungsstrategien befasst und Wissenslücken im Team des Beispiel-Startups schließen kann.

Die Erfahrungen mit der App-Modernisierung sind für das Beispiel-Startup so wertvoll, dass das Team beschließt, künftig den gleichen Ansatz zu verfolgen und die vorhandenen bewährten Methoden für verschiedene Funktionsbereiche zu nutzen. Die Techniker und der Produktmanager vereinbaren ein Telefongespräch, um ihre Roadmap für den Rest des Jahres mit AWS zu teilen, um Doppelarbeit zu vermeiden. Das Beispiel-Startup hat bereits eine mutual non-disclosure agreement (MNDA, gegenseitige Geheimhaltungsvereinbarung) mit AWS unterzeichnet und während dieses Gesprächs gab es auf beiden Seiten einen produktiven, freien Ideenaustausch sowie tolle Neuigkeiten: Es stellte sich heraus, dass eine Funktion, die das Beispiel-Startup selbst entwickeln wollte, bereits auf der Roadmap von AWS für das nächste Quartal steht, was dem Team eine Menge Zeit für die Entwicklung spart.

Das nächste Thema auf der Liste der verbesserungsfähigen Bereiche des Beispiel-Startups bezieht sich auf Infrastructure as Code (IaC), kontinuierliche Integration, fortlaufende Bereitstellung (CI/CD) und automatisiertes Testen. Zwei neu eingestellte Entwicklerbetrieb-Mitarbeiter (DevOps) sind mit vielen der aktuellen Betriebsmechanismen beim Startup nicht zufrieden, insbesondere mit Dingen wie dem Erstellen und Testen von Umgebungen sowie der Verwaltung von Code-Artefakten. Ein wachsendes Team beim Beispiel-Startup bedeutet, dass mehr Menschen Zugriff auf diese sensiblen Prozesse haben, was unnötige Risiken mit sich bringt. Die beiden neuen Teammitglieder haben bereits einige Erfahrungen mit Terraform als IaC-Ansatz gesammelt. Sie freuen sich zu erfahren, dass AWS von Terraform gut unterstützt wird, und freuen sich über die Entdeckung anderer Tools wie AWS CloudFormation und AWS CDK, falls eine Alternative benötigt wird. Allerdings benötigen sie noch etwas Hilfe bei der CI/CD-Einrichtung. Ihren Versuchen mangelt es insofern an Kohärenz, und es erweist sich als schwierig, dafür zu sorgen, dass ihr Entwicklungs-Tool gut mit ihrem Bereitstellungstool zusammenarbeitet. Darüber hinaus sind sie noch auf der Suche nach einem geeigneten Ansatz für die Verwaltung ihrer Container-Images. Das AWS-Team empfiehlt AWS CodePipeline, da es ihre Anforderungen an die nahtlose Integration eines Entwicklungs- und eines Bereitstellungstools erfüllt und außerdem automatisierte Tests sowie Unterstützung für verschiedene Umgebungen bietet. Die Verwendung von CodePipeline ermöglicht die Integration mit Lösungen, die nicht unbedingt nativ auf AWS erstellt wurden, sowie eine robuste Unterstützung für andere Tools wie AWS CodeBuild, AWS CodeDeploy und Tools von Drittanbietern. Durch die Implementierung von CodePipeline kann das Beispiel-Startup einen weiteren großen Punkt auf seiner Liste abhaken.

Da das Team auf dem besten Weg zu einer ordnungsgemäßen Implementierung von Microservices ist, fühlt es sich in der Lage, an einigen der anderen komplexen Herausforderungen zu arbeiten, die noch ausstehen. Zum einen wirft das Vorhandensein mehrerer unabhängig voneinander arbeitender Services die Frage nach der Kommunikation zwischen diesen Services auf. Es stellt sich die Frage, ob jeder serviceübergreifende Aufruf synchron oder asynchron erfolgen sollte. Außerdem muss sich das Team überlegen, wie es bewährte Methoden wie Publish/Subscribe (PubSub) Messaging übernehmen kann. Das Team ist sich im Großen und Ganzen darüber im Klaren, dass die Einführung einer ereignisgesteuerten Architektur von Vorteil wäre, insbesondere im Hinblick auf die Abschaffung von Monolithen. Allerdings sind sie mit der Vielzahl der AWS-Services im Zusammenhang mit dieser Architektur ein wenig überfordert, einschließlich aber nicht beschränkt auf Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS) und Amazon Managed Streaming für Apache Kafka (Amazon MSK). Diesmal kann das Team jedoch selbst einige Ressourcen als guten Ausgangspunkt finden, z. B. einige sehr nützliche Workshops und Blogs zum Thema. Das „ereignisgesteuerte“ Konzept wird langsam zu einem weiteren Werkzeug in der Toolbox des Teams.

Entwicklung einer stärkeren Sicherheitsstrategie

Sicherheit stand für unser Startup weiterhin an erster Stelle und Tools wie die AWS Startup Security Baseline (AWS SSB) helfen ihnen beim Einstieg. Leider kann man nie zu viel Sicherheit haben. Die erste Implementierung von AWS WAF war ein guter Anfang, aber das Team muss beginnen, proaktiver über Prävention, Erkennung und Behebung nachzudenken. Diese fangen an, sich in den vielen auf Sicherheit ausgerichteten AWS-Services weiterzubilden, die ihnen bei der Umsetzung einer starken Sicherheitsstrategie helfen können.

Aufgrund des wachsenden Teams und der Einbeziehung von Partnern sind Zugriffssteuerung, Berechtigungen und Governance weitere Themen, denen zunehmend Aufmerksamkeit gewidmet werden muss. Das Team versucht, bewährte Methoden wie das Prinzip der geringsten Berechtigung bei der Anwendung von Berechtigungen umzusetzen. Sie möchten zumindest die produktiven Workloads in ihre eigenen, separaten Konten verschieben. Während das Team diese bewährten Methoden anwendet, nimmt die betriebliche Komplexität aufgrund der zusätzlichen Verwaltungs- und Genehmigungsebenen, mit denen es sich jetzt befassen muss, zu. Es wird schnell klar, dass sie einen mechanisierten Ansatz für die Kontostruktur benötigen. Jemand erwähnt AWS Organizations, was ein Schritt in die richtige Richtung zu sein scheint, also wenden sie sich an ihren vertrauenswürdigen AWS SA für ein Gespräch. Der SA gibt einige wichtige Ratschläge, wie beispielsweise den AWS Control Tower als einfacheren Ansatz für die Verwaltung mehrerer Konten und AWS-Organisationen zu erwägen. Da dies der erste von vielen Schritten zur Umsetzung einer soliden Strategie für mehrere Konten ist, hat der AWS SA dem Team auch den Leitfaden „Umstellung auf mehrere AWS-Konten“ zur Verfügung gestellt. Dieser Leitfaden enthält bewährte Methoden rund um die Kontomigration, Benutzerverwaltung, Netzwerke, Sicherheit und Architektur beim Wechsel zu einer Einrichtung mit mehreren Konten.

Optimieren der Workloads im Hinblick auf die Leistung

Das Team arbeitet an einigen grundlegenden Aufgaben, damit das Startup gut positioniert ist, um im richtigen Tempo zu wachsen. Einige wichtige Punkte sind von der Liste gestrichen und für andere gibt es bereits Handlungspläne. Die Entwickler tun ihr Bestes, um Ihre Workloads für die Leistung zu optimieren, haben aber einige Möglichkeiten für weitere Verbesserungen identifiziert, die über den Code hinausgehen, z. B. Edge-Caching mit Amazon CloudFront, Caching auf Anwendungsebene mit Amazon ElastiCache und Datenbank-Caching. Das Team verlässt sich zunehmend auf AWS Managed Services, um die benötigte Funktionalität zu erhalten und gleichzeitig die damit verbundene betriebliche Komplexität auf ein Minimum zu reduzieren. Ein weiterer verwalteter Service, den einige Entwickler entdecken und überraschend einfach zu verwenden finden, ist AWS Batch. Der anfängliche Ansatz zur Feed-Verarbeitung mit AWS Lambda stößt aufgrund des exponentiellen Anstiegs der zu verarbeitenden Datenmenge an seine Grenzen. Nach einigen Experimenten sind Entwickler in der Lage, einen Weg für die Nutzung von AWS Batch zu finden, der es ihnen ermöglicht, mit relativ geringem Anstieg der Betriebsbelastung und gleichzeitig niedrigen Kosten weiter zu wachsen.

Das Wertversprechen ihres Startups unter Beweis stellen

All diese gute Arbeit des Beispiel-Startups ist nicht zu übersehen. Die agile und dennoch nachhaltige Entwicklung ohne Abhängigkeit von kurzfristigen Lösungen zeigt, dass das Unternehmen langfristig denkt, eine gewisse Reife aufweist und in der Lage ist, Ergebnisse zu liefern. Diese Eigenschaften bilden zusammen mit einer innovativen Lösung und einer guten Marktanpassung des Produkts den Kern des Wertversprechens des Unternehmens. Die Gründer vermitteln den Wert ihres Unternehmens erfolgreich an mehrere Risikokapitalfirmen und schließen ihre erste Finanzierungsrunde der Serie A ab. Das Beispiel-Startup ist auf dem Weg nach oben.

Lesen Sie den ersten und zweiten Blog der Serie „Evolutionäre Architekturen“.