Ein Intro zu Amazon Fargate: Was es ist, warum es fantastisch ist (und nicht) und wann es verwendet werden soll.

Als Amazon Ende 2017 Fargate auf der AWS re: Invent (zusammen mit EKS) ankündigte, fiel es wirklich unter das Radar. Keiner der Blogs oder Influencer, denen ich damals folgte, sprach wirklich darüber, außer etwas in der Art von:

Oh ja, und es gibt diese neue Sache, mit der ECS-Benutzer Container direkt in der Cloud ausführen können.

Als Entwickler hat mich das wirklich umgehauen. Mal sehen warum.

Der Produktivitätsboom

Ich habe das Gefühl, dass es in der Welt der Softwareentwicklung fünf große Revolutionen gegeben hat, die die Produktivität und die Fähigkeit der Entwickler, Anwendungen auf Produktionsebene mit maximaler Effizienz zu schreiben und bereitzustellen, dramatisch gesteigert haben.

Sie alle lösten auch wichtige Probleme. Hier ist meine Aufschlüsselung der Revolutionen und der Probleme, die sie gelöst haben:

  • Entstehung von Cloud Services (IaaS)

    Infrastrukturkosten und Skalierbarkeit

  • Open Source Community, Konferenzen, Workshops, Tech Blogs, Stack Overflow und so weiter

    Eingeschränkter Zugang zu Wissen

  • Versionierungssysteme, Tools für die Zusammenarbeit, Tools für die kontinuierliche Integration

    Concurrent EngineeringSystems Diskrepanz und Integration Hölle

  • Containerisierte Architektur

    Schwierigkeiten beim Erstellen von Anwendungen in inkonsistenten Umgebungen

  • Serverless Computing Services (PaaS)

    Server- und Systemadministration

Jede dieser Revolutionen hat ein gemeinsames Merkmal: Sie alle geben Softwareentwicklern mehr Kontrolle. Sie tun dies, indem sie bewährte Verfahren und die gemeinsame Nutzung von Code in einem kollaborativen Workflow fördern und den Bedarf an teuren dedizierten Servern, Systemadministratoren, DevOps, IT-Support usw. verringern.

Großartig, aber warte - wo ist Fargate in all dem?

Ihr Schiff ist das Problem

Als Docker Container in die Massen brachte, wurde dies schnell zu einem neuen Standard in der Entwicklung und wurde weithin übernommen.

Kurz darauf und nach dem Erfolg von Kubernetes startete AWS einen eigenen (grundlegenderen) Containerverwaltungsdienst: Amazon Elastic Container Service (ECS). Es wurde das Konzept der Aufgaben eingeführt.

Eine Aufgabe kann eine beliebige Instanz von Containern sein, die zusammenarbeiten. Von einer Webanwendung, auf der ein Webserver, mehrere Mikrodienste, eine Datenbank und ein Reverse-Proxy ausgeführt werden, bis zu einer Liste von Shell-Skriptstapeln, die regelmäßig ausgeführt werden.

Als früher Anwender von ECS hat es mir sehr gut gefallen und es hat eine Weile großartig funktioniert. Schließlich wurde es jedoch immer komplizierter , diese zusätzlichen Ebenen (Aufgaben und Container) anstelle von nur EC2-Instanzen verwalten zu müssen.

Ich war auch mit seiner Sicherheit nicht zufrieden . Je mehr Schichten Sie in Ihrem Stapel haben, desto wachsamer müssen Sie sein. Jede dieser Schichten führt zu mehr Komplexität und einer erhöhten Wahrscheinlichkeit von Sicherheitsfehlkonfigurationen und Sicherheitslücken.

In der Tat werden Ihre Container mit ECS in EC2-Containerinstanzen in einem Cluster ausgeführt , den Sie für die automatische Skalierung konfigurieren. Jede Instanz kann mehrere verschiedene Aufgaben hosten. Jede Aufgabe kann mehrere Container ausführen.

