Phenquestions
Physische Computer
Wir haben uns von den massiven Servern der Dotcom-Ära weit entfernt. Damals war die Serverinfrastruktur hauptsächlich vor Ort. Ein Unternehmen hat seine Lösungen auf einem physischen Server ausgeführt. Die Leute haben ganze separate Server für verschiedene Zwecke verwendet (Backups, Mailserver, Webserver usw.). Wenn ein bestimmter Server nicht mit den wachsenden Anforderungen des Unternehmens Schritt halten konnte, wurde er durch einen neueren, schnelleren Server ersetzt. Du hast durch bessere Hardware skaliert. Du hast vertikal skaliert.
Hypervisoren
Dann kam die Ära der Hypervisoren. Es hat mit dem Aufkommen von VMWare an Dynamik gewonnen und die Leute haben erkannt, dass sie ein Rack bekommen können, um alle zu beherrschen. Ein Rack zur Ausführung aller verschiedenen Anwendungsfälle und Bereitstellung einer eigenen separaten virtuellen Maschine. Dies führte auch zu Cloud Computing und Unternehmen hörten auf, direkt in Serverhardware zu investieren, und entschieden sich stattdessen dafür, virtuelle Server zu "mieten".
Riesige und teure Rechenzentren wurden von Cloud-Anbietern auf der ganzen Welt verwaltet. Dies machten sich Unternehmen zunutze, indem sie ihre Dienste weltweit zur Verfügung stellten und die größtmögliche Anzahl an Rechenzentren nutzten. Dies geschah hauptsächlich, um Latenzen zu reduzieren, das Kundenerlebnis zu verbessern und einen größeren Markt anzusprechen.
Das hat auch Software-Autoren dazu gebracht, in verteilten Systemen zu denken. Sie haben Software geschrieben, die nicht auf einem einzigen riesigen Computer, sondern auf vielen mittelmäßigen Computern konsistent und zuverlässig läuft reliable. Du hast horizontal skaliert.
Sie können weiterhin vertikal skalieren. Tatsächlich wurde die Bereitstellung von mehr Ressourcen aufgrund der Virtualisierung einfacher. Sie haben die VM heruntergefahren, ihre Ressourcen angepasst und Ihrem Cloud-Anbieter einen kleinen Aufpreis bezahlt. Stück Kuchen.
Die zugrunde liegenden physischen Server sind nicht verschwunden. Cloud-Anbieter sind jetzt für die Verwaltung der Komplexität von Netzwerkschnittstellen, der Betriebssystemkompatibilität und anderer erschreckender Pathologien verantwortlich.
Behälter
Dann kamen die Container. Container waren diese erstaunliche leichte Abstraktion. Eine virtuelle Umgebung mit einem Betriebssystem, das es ermöglicht, Software als einzelne Einheit zu paketieren und bereitzustellen. Wie virtuelle Maschinen lief jeder Container ohne Kenntnis von anderen Containern, aber sie nutzten denselben Betriebssystemkernel.
Dies ermöglichte es den Leuten, Software auf Servern (physisch oder virtuell, egal) auf einer noch höheren Abstraktionsebene bereitzustellen deploy. Sie haben sich nicht um das Produktionsbetriebssystem gekümmert. Solange es Ihre Containerisierungstechnologie unterstützt, würde es Ihre Software ausführen. Außerdem lassen sich Container einfacher einrichten, was die Dienste skalierbarer denn je machte.
Dadurch wurde die Flexibilität verteilter Systeme weiter erhöht. Mit Technologien wie Kubernetes können Sie Legionen von Containern haben, die eine komplexe Reihe von Diensten ausführen. Verteilte Systeme bieten viele Vorteile hohe Verfügbarkeit, Robustheit und die Fähigkeit, sich selbst von einem Knotenausfall zu heilen.
Gleichzeitig sind sie aufgrund ihrer Komplexität auch schwieriger zu entwerfen, bereitzustellen, zu warten, zu überwachen und zu debuggen. Dies widerspricht dem ursprünglichen Trend, die Komplexität aus Ihrer Software zu abstrahieren und diese Verantwortung an Ihren Cloud-Anbieter zu delegieren. Hier kommt die serverlose Architektur ins Spiel.
Serverlos oder Function-as-a-Service (FaaS)
Die Idee von Serverless hat vor allem durch AWS Lambda an Bedeutung gewonnen, und hier werde ich das als Modell verwenden, um über Serverless zu sprechen. Die Prinzipien, auf denen FaaS basiert, sind:
- Sie bezahlen für das, was Sie nutzen
- Sie müssen sich nicht um die Skalierung kümmern
- Sie konzentrieren sich auf Ihren Code, überlassen das Infrastrukturmanagement AWS
Wenn niemand auf Ihre Dienste zugreift, sind die Dienste nicht aktiv. Dies war bei den traditionellen Hosting-Lösungen nicht der Fall, bei denen Sie für einen VPS bezahlen, der immer in Betrieb ist, auch wenn er im Leerlauf lag und nichts Nützlicheres tat, als auf eine neue Anfrage zu hören.
In einer serverlosen Architektur wird Ihr Dienst nicht ausgeführt, es sei denn, jemand möchte ihn tatsächlich verwenden. Wenn eine Anfrage eingeht, wird im Handumdrehen ein Service erstellt, um sie zu bearbeiten.
Wie funktioniert es?
Ihre Funktion (z. B. ein Python-, Go- oder Java-Programm) befindet sich als Datei auf AWS Lambda. Mit dieser Funktion verknüpfen Sie bestimmte Triggerereignisse, wie ein API-Gateway oder ein neues Objekt, das in Ihren S3-Bucket kommt. Und bestimmte Ressourcen wie eine Datenbank oder ein anderer Objektspeicher oder eine EC2-Instanz.
Als Reaktion auf eines der zugehörigen Triggerereignisse erstellt AWS Lambda einen Container mit Ihrer darin enthaltenen Funktion. Die Funktion wird ausgeführt und gibt eine Antwort. Wenn beispielsweise ein neues Image in Ihrem S3-Bucket ankommt, kann AWS Lambda einen Machine-Learning-Code enthalten, der dieses Image analysiert und seine Ausgabe in eine DynamoDB (einen der AWS-Datenspeicherdienste) schreibt.
Sie zahlen nicht für einen ganzen Server, sondern nur für die Menge an Speicher, die Sie Ihrer Funktion zugewiesen haben, die Anzahl der Anfragen, die Sie erhalten und wie lange Ihre Funktion ausgeführt wird.
Darüber hinaus müssen Sie sich keine Gedanken über die Skalierung von Containern als Reaktion auf eine hohe eingehende Arbeitslast machen. Wenn viele Triggerereignisse gleichzeitig auftreten, kümmert sich AWS darum, neue Container zu erstellen und Workloads zwischen ihnen und all den anderen Komplexitäten zu planen.
Keine Komplettlösung
Als virtuelle Maschinen aufkamen, hörten die physischen Server nicht auf zu existieren. Als Container ankamen, haben wir noch VMs verwendet. FaaS ist eine Abstraktion auf höherer Ebene und passt sehr gut zum modernen Design von RESTful-APIs, zustandslosen Diensten und leichten Sprachen wie Node.js oder Python.
Läuft jedoch immer noch auf einem physischen Server (zum Beispiel von AWS verwaltet), lauscht es immer noch auf eingehende Anfragen (Sie zahlen nur nicht direkt dafür) und Sie müssen Daten weiterhin dauerhaft speichern, weshalb es dies getan hat Integrationen für S3, EC2 und andere Dienste. Es ist trotzdem eine nützliche Abstraktion.
