© Excellent backgrounds/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.

Artikelserie

Teil 1: Warum wechseln?

Teil 2: Verwendung von Managed Services

Teil 3: Verwendung von Containern

Teil 4: Going Serverless

Teil 5: Optimierung der Architektur

Teil 6: Sicherheit und Verschlüsselung

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ü...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang