Der Amazon Simple Storage Service (S3) wurde 2006 auf den Markt gebracht. Ich erinnere mich noch gut daran, weil ich Teil des Teams war, das einen Konkurrenzspeicherdienst namens Nirvanix entwickelte, der damals im Stealth-Modus lief. Das war lange, bevor der Begriff „Cloud“ in aller Munde war. Amazon definierte S3 als „Internet Storage” oder „Web-Scale Storage“.
15 Jahre später muss ich zugeben, dass sich der Aufwand, den Amazon mit S3 betrieben hat, ausgezahlt hat, denn AWS hat Amazon allein 2020 einen Umsatz von 45 Milliarden Dollar und Gewinne in Höhe von 13,5 Milliarden Dollar beschert! Ich würde zwar nicht so weit gehen zu behaupten, dass dies ausschließlich auf Objektspeicher zurückzuführen ist, doch Objektspeicher war tatsächlich der Grundstein oder zumindest ein wichtiger Baustein der Cloud-Strategie. Doch warum?
Disruptive Innovation verändert per Definition den Status quo
Rückblickend war die Markteinführung von AWS ein brillanter Schachzug von Amazon, doch waren dafür erhebliche Anstrengungen und Ressourcen und der entsprechende Weitblick erforderlich. Damals nutzte die IT-Welt überwiegend Speicher über POSIX-konforme Speicherprotokolle wie NFS oder CIFS/SMB, doch S3 (und andere Speicherdienste wie Nirvanix) waren anders. Bei dem verwendeten RESTful Interface mussten Entwickler ihre Anwendungen über die Anwendungsschnittstelle (API) direkt mit einem bestimmten Speicherdienst koppeln. Jeder Speicherdienst hatte seine eigene API mit einigen speziellen Funktionen. Bestimmte Konzepte waren jedoch einheitlich, z. B. die Nutzung von Metadaten, die Key-Value-Adressierung und Standardbefehle wie Schreiben, Lesen und Löschen.
Dieser Ansatz war völlig anders, und die Speicheranbieter taten damals ihr Bestes, um eine Storage-as-a-Service-Schnittstelle zu standardisieren, allerdings war der Markt dafür zu schnelllebig. Zum damaligen Zeitpunkt hätte jede Standardisierung die Innovation gehemmt. Aus AWS-Perspektive ermöglichte die Tatsache, dass die S3 API (auch als S3-Protokoll bezeichnet) von Amazon kontrolliert wurde, dem Internetgiganten, die API kontinuierlich weiterzuentwickeln, um die veränderlichen Marktanforderungen mit immer neuen Diensten zu bedienen. Zurzeit umfasst das AWS-Portfolio gut 60 Dienste.
Warum hat Amazon überhaupt mit Objektspeicher angefangen?
Sowohl B2C- als auch B2B-Internetdienste entwickeln sich so schnell, dass man sich kaum noch an die Zeit erinnern kann, als es manche davon noch nicht gab. Im Jahr 2006 war YouTube noch ein Wackelkandidat, der gerade seine ersten Schritte versuchte und häufig offline war. Später im Jahr kam Twitter heraus, und wenn man versuchte, diesen Dienst zu nutzen, bekam man häufig den „Fail Whale“ angezeigt (erinnern Sie sich noch an den Fail Whale?). Den Streamingdienst Netflix gab es noch gar nicht, er wurde erst 2007 auf den Markt gebracht.
Was ich damit sagen will: Damals, im Jahr 2006, war für uns alle eine einzelne Anwendung mit lokalem Speicher noch die Norm. Man kaufte seine Software auf einer CD im Laden, um sie dann zu Hause auf dem PC zu installieren. Festplattenausfälle waren an der Tagesordnung, und NAS und Enterprise-Speichersysteme waren teuer und schwierig zu warten und zu erweitern. Es gab zwar Online-Speicherdienste (für Privat- und Unternehmenskunden), allerdings waren sie langsam, teuer und häufig unzuverlässig.
Kurz gesagt: Speicher waren zwar eine Notwendigkeit, wenngleich eine lästige, und der Wert eines Internetdienstes lag im Frontend und in den Inhalten. Speicher wirklich zuverlässig zu machen, war zeit- und arbeitsaufwendig. So sah der Markt aus, als Amazon mit S3 einen Service herausbrachte, der versprach, sich um Bulk Storage zu kümmern, sodass Kunden sich auf die Verbesserung ihrer primären Anwendung kümmern konnten. Damit sprach dieser Service vor allem Entwickler und Organisationen ohne eigene Speicherfachleute oder Storage Architects an. Außerdem erschien das Risiko aus Entwicklersicht eher gering. Schließlich handelte es sich bei den in S3 gespeicherten Daten häufig um sekundäre Kopien, die wiederhergestellt werden konnten oder latenztolerant waren. Das heißt, sie konnten innerhalb von Stunden oder Tagen aus dem Backup wiederbeschafft werden, ohne dass dies größere Probleme verursachte. Der einzige Knackpunkt: Man musste S3 über die S3 API in seine Anwendung integrieren.
Das S3-Protokoll: Wie Amazon seine Dienste in Warp-Geschwindigkeit versetzte
Wie bringt ein Unternehmen also solch eine disruptive Technologie auf den Markt? Vor allem eine, bei der sich IT-Manager und Speicheradministratoren von liebgewonnenen Gewohnheiten verabschieden müssen?
Zunächst muss sich der Mehrwert höher als der Aufwand sein. Dann muss man für die Innovatoren und Early Adopter so viele Hürden wie möglich aus dem Weg räumen. Diese Strategie hat Amazon brillant umgesetzt. Man fokussierte sich auf Entwickler, die Amazon S3 kostenlos (oder fast kostenlos) ausgaben, und setze damit eine massive globale Outreach-Kampagne in Gang, die sich auf bestimmte technische Nutzergruppen in allen wichtigen Weltregionen konzentrierte. Diese wurde von der kontinuierlichen Weiterentwicklung der an die Developer Community gerichteten Ressourcen (z. B. Training und Sample Code) und der ständigen Verbesserung von Amazon AWS begleitet. Anfangs setzte man auf einen eher basisorientierten Ansatz. Nachdem Amazon in der Webservice-Welt Fuß gefasst hatte, arbeitete man sich zu den Unternehmen vor.
Dabei gab es eine ganze Reihe von Ereignissen auf dem Weltmarkt, die der Einführung der AWS-Dienste zu Gute kamen, z. B. Breitband, die Verbreitung mobiler Geräte, die Akzeptanz von Diensten/Subskriptionen und schließlich auch noch die Coronapandemie. Wenn man sich jedoch ansieht, womit AWS überhaupt erst begann, erkennt man, dass die Nutzer als Allererstes an RESTful Interfaces gewöhnt werden mussten, in diesem Fall an die S3 API. Nachdem Amazon dies erreicht hatte, konnte AWS immer neue Services einführen, vorausgesetzt, diese waren nützlich und zuverlässig.
Die S3 API von Amazon als Schnittstelle für Objektspeicher
Einer der Gründe dafür, dass Amazon mit S3 so erfolgreich war, ist die Resilienz und Skalierbarkeit des zugrunde liegenden Objektspeicherkonzepts. Hierzu ist ein „puristischer“ Ansatz vonnöten, das heißt, die API muss alle Daten bis hin zum Speichergerät beim Schreiben und Adressieren als Objekt behandeln. Aufgrund des Erfolgs des S3-Service hat sich das Protokoll de facto zur Norm für die Integration in jedes Storage-as-a-Service-Ziel (Service oder Gerät) entwickelt. Ich sage bewusst „de facto“, weil es keine echte Norm ist. Amazon ist Besitzer der Definition und Spezifikation, versteht jedoch den Wert einer breiten Akzeptanz und überlässt daher der Branche sein Produkt zur Nutzung.
Aufgrund seiner Popularität integrieren Software-, Service- und Speicheranbieter das S3-Protokoll zum Senden und/oder Empfangen von Daten in ihre Produkte. Aus Speicher- und Serviceperspektive kommt es, falls am anderen Ende keine Objektspeicherlösung steht, an irgendeinem Punkt zwangsläufig zu Problemen mit der Skalierbarkeit. Würde Amazon lediglich eine RESTful Interface zusätzlich zu NAS nutzen, hätte das Unternehmen S3 nicht im jetzigen Ausmaß verbreiten können.
Darum muss man bei der Bewertung von Objektspeicherlösungen über das Protokoll hinaussehen und verstehen, wie Daten auf der Festplatte gespeichert und geschützt werden. Dieses Thema haben wir kürzlich in einem Webinar behandelt, doch der Punkt ist, dass es einen Unterschied zwischen einer Schnittstelle und der zugrunde liegenden Architektur gibt.
Die Einführung der Cloud
Auch wenn Amazon zurzeit der beliebteste Cloud Service Provider ist, gab und gibt es viele Dienste und Lösungen, die den Cloud-Markt zu dem gemacht haben, der er heute ist.
Dabei sehe ich den Begriff „Cloud“ eigentlich als Marketingkonzept – als Marketingmensch sei mir dies erlaubt. Hinter jedem Internetdienst gibt es jemanden, der im Hintergrund die entsprechende Infrastruktur verwaltet. Das Gute daran ist: Weil Amazon dazu beigetragen hat, S3 de facto als Norm zu etablieren und die IT-Branche (Anbieter und Nutzer) mit RESTful Interfaces vertraut zu machen, steht ein Großteil dieser Technologie heute allen zur Verfügung. Sie können einige der Vorteile der Cloud nutzen, die Daten jedoch sicher in Ihrem Rechenzentrum halten (z. B. mit DataCore Swarm) oder einen Service Provider wählen, der Ihren individuellen Anforderungen entspricht (z. B. BT Cloud Storage oder Wasabi).
Kontaktieren Sie uns, um mehr zu erfahren.
