Amazons Technologie-Transformation

Mit der richtigen Architektur zu mehr Geschwindigkeit

Werner Vogels

© Shutterstock / YIUCHEUNG

Eine in die Tage gekommene Anwendungslandschaft modernisieren – vor dieser Herausforderung stehen viele Unternehmen. So auch Amazon, das vor etwa 20 Jahren die technologischen Weichenstellungen getroffen hat, die sie zu einem der größten Cloud-Anbieter der heutigen Zeit gemacht haben. Amazon CTO Werner Vogels beschreibt die Etappen auf dem Weg dahin.

Innovation spielte für Amazon schon immer eine besondere Rolle. Vor etwa 20 Jahren allerdings durchlief das Unternehmen eine besonders radikale Transformation. Wir wollten den ständigen Kreislauf aus „Erfinden, Anbieten und Neu-Erfinden“ beschleunigen. Im Vergleich zu heute hatte Amazon nur einen Bruchteil der Kunden. Dennoch stand fest, dass eine grundlegend neue Anwendungsarchitektur nötig sein würde, um das Produkt- und Dienstleistungsportfolio zu erweitern.

Die riesige, monolithische Anwendungsbibliothek und die große Datenbank für den Betrieb der Webseite Amazon.com schränkten die Geschwindigkeit und Agilität ein. Immer wenn ein Feature oder ein neues Angebot für Kunden hinzugefügt wurde – beispielsweise Video-Streaming –, musste umfangreicher Code neu geschrieben werden. Der Prozess war langwierig und umständlich. Er erforderte die Koordination verschiedener Abteilungen und erschwerte es, Innovationen rasch voranzutreiben.

Eine Blaupause für den Wandel stellte das „Distributed Computing Manifest“ dar – ein internes Dokument, das einen neuen Architekturansatz beschrieb. Auf dieser Basis wurde anschließend die Umstrukturierung der Anwendung in kleinere „Services“ angegangen. Die neue Strategie trug entscheidend zum weiteren Wachstum von Amazon bei. Dafür hat Amazon seine funktionalen Hierarchien aufgelöst und die Organisation in kleine, eigenständige Teams umstrukturiert. Jedes von ihnen wurde mit einem bestimmten Produkt, einer konkreten Dienstleistung oder einem definierten Funktionsumfang von Anwendungen betraut. So wurden Entwickler zu Product Ownern, die schnell Entscheidungen treffen konnten.

Die Aufgliederung der Organisations- und Anwendungsstrukturen hat sich als richtig erwiesen. Das Unternehmen konnte viel schneller agieren und war insgesamt innovativer. Die Anzahl an Feature-Implementierungen pro Jahr stieg von ein paar Dutzend auf mehrere Millionen. Noch viel einschneidender war allerdings, dass der Erfolg beim Aufbau einer hochskalierbaren Infrastruktur letztendlich zur Entwicklung neuer Kompetenzen beitrug und 2006 schließlich zur Gründung von AWS führte.

Wie AWS müssen viele Unternehmen ihre Agilität erhöhen, um wettbewerbsfähig zu bleiben. Einige Kunden haben aus diesem Grund zu einer modernen Anwendungsentwicklung mit verschiedenen Komponenten oder Microservices gewechselt und sich von einer monolithischen Architektur verabschiedet.

Um erfolgreich Anwendungen zu entwickeln und ihre Agilität und Innovationsgeschwindigkeit zu erhöhen, müssen Unternehmen fünf Aspekte berücksichtigen: Microservices, speziell entwickelte Datenbanken, automatisierte Software-Release-Pipelines, ein serverloses Betriebsmodell und automatisierte, kontinuierliche Sicherheit.

API Confernce 2020
Milecia McGregor

The 3 Axes of Scaling APIs

Milecia McGregor (Flipped Coding)

 

Software Architecture Summit 2020
Lars Röwekamp

Serverless

mit Lars Röwekamp (OPEN KNOWLEDGE)

Microservices als architektonisches Muster

Die meisten Unternehmen entscheiden sich zunächst für eine monolithische Anwendung, da sich ein solches System am schnellsten und einfachsten entwickeln lässt. Der Nachteil: Prozesse können nur schwer zu einem einzigen Dienst gebündelt werden. Wenn ein Anwendungsprozess permanent zu Lastspitzen führt, muss die gesamte Architektur umständlich skaliert werden.

