Wenn man genug Zeit in der IT-Branche verbringt, erkennt man die Zyklen in den Gesprächen. Eine neue Sache wird vorgeschlagen, alle sind begeistert; jemand weist darauf hin, dass die neue Sache noch nicht alles kann, alle werden desillusioniert; die Leute finden heraus, wofür die neue Sache gut ist - und wofür nicht - und die Diskussion geht weiter zur nächsten neuen Sache.
Im Moment haben wir serverlose Architekturen in der Tonne.
Der Anstifter der aktuellen Runde der Serverless-Kritik ist David Heinemeier Hansson, besser bekannt als DHH, der durch Basecamp bekannt wurde. DHH veröffentlichte eine Polemik mit dem Titel Selbst Amazon kann mit Serverless oder Microservices nichts anfangenveröffentlicht, in der er eine Fallstudie des Amazon Prime Video-Teams über dessen Infrastruktur zitiert.
Der Bericht geht ausführlich auf die internen Aspekte des Prime Video-Dienstes ein. DHH zitiert eine Passage über harte Grenzen der Skalierung, aber diese Notiz hier war für mich am informativsten:
Die beiden kostenintensivsten Vorgänge waren der Orchestrierungsworkflow und die Datenübertragung zwischen verteilten Komponenten. Deshalb haben wir alle Komponenten in einen einzigen Prozess verlagert, um die Datenübertragung innerhalb des Prozessspeichers zu halten, was auch die Orchestrierungslogik vereinfachte.
DHH
Die Sache ist die: Wie Adrian Cockroft (bekannt durch Netflix) feststellte, wurde in dem ursprünglichen Bericht das serverlose Modell nicht in Frage gestellt. Alles, was das Amazon-Team sagte, war, dass der Dienst und ihr Verständnis davon gereift war und sich ihre Bedürfnisse geändert hatten:
Wenn man erforscht, wie man etwas konstruieren kann, ist die Erstellung eines Prototyps in ein paar Tagen oder Wochen ein guter Ansatz. Dann versuchten sie, ihn zu skalieren, um den hohen Datenverkehr zu bewältigen, und entdeckten, dass einige der Zustandsübergänge in ihren Step-Funktionen zu häufig waren und sie einige übermäßig geschwätzige Aufrufe zwischen AWS-Lambda-Funktionen und S3 hatten. Sie konnten den Großteil ihres Arbeitscodes wiederverwenden, indem sie ihn zu einem einzigen, lange laufenden Microservice kombinierten [...]
Adrian Cockroft
Wenn Sie mit dem Aufbau eines neuen Dienstes beginnen, kennen Sie definitionsgemäß weder seine internen Leistungsmerkmale noch die Lastmuster, denen er von den Benutzern ausgesetzt sein wird. Daher ist es eine gute Idee, sich auf die Seite der Vorsicht und der größeren Flexibilität zu schlagen. Das war schließlich das ursprüngliche Versprechen der Cloud, das sie mit Nachdruck eingelöst hat. Während der ursprüngliche Dot-Com-Boom von vielversprechenden Start-ups verlangte, Millionen von Dollar an Investitionskapital für den Kauf von Server-Hardware, Softwarelizenzen, Colo-Raum usw. auszugeben, bevor sie überhaupt mit der Entwicklung ihres geplanten Dienstes beginnen konnten, kann man im Cloud-Zeitalter mit einer Kreditkarte loslegen. Es geht auch viel schneller: Der Aufbau der Infrastruktur, der früher Wochen oder Monate dauerte und bei dem Experten rund um die Uhr im Einsatz waren, geschieht jetzt automatisch in wenigen Minuten.
Serverless ist einfach der nächste Schritt in dieser Entwicklung. Die Cloud ist viel flexibler als der Besitz eigener Hardware, aber ihr traditionelles Preismodell ist immer noch starr und verlangt von den Nutzern, ihren Bedarf im Voraus zu schätzen, und die Skalierung ist möglicherweise nicht so reaktionsschnell oder granular, wie Sie es sich wünschen. Wenn Ihr Anbieter nur T-Shirt-Größen anbietet und Sie zwischen einer kleinen und einer mittleren Größe liegen, aber vielleicht eine große benötigen, wenn die Dinge gut laufen, müssen Sie möglicherweise einige schwierige Entscheidungen treffen. Serverless verspricht stattdessen, dass Ihr Dienst von Null bis zu einer beliebigen Größe skaliert werden kann und dass Sie nach Bedarf bezahlen können.
Hier kommen die Vorbehalte ins Spiel: Viele Dinge, die behaupten, serverlos zu sein... sind es nicht. Echte serverlose Dienste skalieren auf Null: Wenn niemand Ihren Dienst nutzt, zahlen Sie nichts. Das ist eine wichtige Garantie, wenn Sie einen neuen Dienst starten: Wenn die Nutzer Ihren Dienst noch nicht nutzen, haben Sie keine Einnahmen. Zu wissen, dass Ihre Kosten in diesem Szenario ebenfalls gleich null sind, gibt Ihnen die Gewissheit, dass Sie nicht für eine Menge Kapazität aufkommen müssen, die Sie nicht nutzen.
Die Kehrseite der Medaille ist, dass die rein verbrauchsabhängige Preisgestaltung für serverlose Dienste bis ins Unendliche skaliert - es gibt also einen Übergangspunkt, an dem es sinnvoller ist, sich auf eine bestimmte Kapazitätsmenge festzulegen, als das Pay-as-you-go-Modell beizubehalten. Diese finanzielle Flexibilität geht auch auf Kosten der architektonischen Komplexität, die ebenfalls eine Rolle dabei spielt, wo der Übergangspunkt für jede Service-Architektur liegt.
Das ist alles, was dem Team von Amazon Prime Video passiert ist: Sie haben den Übergangspunkt erreicht und festgestellt, dass sie die Kosten für diese extreme Flexibilität nicht mehr tragen müssen. Da es sich um ein Unternehmen von Amazon handelt, fielen vermutlich keine direkten Kosten an, wie es bei einem externen AWS-Kunden der Fall wäre, obwohl es wahrscheinlich eine sichere Annahme ist, dass Amazon diese Kapazität auf ziemlich granulare Weise berücksichtigt. Was das Team jedoch in seinem Bericht beschreibt, sind die Kosten, die ihnen durch die Komplexität der Architektur und die Leistung des Dienstes entstehen. Nachdem sie sich die Zeit genommen haben, die spezifischen Anforderungen ihres Dienstes zu verstehen, müssen sie diesen Preis nicht mehr zahlen: Sie haben ihre Architektur vereinfacht und eine bessere Leistung erzielt, indem sie die spezifischen Pfade, die sie benötigen, fest verdrahtet haben.
Das Wichtigste ist jedoch, dass wir hier das Endstadium des Prozesses sehen. Hätten die Architekten von Amazon Prime Video all dies ohne die Flexibilität einer verteilten Architektur erarbeiten müssen, wären sie vielleicht nie an diesen Punkt gelangt. Stattdessen waren sie in der Lage, ihren Dienst schnell auf die Beine zu stellen, ihn als Reaktion auf die sich entwickelnden Nutzungsmuster rasch zu verfeinern, und jetzt, da sich die Änderungsrate auf ein überschaubares Maß abgekühlt hat, haben sie ihre architektonischen Anforderungen im Lichte ihres hart erarbeiteten Know-hows überprüft.
So sollten die Dinge gemacht werden. Diese Geschichte ist kein Versagen von Serverless; dafür ist es buchstäblich da!
SnapLogic ermöglicht etwas sehr Ähnliches, mit einer zusätzlichen Besonderheit: Sie können alles mit allem verbinden, und jeder kann sich daran beteiligen. Domänenexperten können die Vorteile unserer grafischen Low-Code/No-Code-Schnittstelle nutzen, um Daten- und Anwendungsintegrationen zu entwerfen, ohne Programmierkenntnisse zu benötigen. Wenn sich die Integration durchsetzt und populär wird, kann sie von Experten überarbeitet werden, um Leistungsengpässe zu beseitigen, Doppelarbeit zu vermeiden und die Einhaltung von Vorschriften sicherzustellen. Das ist allerdings eine hohe Hürde für ein Projekt in der Anfangsphase, wenn der Schwerpunkt darauf liegt, den Menschen den Einstieg zu ermöglichen und die benötigten Funktionen zu entwickeln.
In diesem Sinne kann SnapLogic auch mit allen Arten von serverlosen Diensten integriert und zu einem einheitlichen Ganzen zusammengefügt werden. Bei unserem Geschäfts- und Technologieansatz geht es darum, mit den Architekturen unserer Nutzer zu arbeiten, ohne ihnen etwas vorzuschreiben oder sie in ihren Entscheidungen einzuschränken. Deshalb arbeiten wir sowohl mit On-Premises- als auch mit Cloud-Infrastrukturen, ob selbst verwaltet oder als Service bereitgestellt - oder sogar vollständig serverlos für maximale Flexibilität.
Der Vorteil von Serverless-Architekturen und Low-Code-/No-Code-Entwicklung für das Unternehmen besteht darin, dass ein neues Projekt leichter auf den Weg gebracht werden kann. Wenn Sie in der Anfangsphase zu viel Wert auf architektonische Reinheit legen, werden Sie nie etwas zustande bringen. Umgekehrt sollten Sie, sobald Sie eine gute Vorstellung davon haben, was Sie tun müssen, unbedingt darauf aufbauen und das Gelernte einbeziehen. Amazon scheint auf dieser Grundlage gut zurechtzukommen. Wir sollten alle von ihrem Beispiel lernen.