Da Ihre Aufgaben zufällig (standardmäßig) auf derselben Art von EC2-Instanzen mit verfügbaren Ressourcen bereitgestellt werden, treten die folgenden Probleme auf:

  • Ein Cluster folgt denselben Regeln für die automatische Skalierung und stellt automatisch dieselbe Art von EC2-Instanzen bereit.
  • Einige Container benötigen völlig unterschiedliche Ressourcen, müssen aber dennoch zusammenarbeiten.
  • Einige Container folgen nicht unbedingt den gleichen Regeln für die automatische Skalierung.
  • Manchmal benötigen mehrere Container in derselben Aufgabe einen eigenen Load Balancer, und es ist nicht möglich, mehrere Load Balancer für dieselbe Aufgabe zu haben.

Die bevorzugte Problemumgehung bei diesen Problemen war:

  • Stellen Sie einige Ihrer Instanzen je nach Bedarf manuell mit unterschiedlichen Ressourcen bereit
  • Hängen Sie diese Instanzen an Ihren Cluster an
  • Führen Sie einen Container nach Aufgabe aus
  • Verknüpfen Sie Ihre EC2-Instanzen manuell miteinander
  • Schreiben Sie komplexe Einschränkungen für die Platzierung von Strategien in ECS, um sicherzustellen, dass sich die richtige Aufgabe auf dem richtigen Computer befindet, der über die entsprechende Ressource verfügt, je nachdem, was er getan hat

Das ist viel Arbeit, ziemlich langweilig und schwer zu pflegen. Und es vereitelt in erster Linie den Zweck, mit Containern zu arbeiten.

Jemand musste sich eine bessere Idee einfallen lassen.

Lass sie schweben

Wie sich herausstellte, hatte das AWS-Team die gleichen Probleme. Sie haben im letzten Jahr darüber nachgedacht und daran gearbeitet, das folgende Problem zu lösen:

Wie können wir Container ausführen, ohne uns um Server und Cluster kümmern zu müssen?

Und darum geht es bei AWS Fargate . Die zugrunde liegende Infrastruktur wird vollständig abstrahiert, und Sie sehen jeden Ihrer Container als eine einzelne Maschine.

Sie müssen nur angeben, welche Ressource Sie für jeden Container benötigen, und er erledigt das schwere Heben für Sie. Sie müssen keine mehrschichtigen Zugriffsregeln mehr verwalten. Sie können die Berechtigungen zwischen Ihren Containern genau wie zwischen einzelnen EC2-Instanzen optimieren.

Es ist, als würden Ihre Container zu Schiffen mit eigenem Segel, Ruder und Besatzung und können selbstständig an ihr Ziel schweben.

Container als Dienstleistung (CaaS)

Ich glaube tatsächlich, dass Containers as a Service (CaaS) das echte PaaS ist , auf das Entwickler seit Jahren warten. Entwickler können ihre Container direkt in der Cloud bereitstellen, ohne sich um alles dazwischen kümmern zu müssen.

Natürlich gibt es bereits viele Technologien, mit denen Sie Ihren Code nahtlos in der Cloud ausführen können, ohne sich um Skalierung oder Serververwaltung kümmern zu müssen (wie das erstaunliche Heroku , Lambda oder sogar die eigene Google App Engine) . Aber alle haben Einschränkungen.

  • Sie müssen sich entscheiden, ob Sie ein wenig an Flexibilität verlieren möchten
  • Sie müssen sich an die unterstützten Sprachen halten
  • Sie können die unterstützten Sprachen nicht verwenden, da Ihr Projekt eine native Bibliothek auf niedriger Ebene benötigt, die nur auf sehr spezifischen Systemen verfügbar ist
  • Ihr Projekt verwendet eine Spitzentechnologie, die in den nächsten Jahren nicht für die Massen verfügbar sein wird
  • Einige dieser Plattformen sind sehr (sehr) teuer, insbesondere beim Skalieren

Fargate (oder CaaS) bietet Ihnen das Beste aus beiden Welten.

Die containerisierte Architektur bietet Ihnen die Flexibilität und Kontrolle, die Sie benötigen. Sie können damit jede Art von Technologie verwenden, die in jedem gewünschten System ausgeführt wird . Der Container-Aspekt stellt sicher, dass Sie auf jedem Host das gleiche Verhalten haben, egal ob es sich um eine Entwicklungs-, Test-, Staging- oder Produktumgebung handelt.

Ich finde diesen Punkt für viele Tech-Startups kritisch. In der Tat ist einer Ihrer Wettbewerbsvorteile manchmal die Verwendung einer hochmodernen Technologie, an deren Entwicklung Sie beteiligt waren, oder die intelligente Wiederverwendung einer anderen Technologie in einem völlig neuen und revolutionären Kontext.

Mit der serverlosen Bereitstellung können Sie sich darauf konzentrieren, großartigen Code zu schreiben. Keine Bereitstellung, einfache Skalierung.

Grenzen

CaaS gegen PaaS

Es ist wahr, dass Sie einige coole Aspekte von echtem PaaS aufgeben. Ja, Sie müssen die Bilder Ihres Containers immer noch manuell aktualisieren , und manchmal müssen Sie Ihre eigenen Docker-Bilder schreiben. Dies kann zunächst schwierig sein, wenn Sie die Grundlagen der Systemadministration nicht kennen .

Dies bedeutet jedoch auch, dass Sie so ziemlich alles tun können, woran Sie denken können, und über vollständige Flexibilität und Freiheit in den Systemen, Sprachen, Tools, Bibliotheken und Versionen verfügen, die Sie verwenden möchten.

Kosten

Seien wir ehrlich, Cloud-Dienste (IaaS) sind teurer als eine eigene Infrastruktur (wenn Sie sie bei Bedarf vergrößern und verkleinern können). Aus dem gleichen Grund ist es kostenpflichtig, Ihre Server nicht bereitstellen, verwalten und skalieren zu müssen. Für einige Ihrer einfachsten Anwendungsfälle ist dies möglicherweise noch nicht die beste Lösung.

Hoffen wir, dass sie daran arbeiten werden , die Kosten zu senken. So gut das Produkt auch ist, es ist schwierig, den fast vierfachen Preis einer On-Demand-äquivalenten EC2-Instanz (zum Beispiel für t2.medium) zu rechtfertigen.

Sollte ich alle meine ECS-Aufgaben auf Fargate umstellen?

Noch nicht. Wie oben erwähnt, werden Sie in einigen Fällen Ihre Kosten mehr als verdreifachen. Bis sie die Kosten senken, ist es möglicherweise besser, Standard-EC2-Instane zu verwenden.

In den folgenden Anwendungsfällen kann Fargate jedoch für Sie vorteilhafter sein:

  • Wenn Sie Probleme haben, Ihre ECS-Aufgaben effizient automatisch zu skalieren, und häufig viel ungenutzte CPU oder Arbeitsspeicher zur Verfügung stehen . Mit Fargate zahlen Sie nur für die Ressourcen, die Sie in Ihren Aufgaben definiert haben .
  • Für Ihre Aufgaben, die bei Bedarf oder nach einem Zeitplan ausgeführt werden und keine dedizierte EC2-Instanz benötigen. Mit Fargate zahlen Sie nur, wenn Ihre Aufgabe ausgeführt wird.
  • Für Ihre Aufgaben mit Spitzenwerten bei Speicher- und / oder CPU-Auslastung . Nur weil Sie dadurch Zeit und Aufwand bei der Konfiguration und Verwaltung solcher Fälle sparen.

Bonus

Für diejenigen, die Kubernetes gegenüber ECS bevorzugen , wird Fargate in Kürze den Elastic Container Service für Kubernetes ausführen können.