Darüber hinaus ist es kompliziert, mit wachsender Codebasis neue Funktionen hinzuzufügen und bestehende zu verbessern. Bei monolithischen Architekturen steigt das Risiko eines Ausfalls, da sich bei vielen voneinander abhängigen und eng gekoppelten Prozessen ein einzelner Prozessausfall stärker auf das Gesamtsystem auswirkt.

Bei einer Microservices-Architektur gliedert sich eine einzige Anwendung in mehrere, voneinander unabhängige Komponenten, die als Service ausgeführt werden. Services sind dabei jeweils für klar abgegrenzte Geschäftsfunktionen konzipiert. Ein Beispiel dafür ist der Warenkorb bei einem Online-Shop. Der entsprechende Service läuft unabhängig von anderen Diensten und wird von einem einzigen Entwicklerteam verwaltet. Dadurch lässt er sich unkompliziert aktualisieren, bereitstellen und skalieren. Ein Online-Shop kann also zusätzliche Warenkörbe unterstützen, wenn die Nachfrage besonders hoch ist, etwa bei größeren Rabatt-Aktionen.

Wenn Unternehmen von einer monolithischen Architektur zu Microservices wechseln, wollen Entwickler häufig im gleichen Schritt Abhängigkeiten innerhalb eines Dienstes über eine Pipeline verwalten. Dafür müssen sie neue Wege finden, Anwendungen zu bündeln und Code auszuführen. Aufgrund dieser Innovationen sind Instanzen nicht mehr die einzige Berechnungsoption.

Dafür lassen sich Container oder AWS-Lambda-Funktionen verwenden. Container sind eine beliebte Möglichkeit, um Anwendungen zu bündeln und so ein hervorragendes Werkzeug zur Modernisierung von Legacy-Anwendungen. Schließlich bieten sie Portabilität und Flexibilität. Für Entwickler ist Lambda die einfachste Lösung, da nur die Geschäftslogik in Code gefasst werden muss.

Ferner ist es wichtig, dass bei Microservices eine Möglichkeit für die Kommunikation untereinander gefunden wird. Viele Anwendungen verwenden dafür weiterhin API-Verbindungen. Es gibt jedoch noch andere Wege, Daten zwischen Diensten zu verschicken, beispielsweise Streaming für die Echtzeit-Datenverarbeitung. Hinzu kommen Maßnahmen zur Auslösung von Reaktionen auf Datenänderungen, Servicenetze für die Kommunikation und die Überwachung auf Anwendungsebene. Entwickler können dabei die Integrationsmethode wählen, die ihren Anforderungen am besten entspricht.

Datenmanagement mit speziell entwickelten Datenbanken 

Moderne Anwendungen bestehen aus voneinander unabhängigen Datenspeichern. Statt eine einzige Datenbank zu verwenden, werden Datenbank und Microservice Eins-zu-Eins-abgebildet. Die Abkehr von einer traditionellen Anwendungsarchitektur ist dabei ein wichtiger Schritt in Richtung Zukunft. Monolithische Anwendungen dagegen führen mit zunehmendem Wachstum zu großen Problemen in den Bereichen Skalierung und Fehlertoleranz. Außerdem wächst die Datenbank, die zugleich einen Single Point of Failure darstellt. Mit einer einzigen Datenbank ist es zusätzlich schwierig, die spezifischen Anforderungen verschiedener Microservices zu erfüllen. Durch die Entkopplung von Daten und Microservices dagegen können Entwickler selbst die Datenbank auswählen, die am besten zu den eigenen Bedürfnissen passt.

Für viele Anwendungen wäre die beste Wahl immer noch eine relationale Datenbank. Das gilt jedoch nicht in jedem Fall. Werden beispielsweise Anwendungen ausgeführt, die mit hochgradig verbundenen Datensätzen arbeiten – etwa Produktempfehlungen bei einem Online-Shop –, so eignet sich dafür eher eine Diagrammdatenbank wie Amazon Neptune, die Verknüpfungen enthält und durchsuchbar ist.

Benötigen die Anwendungen Echtzeitzugriff auf Daten, ist eine In-Memory-Datenbank die beste Wahl. In diesem Kontext eignet sich die Datenbank Amazon ElastiCache, die häufig für Spiele- und IoT-Anwendungen verwendet wird.

Software-Lieferung: Automatisierte Release-Pipelines

Mit der Abkehr von der monolithischen Architektur hin zu kleinen, agilen und voneinander unabhängigen Teams beendete Amazon die Verwendung einer einzigen Release-Pipeline. Die Prozesse rund um die Erstellung und Bereitstellung von Updates wurden somit vereinfacht. Allerdings führte die Dezentralisierung der Entwicklungsprozesse zu einer Reihe neuer Herausforderungen. Die Aufrechterhaltung des Entwicklungsprozesses und der Qualitätskonsistenz über alle Teams hinweg wurde schwierig, besonders weil jeder Schritt des Entwicklungsprozesses manuell war und die Fehleranfälligkeit dadurch stieg.

Die Lösung des Problems bestand in einer stärkeren Standardisierung und einer größeren Automatisierung. Als erstes hat AWS den Softwarebereitstellungsprozess mit Best-Practice-Vorlagen definiert. Sie stellen einen Standard für die Modellierung und Bereitstellung aller Infrastrukturressourcen in einer Cloud-Umgebung dar. Diese Vorlagen, die sich als „Infrastruktur as Code“ beschreiben lassen, helfen, Projekte optimal zu starten. Sie stellen den gesamten Technology Stack für eine Anwendung in Form von Code und nicht durch einen manuellen Prozess bereit. So ist sichergestellt, dass die Teams ihre Prozesse und die Implementierungen entsprechend den Anforderungen von AWS konfigurieren.

Zweitens werden durch die Automatisierung manuelle Prozesse aus dem Workflow der Softwarebereitstellung entfernt. Mit automatisierten Entwicklungsprozessen testet und veröffentlicht AWS eine Menge Code und minimiert gleichzeitig die Fehlerquote. Durch kontinuierliche Integration führen die Teams ihre Code-Änderungen regelmäßig in einem zentralen Repository zusammen. Anschließend werden automatisiert Builds erstellt und Tests durchgeführt, um Probleme frühzeitig zu erkennen. Über eine kontinuierliche Bereitstellung werden mehrmals täglich Änderungen eingepflegt, die ohne menschliches Eingreifen an die Produktion weitergeleitet werden. AWS hat viel Zeit in das Schreiben der richtigen Tests und Fail-Safes investiert. Das Ergebnis: höhere Geschwindigkeit, mehr Agilität, qualitativ besseren Code.

Betriebsmodell: So wenig Server-basiert wie möglich

Moderne Lösungen bestehen aus vielen Komponenten. Sie setzen sich nicht nur aus einer einzigen Anwendung und Datenbank zusammen, sondern aus Tausenden von Diensten, die jeweils über eine eigene, speziell konzipierte Datenbank verfügen. So kann ein Team kontinuierlich neue Funktionen entwickeln.

Die Komponenten lassen sich in zwei Kategorien einteilen:

  • Aktivitäten, die das Unternehmen am Markt erfolgreich machen. Dazu zählen beispielsweise Prozesse rund um die Benutzererfahrung und die Entwicklung innovativer Produkte.
  • Aufgaben, die erledigt werden müssen, aber keinen Wettbewerbsvorteil bieten. Für die meisten Unternehmen sind das Prozesse rund um Servermanagement, Lastausgleich und das Anwenden von Sicherheits-Patches.

Bei AWS-Lambda handelt es sich um einen Dienst, mit dem Code serverlos ausgeführt werden kann. Dadurch können Kunden bestimmte Aufgaben an AWS abgeben – ein entscheidender Vorteil des Angebots. Unternehmen können sich so auf andere Aktivitäten, wie beispielsweise Produktinnovationen, konzentrieren.

Ein serverloses Konzept umfasst also Dienste, die ohne Infrastrukturbereitstellung und Skalierung auskommen, über integrierte Verfügbarkeits- und Sicherheitsfunktionen verfügen und ein Pay-for-Value-Abrechnungsmodell verwenden. Dabei gilt es festzuhalten, dass nicht nur Lambda serverlos ist, sondern der gesamte Application Stack.

Application Stacks bestehen in der Regel aus drei Komponenten:

  • einem Rechendienst wie AWS Fargate zur Ausführung der Anwendungslogik,
  • Datenspeichern wie MySQL, relationale PostgreSQL-Datenbanken oder Amazon Aurora, um die Daten abzulegen,
  • einer Integrationsschicht wie eine Event-Bus-Netzwerkarchitektur Amazon-EventBridge, um die Daten zu verschieben.

