© Enkel/Shutterstock.com
Teil 4: Going Serverless

Migration nach AWS


Im dritten Teil dieser Serie haben wir unsere monolithische Anwendung durch die Zerlegung in verteilte Microservices wartbarer gemacht. Das ermöglicht es uns, diese unabhängig voneinander zu skalieren. Der Einsatz von verwalteten Services wie dem Application Load Balancer (ALB) [1], dem Amazon Relational Database Service (RDS) [2], Amazon ElastiCache [3] und Containern, die in AWS Fargate [4] laufen, hat uns bereits erhebliche Vorteile in Bezug auf den Betrieb, die Wartung und die Skalierbarkeit der Anwendung gebracht. Wir haben ebenfalls aufgezeigt, wie durch die Verwendung von asynchroner Kommunikation zwischen den einzelnen Microservices die Ausfallsicherheit erhöht werden kann.

In diesem Artikel möchten wir prüfen, ob unser DevOps-Team nicht noch weitere Verantwortlichkeiten in Bezug auf den Betrieb und die Wartung der Anwendung abgeben kann. Unser Team soll möglichst viel Zeit mit der Entwicklung neuer Funktionalitäten verbringen, anstatt Infrastruktur zu managen, zu skalieren und zu patchen. Einen weiteren Aspekt von serverlosen Architekturen möchten wir uns zunutze machen. Anstatt für provisionierte Ressourcen zu zahlen, die wir gegebenenfalls nicht vollständig nutzen, wünschen wir uns eine nutzungsbasierte Abrechnung. Diese macht es einfacher, die Kosten auf einen Geschäftsprozess umzulegen und die Rentabilität eines Service zu ermitteln. Wird die Infrastruktur nicht genutzt, möchten wir möglichst nichts dafür bezahlen.

Führen wir uns zur Erinnerung unsere aktuelle Architektur noch einmal vor Augen, bevor wir sie weiter optimieren (Abb. 1).

mueller_aws_4_1.tif_fmt1.jpgAbb. 1: Die aktuelle Architektur unserer containerisierten Anwendung

API-Management und Deployments – warum das Rad neu erfinden?

Starten wir an der Schnittstelle zu unseren Kunden – unserem API. In unserer aktuellen Implementierung nutzen wir Spring Boot, um unser API zu implementieren, und veröffentlichen Letzteres hinter einem Application Load Balancer. Jede Zeile Code, die wir schreiben, ist auch gleichzeitig eine Verpflichtung und bringt Verantwortlichkeiten mit sich. Damit stehen wir in der Verantwortung, dieses API zu managen, zu patchen, zu versionieren, hochverfügbar zu gestalten, zu skalieren und mittels des Load Balancer unter einem fixen URL bereitzustellen. Um diese Verantwortlichkeiten für unser Team weiter zu reduzieren, nutzen wir zukünftig das Amazon API Gateway [5], um unser API zu veröffentlichen. Das Amazon API Gateway ist ein vollständig verwalteter Service, der uns erlaubt, unser API deklarativ zu beschreiben und unsere Endpunkte mit diversen Compute Resources zu verbinden. Das können traditionelle Anwendungen im Rechenzentrum sein, virtuelle Maschinen in der Cloud, Container oder auch nur einzelne Funktionen, die nur die auszuführende Businesslogik beinhalten (Abb. 2). Für die deklarative Beschreibung des API können wir unter anderem die OpenAPI-Spezifikation (vormals Swagger) nutzen.

mueller_aws_4_2.tif_fmt1.jpgAbb. 2: Unterschiedliche Integrationsoptionen des Amazon API Gateway

Bei unserem Ansatz haben wir bisher Aspekte wie feingranulares Zugriffsmanagement, Drosselung von Anfragen basierend auf Nutzungsplänen, Monetarisierung des Service, Caching im API-Layer oder das Tracing von Anfragen außer Acht gelassen. In einer realen Anwendung sind diese jedoch durchaus relevant: Amazon API Gateway macht es uns sehr einfach, diese Aspekte – wenn notwendig – zum gegebenen Zeitpunkt per Konfiguration hinzuzunehmen. Für unsere Anwendung entscheiden wir uns, AWS X-Ray [6] zu nutzen, um Tracinginformationen in unserer Anwendung aufzuzeichnen. Das hilft uns, ein besseres Verständnis dafür zu bekommen, wie Anfragen in unserer Anwendung verarbeitet werden, wie viel Zeit wir in den Verarbeitungsschritten benötigen, wo Fehler aufgetreten sind und welche Kunden betroffen waren. Wir gehen später detaillierter auf das Thema Monitoring ein.

Für das Zugriffsmanagement unterstützt das Amazon API Gateway zahlreiche Verfahren. Neben der Bereitstellung öffentlicher APIs, die frei zugänglich sind und keine Authentifizierung erfordern, können wir ein Amazon API Gateway auch so bereitstellen, dass es nur von einer ausgewählten Amazon Virtual Private C...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang