Ich habe eine Website über Serverlos erstellt und wie sie sich auf Frontend-Entwickler bezieht.
Jedes Mal, wenn ich das Wort „serverless“ verwende, was in letzter Zeit einigermaßen regelmäßig vorkommt, da wir in letzter Zeit einige Artikel zu diesem Thema hatten und das Konzept bei CodePen für eine Vielzahl von Dingen nutzen, bekomme ich eine Version von
KOMM SCHON MANN, DU BENUTZT IMMER NOCH „SERVER“.
Und sie liegen nicht falsch. Ja, wenn man Dinge im Web baut, sind immer Server beteiligt. Immer. Ob es sich um einen alten Computer im Keller einer Kirche handelt, einen Computer in einem Rack bei einem großen Hosting-Unternehmen oder „The Cloud“, es ist ein Server.
Ich habe bei den ersten paar Malen, als ich den Begriff hörte, auch die Augen gerollt. Aber jetzt zögere ich, ihn als schlechten Begriff zu bezeichnen, teils weil er sich wirklich durchgesetzt hat und es etwas zu sagen gibt über neue Begriffe, die sich so stark durchsetzen. Teils auch, weil er eine dramatische Veränderung in der Art und Weise signalisiert, wie man Server nutzen kann. Es ist wirtschaftlich anders, DevOps-mäßig anders und in der Art, wie man dafür code schreibt, anders.
Für viele von uns ist uns bewusst, dass ein Server ein Computer ist. Es gibt verschiedene Möglichkeiten, sie zu kaufen, aber man kauft sie. Hier ist etwas Geld, hier ist Ihr Server. Er mag virtuell sein, aber es ist immer noch etwas, wofür Sie verantwortlich sind. Sie installieren Software darauf. Sie starten sie und fahren sie herunter. Sie gleichen sie aus. Sie treffen Entscheidungen darüber, wie viel Speicher und Festplattenspeicher sie haben. Sie sind für die Bereitstellung und Verwaltung zuständig.
Was „serverless“ bedeuten soll, so scheint es mir, ist eine neue Art der Verwaltung und Bezahlung von Servern. Sie kaufen keine einzelnen Server. Sie verwalten sie nicht. Sie skalieren sie nicht. Sie gleichen sie nicht aus. Sie sind nicht wirklich dafür verantwortlich.
Sie bezahlen nur für das, was Sie nutzen. AWS Lambda ist zum Beispiel kostenlos für 1.000.000 Anfragen und kostet danach 0,0000002 US-Dollar pro Anfrage. Billig. Erst diese Woche hat Firebase „Functions“ eingeführt, die im Wesentlichen ein serverloses Konzept sind, und ihr 25-Dollar-Monatsplan bietet 2.000.000 Anfragen (zusammen mit allem anderen, was Firebase bietet).
Das funktioniert nicht für alle Anwendungen. Es funktioniert für Dinge, bei denen man Code schreiben kann, der darauf ausgelegt ist, etwas zu nehmen, etwas zu tun und etwas Neues zurückzugeben. Man schreibt eine API.
Man muss nicht komplett auf die „serverless“-Idee umsteigen. Man kann es und ich stelle mir vor, die meisten Leute *tun* es, für Dinge verwenden, für die es sinnvoll ist, und für den Rest traditionelle Server verwenden.
Ein Marketingbegriff, um Frontend-Entwickler bei dem zu halten, was sie kennen,
Um sie davon abzuhalten, sich für den aktuellen DevOps-Hype verführen zu lassen?
Ich musste lachen, als ein ehemaliger Kunde beschloss, dass der Wechsel von lokalen IBM 720-Serien zu einem „Cloud-basierten“ ERP schneller, flotter und zukunftsweisend sein würde. Ich glaube immer noch nicht, dass sie verstehen, warum das RDP auf ihr Cloud-basiertes ERP, das „GUI“ statt „grüner Bildschirm“ ist, so langsam ist… Es ist alles ein Server, egal wie man es dreht.
Ich kann mir nicht vorstellen, dass die Leute „serverless“ wörtlich nehmen… Tun sie das? Ich meine, natürlich gibt es Server, womit sollen sich die Leute denken, dass ihr Browser sich verbindet? :)
Das Bauen von Dingen mit einer serverlosen Architektur ist sehr lohnend. Nehmen wir zum Beispiel dieses Szenario: Wir haben eine Freigabeseite für Inhalte, die Benutzer erstellen,
share.example.com/abc123. Der naive Ansatz ist einfach. Wir stellen einige Server bereit, lassen sie auf Anfragen anshare.example.com/:short_idreagieren, lassen sieshort_idin der Datenbank nachschlagen und etwas an den Browser zurückgeben.Aber warten Sie… Was passiert, wenn ein Benutzer Inhalte teilt, die viral werden? Was ist, wenn wir 1.000, 10.000 oder 100.000 gleichzeitige Anfragen zu diesen Inhalten haben? Müssen wir unsere Server skalieren, die auf
share.example.com/v1r4lreagieren? Müssen wir unsere Datenbank wegen der steigenden Anzahl von Anfragen skalieren? Müssen wir eine Art von Caching implementieren?Nun, hier ist der serverlose Ansatz. Wir generieren die HTML der Freigabeseite zum *Zeitpunkt der Inhaltserstellung*. Wir legen sie in einen S3 (oder GCP oder Azure Äquivalent) Bucket und servieren sie über eine globale CloudFront (oder GCP oder Azure Äquivalent) Distribution. Wir lesen nur einmal pro Freigabe aus der Datenbank und haben 0 (null!) Server zu warten und zu skalieren. Wenn wir 100.000 gleichzeitige Anfragen erhalten, müssen wir… nichts tun. Es funktioniert einfach.
Serverlose Architektur rockt.
Was Sie beschreiben, scheint Caching zu sein, da das, was Sie von S3 liefern, nur statische Inhalte sind. Um als „serverless“ klassifiziert zu werden, sollte der Dienst benutzerdefinierten Backend-Code ausführen, den Sie geschrieben haben.
Persönlich halte ich den Begriff „serverless“ für schlecht. „Cloud Functions“, wie Firebase sie nennt, ist ein beschreibenderer Begriff.
Statisch generierter Inhalt !== Caching
Aber ja, was ich beschrieben habe (Ausliefern von statisch generiertem Inhalt) ist nicht *technisch* „Serverless Computing“, da kein benutzerdefinierter Code ausgeführt wird, wie Sie richtig bemerkt haben.
Das erinnert mich auch an den Begriff „offline first“, der anfangs etwas nervig sein kann, denn natürlich kann das Web gar nicht funktionieren, wenn keine Art von Netzwerkverbindung hergestellt wird, die „zuerst“ sein muss.
Aber ich denke, der Teil „first“ bezieht sich eher auf die Philosophie. Darauf, die Behandlung eines defekten Netzwerks mit der gleichen oder mehr Aufmerksamkeit zu gestalten als ein funktionierendes.
Auch „die Cloud“ ist als Name seltsam, da die tatsächlichen Dinge, aus denen sie besteht, oft in unterirdischen Anlagen gespeichert werden, die von der natürlichen Kühlung profitieren, da sie sich mehrere Meter unter der Erdoberfläche befinden und Wärme für Häuser über der Erde produzieren, die dem Grundprinzip der Gasdynamik folgt, bei dem heiße Luft nach oben strömt. Wir könnten es auch „der Maulwurf“ nennen, aber ich schätze, es wäre weniger vermarktbar, da es nicht das „Freiheits“-Gefühl vermittelt, das der Himmel hervorruft.
Ein Beispiel für die Verwendung der „serverlosen“ Architektur von AWS Lambda war, als ich für Stamen Design arbeitete. Wir nutzten sie zur Generierung von Webkartenkacheln aus Geodaten. Normalerweise müsste man dafür einen „Tile-Server“ haben, was die Erstellung und Wartung von Servern usw. beinhaltet. Mit Lambda konnten wir Python-Code aufrufen, der die geografischen Daten liest und dann Kacheln (256×256 Pixel Bilder) nach S3 schreibt, die dann an den Client gesendet werden. Wenn die Kachel bereits existiert, wird der Code nicht ausgeführt. Mehr über den Ansatz können Sie hier lesen: https://hi.stamen.com/stamen-aws-lambda-tiler-blog-post-76fc1138a145#.5od5om8tf