Amazon selbst arbeitet allerdings nicht zu 100 Prozent serverlos – auch wenn die derzeitigen Erkenntnisse klar für eine Abkehr von Servern sprechen. Das gilt auch für viele Kunden des Unternehmens. Aller Voraussicht nach werden zukünftige Entwicklergenerationen gänzlich ohne Server arbeiten und sich nur noch auf Geschäftslogiken konzentrieren. Der Grund für diese Entwicklung ist einfach: Die Verwendung von serverlosen Primäranwendungen für Berechnungen, Datenverarbeitung und Integrationen ermöglicht es Unternehmen, durch die Cloud immer agiler zu werden – unabhängig davon, ob neue netzbasierte Anwendungen entwickelt oder ältere Lösungen migriert werden.

Sicherheit: Alle Beteiligten sind verantwortlich

In der Vergangenheit haben Unternehmen zunächst die Anwendung selbst erstellt und sich anschließend um das Thema Sicherheit gekümmert. Bei kontinuierlichen Release-Zyklen funktioniert dieser Ansatz allerdings nicht. Deshalb wurden oft Firewalls um die gesamte Anwendung gezogen. Das bringt allerdings eine Reihe neuer Herausforderungen mit sich. So ist es problematisch, wenn die gleichen Sicherheitseinstellungen auf jedes Einzelprogramm der Anwendung übertragen werden. Eine Applikation mit unabhängigen Microservices benötigt möglicherweise individuelle Einstellungen.

Aus diesem Grund werden in modernen Anwendungen Sicherheitsfunktionen in jede Komponente der Applikation integriert und bei jedem Release automatisch getestet und bereitgestellt. Das bedeutet, dass die Sicherheit nicht mehr in der alleinigen Verantwortung der Sicherheitsexperten liegt. Vielmehr sind Technik-, Operation- und Compliance-Teams involviert, die über den gesamten Entwicklungslebenszyklus kontinuierlich an dem Sicherheitscode arbeiten.

Der Sicherheitscode ist bei AWS in Tools wie Code-Repositorys, Build-Management-Programmen und Bereitstellungs-Werkzeugen integriert. Er wird sowohl beim Entwicklungszyklus selbst als auch auf der Software ausgeführt. Mit serverlosen Diensten ist der Sicherheitsstatus einfach aufrechtzuerhalten, da die zugrunde liegende Infrastruktursicherheit in jeden Dienst integriert ist. Dazu gehören Updates von Betriebssystemversionen, Software-Patching und die Überwachung.

Ausblick

Es existiert für Unternehmen kein Königsweg für die Modernisierung von Anwendungen. Allerdings gibt es einige bewährte Verfahren, wie auch der Ansatz, für den sich Amazon selbst entschieden hat.

Zugunsten eines größeren Innovationsgrads fasste Amazon den Entschluss, die monolithische Anwendung sowie die Organisation neu zu strukturieren und durch cloudbasierte, automatisierte Prozesse zu optimieren. Einige Kunden, wie Yelp, haben einen ähnlichen Weg eingeschlagen.

„Lift and Shift“ lautet der Ansatz für Kunden, die eine On-Premises-Anwendung in die Cloud verlagern möchten. Diese nutzen anschließend Managed Services in der Cloud und geben Aufgaben wie Datenbank- und API-Management an AWS ab, um sich auf die eigene Geschäftslogik zu konzentrieren.

Alle Kunden, die moderne Anwendungen entwickeln, haben eines gemeinsam: Sie profitieren in ihrem gesamten Unternehmen besonders von optimaler Zuweisung von Zeit und Ressourcen. Sie können sich verstärkt mit der Logik, die ihr Geschäft definiert, auseinandersetzen und Systeme so skalieren, dass sie Nachfragespitzen leicht bewältigen können. Zusätzlich lässt sich mit modernen Anwendungen die Agilität erhöhen und eine größere Anzahl neuer Funktionen integrieren.

So hat beispielsweise Edmunds.com, ein Portal für Autokäufer, die Zeit für die Einführung neuer Website-Funktionen von sechs Monaten auf eine Woche reduziert. Auch das Startup Bynder hat die Zeit bis zur Markteinführung seiner Produkte von einem Jahr auf einen Monat verkürzt. Unternehmen können also durch die Änderung der Art und Weise, wie sie mit Technologien umgehen, ihre Geschäftsabläufe verbessern.

Geschrieben von
Werner Vogels
Werner Vogels
Werner Vogels ist Chief Technology Officer (CTO) und Vizepräsident von Amazon.com. Werner bloggt unter https://www.allthingsdistributed.com.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: