Google Cloud für AWS-Experten: Computing

Aktualisiert am 21.­11.2017

Vergleichen Sie die Computing-Dienste, die Amazon Web Services (AWS) und Google Cloud in ihren jeweiligen Cloud-Umgebungen bereitstellen. Computing-Dienste werden in der Regel in vier verschiedenen Dienstmodellen angeboten:

  • Infrastructure as a Service (IaaS), bei dem Nutzer nach Bedarf direkten Zugriff auf virtuelle Maschinen sowie auf eine Reihe zugehöriger Dienste zur Automatisierung häufiger Aufgaben haben.
  • Platform as a Service (PaaS), bei dem die Maschinenebene vollständig abstrahiert ist und Nutzer über übergeordnete Dienste und APIs mit Ressourcen interagieren.
  • Functions as a Service (FaaS), ein serverloses Computing-Modell, mit dem Sie einzelne Funktionen als Reaktion auf eine Vielzahl von Auslösern ausführen können.
  • Containers as a Service (CaaS), eine Mischung aus IaaS und PaaS, bei der die Maschinenebene abstrahiert ist, aber viel von der Flexibilität des IaaS-Modells erhalten bleibt.

Im Mittelpunkt dieses Artikels stehen die von Google Cloud und AWS angebotenen IaaS-, PaaS-, FaaS- und CaaS-Dienste.

IaaS-Vergleich

Für IaaS stehen die Amazon Elastic Compute Cloud (EC2) von AWS und Compute Engine von Google Cloud zur Verfügung. Die Konzepte von Google und Amazon für IaaS-Dienste sind ähnlich. Sowohl für Amazon EC2 als auch für Compute Engine gilt:

  • Es sind grundlegende Komponenten der jeweiligen Cloudumgebung
  • Es kann damit beinahe jede Art von Kundenarbeitslast auf der jeweiligen Plattform ausgeführt werden

Auf übergeordneter Ebene lassen sich die Begriffe und die Konzepte von Amazon EC2 mit denen von Compute Engine folgendermaßen vergleichen:

Funktion Amazon EC2 Compute Engine
Virtuelle Maschinen Instanzen Instanzen
Maschinen-Images Amazon Machine Image Image
Temporäre virtuelle Maschinen Spot-Instanzen VMs auf Abruf
Firewall Sicherheitsgruppen Compute Engine-Firewallregeln
Automatische Instanzskalierung Automatische Skalierung Compute Engine-Autoscaling
Lokal hinzugefügte Festplatte Ephemerisches Laufwerk Lokale SSD
VM-Import Unterstützte Formate: RAW, OVA, VMDK und VHD Unterstützte Formate: RAW, OVA, VMDK und VHD
Bereitstellungsort Zonal Zonal

VM-Instanzen

VM-Instanzen in Compute Engine und Amazon EC2 haben größtenteils die gleichen Funktionen. Mit beiden Diensten können Sie:

  • Instanzen von gespeicherten Laufwerk-Images erstellen
  • Instanzen nach Bedarf starten und beenden
  • Ihre Instanzen ohne Beschränkungen verwalten
  • Ihre Instanzen mit Tags kennzeichnen
  • Verschiedene Betriebssysteme auf Ihren Instanzen installieren

Maschinenzugriff

Die Konzepte für den Maschinenzugriff von Compute Engine und Amazon EC2 unterscheiden sich in einigen wenigen Punkten:

  • Mit Amazon EC2 müssen Sie einen eigenen SSH-Schlüssel angeben, wenn Sie mit einem Terminal auf die Instanz zugreifen möchten.
  • Mit Compute Engine können Sie den Schlüssel bei Bedarf erstellen, auch wenn die Instanz bereits ausgeführt wird.
  • Sie können das browserbasierte SSH-Terminal von Compute Engine in der Google Cloud Console verwenden, ohne Schlüssel auf dem lokalen Computer speichern zu müssen.

Instanztypen

Amazon EC2 und Compute Engine bieten beide eine Vielzahl an vordefinierten Instanzkonfigurationen mit einem bestimmten Umfang an virtuellen CPUs, virtuellem Arbeitsspeicher (RAM) und virtuellen Netzwerken.

  • Bei Amazon EC2 werden diese Konfigurationen als Instanztypen bezeichnet
  • Bei Compute Engine werden diese Konfigurationen Maschinentypen genannt.
  • Mit Compute Engine können Sie von den vordefinierten Konfigurationen abweichen und CPUs sowie Arbeitsspeicher (RAM) der Instanz an die jeweilige Arbeitslast anpassen

Vordefinierte Instanzen können grob nach ihrer beabsichtigten Verwendung kategorisiert werden, wie in der folgenden Tabelle dargestellt:

Maschinentyp Beschreibung
Gemeinsam genutzter Kern

Maschinen, die auf einem Teil einer einzelnen physischen CPU ausgeführt werden.

Geeignet für Aufgaben, die nur wenige Ressourcen benötigen, aber für einen längeren Zeitraum online bleiben müssen.

Standard

Maschinen mit einer abgestimmten Kombination aus Compute-, Netzwerk- und Speicherressourcen.

Geeignet für die meisten allgemeinen Anwendungen ohne spezifische Ressourcenanforderungen.

Großer Speicher

Maschinen mit einem größeren Verhältnis von Arbeitsspeicher zu vCPUs als das Standardverhältnis.

Geeignet für speicherintensive, aber nicht rechenintensive Anwendungen. Dazu gehören beispielsweise hochleistungsfähige Datenbankanwendungen, Anwendungen, die große Daten-Caches verwenden, und alle großen datengesteuerten Anwendungen wie z. B. Managementsysteme für Unternehmen.

Leistungsfähige CPU

Maschinen mit einem größeren Verhältnis von vCPUs zu Arbeitsspeicher als das Standardverhältnis.

Geeignet für rechenintensive Anwendungen ohne ungewöhnlich hohen Bedarf an Arbeitsspeicher. Beispiele dafür sind Software zur Datentransformation (z. B. Videocodierung), Simulationssoftware in Wissenschaft und Technik sowie Webserver mit hohem Traffic.

GPU

Maschinen mit eigenständigen Grafikprozessoren (Graphics Processing Units, GPU).

Geeignet für Anwendungen mit hohem Bedarf an mathematischer Verarbeitung. Ein typisches Beispiel ist das Machine Learning. Es gibt aber noch viele andere Aufgaben, die ggf. von der erhöhten Effizienz der erweiterten mathematischen Verarbeitung von GPUs profitieren.

SSD-Speicher

Maschinen mit lokalem SSD-Speicher (Solid-State Drive).

Geeignet für Anwendungen, die einen hohen Durchsatz für Speicher benötigen. SSD-Speicher bieten einen schnelleren Zugriff als magnetische Speicher.

Hohe Speicherdichte

Maschinen mit magnetischen Speichermedien hoher Kapazität.

Geeignet für Anwendungen, die große Datenmengen auf lokalen Festplatten speichern. In vielen Fällen können Anwendungen mit hohen Speicheranforderungen Daten in anderen Webdiensten statt auf VMs hinzugefügten Festplatten speichern.

In der folgenden Tabelle sind die Instanztypen für beide Dienste aufgeführt (Stand Mai 2016).

Maschinentyp Elastic Compute Cloud Compute Engine
Gemeinsam genutzter Kern t2.micro – t2.large f1-micro
g1-small
Standard m3.medium – m3.2xlarge
m4.large – m4.10xlarge
n1-standard-1 – n1-standard-64
Großer Arbeitsspeicher r3.large – r3.8xlarge
x1.32xlarge
n1-highmem-2 – n1-highmem-64
Leistungsfähige CPU c3.large – c3.8xlarge
c4.large – c4.8xlarge
n1-highcpu-2 – n1-highcpu-64
gpu g2.2xlarge
g2.8xlarge
GPUs den meisten Maschinentypen hinzufügen
SSD-Speicher i2.xlarge – i2.8xlarge n1-standard-1 – n1-standard-64
n1-highmem-2 – n1-highmem-64
n1-highcpu-2 – n1-highcpu-64*
Hohe Speicherdichte d2.xlarge – d2.8xlarge

* Obwohl Compute Engine keine Maschinentypen bietet, die genau diesen AWS-Instanztypen entsprechen, kann durch Hinzufügen von lokalem SSD-Speicher das Gleiche erreicht werden.

Compute Engine und AWS teilen die gleichen übergeordneten Familien an Instanztypen, darunter "Standard", "Großer Speicher", "Leistungsfähige CPU" und "Gemeinsamer Kern". Allerdings gibt es in Compute Engine keine spezielle Kategorie für Instanzen, die lokalen SSD-Speicher verwenden. Alle nicht geteilten Instanztypen von Compute Engine unterstützen hinzugefügte lokale SSD-Festplatten. Einen detaillierteren Vergleich, wie die Umgebungen lokal hinzugefügte SSDs implementieren, erhalten Sie unter Lokal hinzugefügter Speicher.

Compute Engine bietet derzeit keine große magnetische Speicherung.

Temporäre Instanzen

Temporäre Instanzen sind virtuelle Maschinen, die in freien Ressourcenzyklen ausgeführt werden, die anderen Prozessen zugewiesen sind. Das Ergebnis ist eine VM mit nicht vorhersehbarer Verfügbarkeit, die geringere Kosten als eine mit dedizierten Ressourcen erstellte VM verursacht. Temporäre Instanzen sind für Folgendes hilfreich:

  • Jobs, die unterbrochen werden können, ohne die bisherigen Ergebnisse zu verlieren
  • Jobs mit niedriger Priorität, die nicht innerhalb eines bestimmten Zeitraums abgeschlossen werden müssen
  • Zusätzliche Ressourcen für Jobs, die von einer höheren verfügbaren Rechenleistung profitieren, beispielsweise das Rendern von Videos

Amazon EC2 bietet als temporäre Instanzen sogenannte Spot-Instanzen. Mit Compute Engine sind ähnliche Instanzen verfügbar. Diese werden als VMs auf Abruf bezeichnet. Beide bieten eine vergleichbare Funktionalität, haben aber unterschiedliche Preismodelle.

Sowohl für Spot-Instanzen wie für VMs auf Abruf gilt:

  • Sie sind auf eine kleinere Gruppe verfügbarer Instanztypen und Maschinen-Images als herkömmliche On-Demand-Instanzen beschränkt
  • Sie können während der Ausführung die gleiche Leistung wie On-Demand-Instanzen erzielen.
  • Sie können während der Ausführung komplett gesteuert werden

Spot-Instanzen von Amazon EC2 gibt es in zwei Varianten:

  • Für reguläre Spot-Instanzen gilt:
    • Sie werden auf dem Spot-Markt versteigert.
    • Sie werden gestartet, wenn ein Angebot akzeptiert wurde.
    • Sie sind aktiv, bis sie beendet oder von AWS unterbrochen werden
  • Für Spot-Blöcke gilt:
    • Der Festpreis liegt unter dem regulären On-Demand-Preis.
    • Sie können maximal sechs Stunden zum ermäßigten Preis ausgeführt werden

Die präemptiven VMs von Compute Engine unterscheiden sich folgendermaßen von Spot-Instanzen:

  • Die Preise sind fix. Die Preise für VMs auf Abruf können, abhängig vom Maschinentyp, um bis zu 80 % des On-Demand-Preises ermäßigt werden.
  • VMs auf Abruf werden, wenn sie von Compute Engine nicht wieder in Anspruch genommen werden, maximal 24 Stunden ausgeführt und dann automatisch beendet.
  • Wenn Sie ein Premium-Betriebssystem mit einer Lizenzgebühr verwenden, fallen während der Verwendung der VMs auf Abruf die gesamten Kosten für die Lizenz an.

Maschinen-Images

Compute Engine und Amazon EC2 nutzen beide Maschinen-Images für das Erstellen neuer Instanzen. Bei Amazon werden diese Images als "Amazon Machine Images" (AMIs) bezeichnet, bei Compute Engine werden sie einfach "Images" genannt.

Amazon EC2 und Compute Engine sind so ähnlich, dass Sie auf beiden Plattformen den gleichen Workflow für die Erstellung von Images verwenden können. Beispielsweise enthalten sowohl Amazon EC2-AMIs als auch Compute Engine-Instanzen ein Betriebssystem. Sie können auch andere Software wie Webserver oder Datenbanken enthalten. Zusätzlich besteht bei beiden Diensten die Möglichkeit, von Drittanbietern veröffentlichte Images oder benutzerdefinierte Images für den privaten Gebrauch zu verwenden.

Amazon EC2 und Compute Engine speichern Images auf verschiedene Arten. Auf AWS speichern Sie Images entweder in Amazon Simple Storage Service (S3) oder Amazon Elastic Block Store (EBS). Wenn Sie eine Instanz erstellen, die auf einem in Amazon S3 gespeicherten Image basiert, treten während der Erstellung größere Latenzen als mit Amazon EBS auf.

In Google Cloud werden Images in Compute Engine gespeichert. Zum Aufrufen der verfügbaren Images bzw. zum Erstellen oder Importieren von Images verwenden Sie die Seite für Cloud Console-Images oder das gcloud-Befehlszeilentool im Cloud SDK.

Anders als bei Amazon EC2 gibt es bei Compute Engine kein Verfahren, um ein Image öffentlich verfügbar zu machen, und kein Community-Repository, aus dem verfügbare Images übernommen werden können. Allerdings können Sie Images informell teilen, wenn Sie Ihre Images nach Cloud Storage exportieren und sie öffentlich verfügbar machen.

Die Maschinen-Images von Amazon sind nur innerhalb einer bestimmten Region verfügbar. Im Gegensatz dazu sind die Maschinen-Images von Compute Engine global verfügbar.

Öffentliche Images

Amazon EC2 und Compute Engine bieten beide eine Vielzahl an öffentlichen Images mit gängigen Betriebssystemen. Auf beiden Plattformen bezahlen Sie zusätzlich zu den normalen Kosten für die Instanz eine Lizenzgebühr, wenn Sie ein Premium-Image mit einem lizenzpflichtigen Betriebssystem installieren.

Bei beiden Diensten können Sie auf Maschinen-Images für die meisten gängigen Betriebssysteme zugreifen. Eine vollständige Liste an Images, die auf Compute Engine verfügbar sind, finden Sie unter Liste der öffentlichen Images.

Amazon EC2 unterstützt einige Images mit Betriebssystemen, die nicht als öffentliche Images auf Compute Engine verfügbar sind.

  • Amazon Linux
  • Windows Server 2003 (Premium)
  • Oracle Linux (Premium)

Import benutzerdefinierter Images

Sowohl Amazon EC2 als auch Compute Engine bieten die Möglichkeit, bestehende Maschinen-Images in ihre jeweilige Umgebung zu importieren.

Amazon EC2 stellt einen Dienst mit dem Namen VM Import/Export zur Verfügung. Dieser Dienst unterstützt eine Reihe von VM-Image-Typen wie RAW, OVA, VMDK und VHD sowie verschiedene Betriebssysteme, einschließlich Varianten von Windows, Red Hat Enterprise Linux (RHEL), CentOS, Ubuntu und Debian. Eine virtuelle Maschine importieren Sie mit einem Befehlszeilentool, das die VM-Images gruppiert und auf Amazon Simple Storage Service (S3) als AMI hochlädt.

Der Prozess und die Anforderungen für den Import von Maschinen-Images in Compute Engine sind mit denen bei Amazon EC2 vergleichbar. Wie beim VM-Import/Export unterstützt das Compute Engine-Importtool die Image-Typen RAW, OVA, VMDK und VHD sowie Windows-, RHEL-, CentOS-, Ubuntu- und Debian-Betriebssysteme. Sie importieren eine virtuelle Maschine, wenn Sie das Image in Cloud Storage hochladen und dann das gcloud-Befehlszeilentool oder die Cloud Console verwenden, um den Prozess des Image-Imports in Compute Engine abzuschließen. Weitere Informationen zum Importieren von Images und anderen virtuellen Assets in Compute Engine finden Sie unter Importmethode auswählen.

Wenn Sie eigene benutzerdefinierte Betriebssysteme erstellen und diese auf Compute Engine ausführen möchten, müssen Sie prüfen, ob die Anforderungen für Hardware-Support und Kernel erfüllt sind.

Abgesehen von den Kosten für die Speicherung eines Images in Amazon S3 oder Cloud Storage entstehen für die jeweiligen Importdienste keine Kosten, weder bei AWS noch bei Google Cloud.

Automatische Instanzskalierung

Sowohl Compute Engine als auch Amazon EC2 unterstützen das Autoscaling. Dabei werden Instanzen nach benutzerdefinierten Richtlinien erstellt und entfernt. Mithilfe des Autoscalings können Sie jederzeit eine bestimmte Anzahl von Instanzen bereitstellen und die Kapazität an bestimmte Bedingungen anpassen. Automatisch skalierte Instanzen werden aus einer benutzerdefinierten Vorlage erstellt.

Compute Engine und Amazon EC2 implementieren die automatische Skalierung auf ähnliche Weise:

  • Auto Scaling von Amazon skaliert Instanzen innerhalb einer Gruppe. Beim Autoscaling werden Instanzen nach dem gewählten Skalierungsplan erstellt bzw. entfernt. Jede neue Instanz innerhalb der Gruppe wird aus einer Startkonfiguration erstellt.
  • Das Autoscaling in Compute Engine skaliert Instanzen innerhalb einer verwalteten Instanzgruppe. Dabei werden Instanzen entsprechend einer Autoscaling-Richtlinie erstellt und entfernt. Jede neue Instanz innerhalb der Instanzgruppe wird aus einer Instanzvorlage erstellt.

Es gibt drei Arten von Skalierungsplänen in Amazons Auto Scaling:

  • Manuell – hierbei weisen Sie Auto Scaling manuell an, herauf- oder herunterzuskalieren.
  • Geplant – hierbei konfigurieren Sie Auto Scaling so, dass es zu bestimmten Zeiten hoch- oder herunterskaliert.
  • Dynamisch – in diesem Fall skaliert Auto Scaling nach einer Richtlinie. Sie können Richtlinien basierend auf Amazon CloudWatch-Messwerten oder auf der Basis von Warteschlangen von Amazon Simple Queue Service (SQS) erstellen.

Im Gegensatz dazu unterstützt das Autoscaling von Compute Engine nur die dynamische Skalierung. Sie können Richtlinien entsprechend der durchschnittlichen CPU-Auslastung, der Bereitstellungskapazität des HTTP(S)-Load-Balancings oder der Cloud Monitoring-Messwerte erstellen.

Interne Netzwerke

Sowohl bei Compute Engine als auch bei Amazon EC2 werden neue Instanzen automatisch mit einem internen Standardnetzwerk verbunden. Zusätzlich erstellen Sie bei beiden Diensten ein alternatives Netzwerk, in dem Sie Instanzen starten. Einen vollständigen Vergleich der Netzwerke von Google Cloud und AWS finden Sie im Artikel "Netzwerk".

Firewalls

Sowohl mit Amazon EC2 als auch mit Compute Engine können Nutzer Firewallrichtlinien konfigurieren, um punktuell Traffic auf VM-Instanzen zuzulassen oder zu unterbinden. Standardmäßig blockieren beide Dienste jeden eingehenden Traffic von außerhalb eines Netzwerks. Nutzer müssen, um eine Instanz zu erreichen, eine Firewallregel für Pakete festlegen.

Amazon EC2 und Amazon Virtual Private Cloud (VPC) nutzen Sicherheitsgruppen und Netzwerk-Zugriffssteuerungslisten (NACLs), um eingehenden und ausgehenden Traffic zuzulassen oder abzulehnen. Sicherheitsgruppen in Amazon EC2 schützen Instanzen in Amazon EC2-Classic, während Amazon VPC Sicherheitsgruppen und NACLs sowohl Instanzen als auch Subnetzwerke in einer Amazon VPC schützen.

Compute Engine nutzt Firewallregeln, um VM-Instanzen und Netzwerke in Compute Engine zu schützen. Für eine Regel legen Sie den Bereich von Quell-IP-Adressen, ein Protokoll, Ports oder benutzerdefinierte Tags für Quell- und Zielgruppen von VM-Instanzen fest.

Blockspeicher

Amazon EC2 und Compute Engine unterstützen beide Blockspeicher im Netzwerk und lokal angehängten Blockspeicher. Einen detaillierten Vergleich der Blockspeicherdienste finden Sie unter Blockspeicher.

Kosten

In diesem Abschnitt werden die Preismodelle für Compute Engine und Amazon EC2 verglichen.

On-Demand-Preise

Für Compute Engine und Amazon EC2 gelten ähnliche On-Demand-Preismodelle für ausgeführte Instanzen:

  • Bei Amazon EC2 wird sekundengenau abgerechnet. Die Mindestdauer beträgt eine Minute. Premium-Betriebssysteme wie Windows oder RHEL werden pro Stunde abgerechnet, wobei auf die nächsthöhere Stundenzahl aufgerundet wird.
  • Compute Engine-Gebühren fallen ebenfalls pro Sekunde an, bei einer Mindestdauer von einer Minute.

Mit beiden Diensten können Sie Instanzen unbegrenzt ausführen.

Rabatte

Compute Engine und Amazon EC2 haben einen grundverschiedenen Ansatz zu Rabatten:

In Amazon EC2 erhalten Sie Rabatte für die Bereitstellung reservierter Instanzen:

  • Sie müssen sich entweder für ein Jahr oder für drei Jahre zum Betrieb einer bestimmten Anzahl an Instanzen verpflichten
  • Für diese Instanzen fallen geringere Kosten an.
  • Eine dreijährige Bindung führt zu größeren Rabatten als eine einjährige Bindung.
  • Je mehr Sie anfänglich zahlen, desto größer wird der Rabatt.
  • Reservierte Instanzen sind bei der Anschaffung an einen bestimmten Instanztyp und eine bestimmte Verfügbarkeitszone gebunden.
  • Sie können Verfügbarkeitszonen und reservierte Instanzen nur zu anderen Instanztypen in der gleichen Familie ändern

Bei Compute Engine-Instanzen ist ein Rabatt für kontinuierliche Nutzung möglich:

  • Bei Compute Engine werden automatisch Rabatte für Ihre Instanzen vergeben, je nachdem, wie lang die Instanzen in einem bestimmten Monat aktiv sind
  • Je länger Sie eine Instanz in einem bestimmten Monat verwenden, desto größer ist der Rabatt.
  • Mit Rabatten für kontinuierliche Nutzung können Sie im Vergleich zum standardmäßigen On-Demand-Preis bis zu 30 % einsparen.

FaaS-Vergleich

Für FaaS (Functions as a Service) bietet Amazon AWS Lambda und Google Cloud Cloud Functions. Die Dienstmodelle sind jeweils ähnlich:

  • Bei beiden handelt es sich um serverlose Computing-Plattformen, auf denen Sie einzelne Funktionen als Reaktion auf eine Vielzahl von Auslösern ausführen können
  • Es entstehen Ihnen nur Gebühren, wenn Ihre Funktionen ausgeführt werden.
  • Sie bieten eine kostengünstige Möglichkeit, Dienste mit uneinheitlichen Nutzungsmustern zu hosten

Dienstmodelle im Vergleich

AWS Lambda-Begriffe und -Konzepte im Vergleich zu jenen von Cloud Functions:

Feature AWS Lambda Cloud Functions
Codeerfassung Zip-Upload, Online-IDE, Deskop-IDE, Amazon S3 Zip-Upload, Online-IDE, Cloud Storage, GitHub
Latenz von Codeaktualisierungen In der Regel innerhalb von Sekunden In der Regel in weniger als 2 Minuten
Höchstanzahl gleichzeitiger Ausführungen Standardmäßig 1.000 pro Region Standardmäßig 1.000 pro Funktion
Max. Bereitstellungsgröße 50 MB komprimiert, 250 MB unkomprimiert 100 MB komprimiert, 500 MB unkomprimiert
Trigger S3, DynamoDB, Kinesis Streams und Firehose, SNS, SES, Cognito, CloudFormation, CloudWatch, CodeCommit, geplaten Ereignisse, AWS-Konfigurationsänderungen, Amazon Echo, Amazon Lex, API Gateway (HTTP), IoT-Schaltfläche, CloudFront HTTP, Cloud Storage, Pub/Sub, Firebase, Cloud Logging
Unterstützte Sprachen Node.js, Java, Python, C#, Go Node.js 6, Node.js 8, Python
Speicherzuordnung 128 MB bis 1,5 GB in Schritten von 64 MB 128 MB, 256 MB, 512 MB, 1 GB, 2 GB
Zeitlimits 1 Sek. bis 15 Min. 1 Sek. bis 9᠎ Min.
Versionsverwaltung Eingebunden Über Cloud Source Repositories
Automatische Skalierung Ja Ja
Logging Amazon CloudWatch Cloud Logging
Bereitstellungsort Regional Regional
Preismodell Pro Anfrage, Abrechnung in 0,1-Sekunden-Schritten sowie Datenübertragung. Die Kosten für die Dauer werden mit der Speichernutzung skaliert. Pro Anfrage, Abrechnung in 0,1-Sekunden-Schritten sowie Datenübertragung. Die Kosten für die Dauer werden mit der Speichernutzung und CPU-Auslastung skaliert.

Starten und skalieren

AWS Lambda und Cloud Functions haben eine Reihe an gemeinsamen Funktionen. Beide bieten eine serverlose Codeausführung mit einer Vielzahl von Auslösern und werden bei Bedarf automatisch skaliert. Sie ermöglichen auch beide eine einfache Bereitstellung, Skalierung und Fehlerbehebung. Die Architektur startet einen Compute-Container mit einer Kopie Ihres Codes und skaliert automatisch die Anzahl der Instanzen, die für die Verarbeitung Ihrer anfallenden Lasten benötigt werden. Nach der Bereitstellung der Funktion ist keine Konfiguration oder Verwaltung erforderlich.

Google verwendet eine Architektur auf Abruf zur Imageerzeugung, die die Latenz für erste Anfragen bei jeder neuen Instanz erheblich reduziert. Dies kann ein erheblicher Vorteil für Echtzeitanwendungen oder Situationen sein, in denen Ihre Anwendung sehr schnell skaliert werden muss.

Unterstützte Sprachen und Trigger

Lambda ist schon länger als Cloud Functions verfügbar. Es unterstützt daher mehr Sprachen und Triggertypen. Cloud Functions unterstützt Firebase-Trigger, Logs der Operations-Suite von Google Cloud und Pub/Sub. Mit diesen Tools können Sie eine Cloud Functions-Funktion von nahezu jedem anderen Google Cloud-Dienst oder -Ereignis aus auslösen.

Laufzeitbeschränkungen

Da FaaS-Plattformen ausschließlich transaktionsorientiert sind und Instanzen auf Anfrage bereitstellen, können Sie sich nicht darauf verlassen, dass sie Code kontinuierlich über die ursprüngliche Anfrage hinaus ausführen. Sie sollten Ihre Anwendung so konzipieren, dass sie zustandslos und nur mit kurzer Laufzeit ausgeführt wird. Dies gilt sowohl für Lambda als auch für Cloud Functions:

  • AWS beendet die Ausführung nach fünf Minuten.
  • Cloud Functions beendet die Ausführung nach neun Minuten

FaaS bereitstellen

Die Bereitstellung von FaaS unterscheidet sich bei Amazon und Google geringfügig. AWS Lambda unterstützt die Bereitstellung aus einer ZIP- oder JAR-Datei oder über CloudFormation oder S3. Zusätzlich zu ZIP-Dateien können die Cloud Functions-Funktionen von Google Cloud aus einem Git-Repository entweder aus GitHub- oder aus Cloud Source Repositories bereitgestellt werden. Git-Support verbindet Cloud Functions eng mit Ihrem Bereitstellungsprozess. Sie können auch automatische Updates auf der Grundlage von Webhooks konfigurieren.

Kosten

Preise für AWS Lambda setzen sich aus einem Basispreis pro Anfrage sowie aus einem variablen Preis auf der Grundlage der RAM-Zuordnung und der Rechenzeit zusammen. AWS Lambda rechnet die Datenübertragung mit dem Standard-EC2-Preis ab.

Cloud Functions berechnet einen variablen Preis auf der Grundlage des zusätzlich zur Aufrufrate bereitgestellten Umfangs an Speicher und CPU. Wie bei AWS Lambda werden für Cloud Functions Standardgebühren für die ausgehende Bandbreite, aber keine Gebühren für den eingehenden Traffic berechnet.

Weitere Informationen finden Sie auf der Preisseite für Cloud Functions. Mit dem Google Cloud-Preisrechner können Sie die geschätzten Kosten für Ihre spezifische Arbeitslast ermitteln.

PaaS-Vergleich

Für PaaS bietet AWS Elastic Beanstalk und Google Cloud App Engine. Bei beiden Diensten steht Ihnen die folgende Funktionalität zur Verfügung:

  • Sie können damit Anwendungen durch Senden von Programmcode an einen verwalteten Plattformdienst veröffentlichen.
  • Der Dienst verwaltet folgende Elemente:
    • Eine zugrunde liegende Infrastruktur
    • Automatische Skalierung
    • Versionskontrolle der Anwendung

Dienstmodelle im Vergleich

Bei AWS Elastic Beanstalk wird eine Reihe zugrunde liegender AWS-Ressourcen wie Amazon EC2-Instanzen oder Amazon RDS-Datenbanken konfiguriert und implementiert, um auf der Grundlage Ihrer Eingabekonfiguration eine geeignete Laufzeit für Ihre Anwendung zu erstellen.

App Engine verwendet das gleiche Modell. Allerdings bietet App Engine zwei unterschiedliche Umgebungen: die Standardumgebung von App Engine und die flexible Umgebung von App Engine. Diese sind jeweils für bestimmte Anwendungsfälle konzipiert.

  • In der Standardumgebung von App Engine wird Ihr Code in Container-Instanzen implementiert, die auf der Google-Infrastruktur ausgeführt werden. Da die App Engine-Standardumgebung nicht auf zugrunde liegenden Compute-Engine-VM-Instanzen basiert, wird sie schneller als die flexible App Engine-Umgebung skaliert. Bei der App Engine-Standardumgebung haben Sie jedoch weniger Möglichkeiten zur benutzerspezifischen Anpassung als bei der flexiblen App Engine-Umgebung. Außerdem müssen Sie dabei eine Laufzeitumgebung aus den vordefinierten Laufzeitumgebungen des Dienstes verwenden.
  • In der flexiblen App Engine-Umgebung wird Ihr Code in Docker-Containern bereitgestellt, die auf Compute Engine-VM-Instanzen ausgeführt werden. Diese Container werden von App Engine verwaltet. Es werden mehr Laufzeiten als in der App Engine-Standardumgebung zur Auswahl unterstützt und Sie können teilweise oder vollständig angepasste Laufzeiten erstellen. Bei hohen Zugriffszahlen wird die Anwendung eventuell jedoch langsamer skaliert als in der App Engine-Standardumgebung. Informationen darüber, welche App Engine-Umgebung für Sie am besten geeignet ist, finden Sie unter App Engine-Umgebung auswählen.

Elastic Beanstalk könnte in die folgenden Dienste integriert werden:

  • Amazon DynamoDB: Vollständig verwaltete NoSQL-Datenbank, die beliebige Datenmengen speichern und abrufen kann
  • Amazon RDS: verwalteter relationaler Datenbankdienst auf Basis von MySQL, PostgreSQL, MariaDB, Amazon Aurora, Oracle oder Microsoft SQL Server
  • Automatische Skalierung und Lastenausgleich
  • Worker-Stufe-Umgebungen mit SQS-Integration zur Verarbeitung von Hintergrund- und regelmäßigen Aufgaben
  • Integration mit anderen AWS-Diensten und APIs

Für beide App Engine-Umgebungen können die gleichen Plattformdienste verwendet werden, z. B.:

  • Firestore: Nichtflüchtiger Speicher mit Abfragen, Sortierung und Transaktionen
  • CloudSQL: Relationale Datenbank auf Basis von MySQL oder PostgreSQL (derzeit in der Betaversion)
  • Automatische Skalierung und Lastenausgleich
  • Asynchrone Aufgabenwarteschlangen zum Ausführen von Arbeiten außerhalb des Geltungsbereichs einer Anfrage
  • Geplante Aufgaben zum Auslösen von Ereignissen zu bestimmten Zeiten oder in regelmäßigen Intervallen
  • Einbindung in andere Google Cloud-Dienste und APIs

Schlüsselkomponenten

Sowohl AWS Elastic Beanstalk als auch App Engine arbeiten mit ähnlichen Schlüsselkomponenten. Aus der Sicht von Entwicklern besteht AWS Elastic Beanstalk aus den folgenden Schlüsselkomponenten:

  • Anwendungsversion: Eine benannte/markierte Iteration von bereitstellbarem Code, der vom Entwickler eingereicht wurde
  • Umgebung: eine laufende Instanz einer bestimmten Anwendungsversion, die auf AWS-Ressourcen bereitgestellt wird
  • Umgebungskonfiguration: eine Sammlung von Parametern und Einstellungen, die steuern, wie Elastic Beanstalk zugrunde liegende AWS-Ressourcen für eine bestimmte Anwendungsversion, die einer bestimmten Umgebung zugeordnet ist, bereitstellt und konfiguriert
  • Anwendung: Ein logischer Bucket für eine Sammlung von Umgebungen, Umgebungskonfigurationen und Anwendungsversionen

App Engine besteht aus den folgenden Schlüsselkomponenten:

  • Version: Eine benannte Iteration von vom Entwickler eingereichtem implementierbarem Code und eine Konfigurationsdatei, die angibt, wie dieser Code in App Engine bereitgestellt wird, um einen Dienst zu erstellen.
  • Dienst: Eine App Engine-Anwendung besteht aus einem oder mehreren Diensten, die so konfiguriert werden können, dass sie unterschiedliche Laufzeiten verwenden und mit unterschiedlichen Leistungseinstellungen arbeiten. Jeder Dienst besteht aus Quellcode und einer Konfigurationsdatei.
  • Dienstkonfigurationsdatei: Eine Datei, die angibt, wie URL-Pfade Anfrage-Handlern und statischen Dateien entsprechen. Diese Datei enthält auch Informationen zum Anwendungscode, z. B. die Anwendungs-ID und die ID der aktuellen Version.
  • Instanz: Eine zugrunde liegende Compute-Ressource, auf der ein Dienst ausgeführt wird. In einer flexiblen App Engine-Umgebung ist eine Instanz ein Docker-Container in einer Compute Engine-VM-Instanz. In der App Engine-Standardumgebung ist eine Instanz ein Container, der auf der Google-Infrastruktur ausgeführt wird.
  • Anwendung: Ein logischer Bucket mit einem oder mehreren Diensten. Dieser Bucket kann so konfiguriert werden, dass er unterschiedliche Laufzeiten verwendet und mit unterschiedlichen Leistungseinstellungen arbeitet.

Auf übergeordneter Ebene können die Plattformen wie folgt verglichen werden:

Funktion AWS Elastic Beanstalk App Engine-Standardumgebung Flexible App Engine-Umgebung
Unterstützte Sprach-Laufzeitumgebungen Java, PHP, .NET, Node.js, Python (2.6, 2.7, 3.4), Ruby, Go Python 2.7, Java 7, PHP 5.5, Go 1.6 Python (2.7, 3.5), Java 8, Node.js, Go 1.8, Ruby, PHP (5.6, 7), .NET
Benutzerdefinierte Laufzeiten Ja Nein Ja
Automatische Skalierung Ja Ja Ja
Kostenloses Kontingent verfügbar Ja (basierend auf dem kostenlosen Kontingent der zugrunde liegenden AWS-Ressourcen) Ja (28 Instanzstunden pro Tag) Nein
Speicheroptionen Amazon S3, Amazon RDS, Amazon EFS, Amazon ElastiCache, Amazon DynamoDB Cloud Storage, Cloud SQL, Memcache, Firestore Cloud Storage, Cloud SQL, Memcache, Firestore
IAM-Rollen Ja Ja Ja
Verfügbare Standorte USA, EMEA, APAC USA, EMEA, APAC USA, EMEA, APAC
Nutzerauthentifizierung und -autorisierung für die Anwendung Nein, muss innerhalb der Anwendung entwickelt werden Ja, mit Firebase (mehrere Identitätsanbieter), Google Cloud Identity, OAuth 2.0 und OpenID Ja, mit Firebase (mehrere Identitätsanbieter), Google- und G Suite-Konten, OAuth 2.0 und OpenID
Aufgaben- und Nachrichtenwarteschlangen Ja, mit SQS Ja, mit Pub/Sub und der Task Queue API Ja, mit Pub/Sub und der Task Queue API
Anwendungsupgrades und A/B-Tests Rolling Update mit Skalierung basierend auf der Back-End-Kapazität, Blau-/Grün-Bereitstellung mit einmaligem Traffic-Austausch. Eine gewichtete Round-Robin-Verteilung ist mit einem DNS-basierten Ansatz möglich. Ja, mit detaillierter Trafficaufteilung zwischen Versionen Ja, mit granularer Traffic-Aufteilung zwischen Versionen
Monitoring Ja; Statusberichterstellung, Instanzlogs und Streams für Umgebungsereignisse Ja, mit der Operations-Suite von Google Cloud (Anfrage-/Antwort- und Aktivitätslogs), Verfügbarkeitsdiagnosen Ja, mit der Operations-Suite von Google Cloud (Anfrage-/Antwort- und Aktivitätslogs), Verfügbarkeitsdiagnosen, benutzerdefinierten Messwerten und Benachrichtigungen für zugrunde liegende Compute Engine-Ressourcen
Netzwerk Kann in einer VPC platziert werden Keine Netzwerkfunktionen, nur IP-Endpoints, die mit dem Internet verbunden sind Kann in einem VPC-Netzwerk platziert werden
Preis Basierend auf den Kosten der zugrunde liegenden AWS-Ressourcen Basierend auf der ausgewählten Instanz pro Stunde Der Preis besteht aus 3 Parametern:
  • vCPU pro Kernstunde
  • Speicher pro GB-Stunde
  • Nichtflüchtiger Speicher pro GB und Monat
Fehlerbehebung Ja, mit X-Ray Ja, mit der Operations Suite von Google Cloud Ja, mit der Operations Suite von Google Cloud

Benutzerdefinierte Laufzeiten

Mit AWS Elastic Beanstalk und der flexiblen Umgebung von App Engine können Sie Ihre eigene benutzerdefinierte Laufzeit erstellen. Sie haben dabei die Möglichkeit, andere Programmiersprachen bzw. eine andere Version oder Implementierung der Standardlaufzeiten der Plattform zu verwenden.

AWS Elastic Beanstalk unterstützt die Anpassung über benutzerdefinierte Plattformen, bei denen es sich um Amazon Machine Images (AMIs) handelt, die die für die Ausführung Ihrer Anwendung erforderlichen Binärdateien enthalten. Sie erstellen benutzerdefinierte Plattformen mit Packer, einem Open-Source-Tool zur Erstellung identischer Maschinenimages für mehrere Plattformen aus einer einzigen Quellkonfiguration. Mithilfe einer Packer-Konfigurationsvorlage können Sie Betriebssysteme, Sprachen und Frameworks sowie Metadaten und Konfigurationsoptionen anpassen, die Sie für Ihre Anwendung benötigen.

Die flexible Umgebung von App Engine unterstützt die Anpassung über benutzerdefinierte Laufzeiten. Zur Erstellung einer benutzerdefinierten Laufzeit legen Sie ein Dockerfile mit einem Basis-Image Ihrer Wahl an und fügen dann die Docker-Befehle hinzu, die die gewünschte Laufzeitumgebung erstellen. Ihr Dockerfile kann zusätzliche Komponenten wie Sprachinterpreter oder Anwendungsserver enthalten. Es kann dazu jede beliebige Software verwendet werden, mit der sich HTTP-Anfragen erstellen lassen.

In beiden Fällen müssen Sie darauf achten, dass alle Komponenten kompatibel sind und mit der erwarteten Leistung arbeiten.

AWS Elastic Beanstalk verwendet Packer und ermöglicht Nutzern die Steuerung des gesamten Betriebssystem-Images. In der flexiblen Umgebung von App Engine werden ausschließlich Docker-Container erstellt, sodass Nutzer nur Anwendungscode und zugehörige Abhängigkeiten steuern können. Ein Nutzer der flexiblen App Engine-Umgebung hat nicht die Möglichkeit, Elemente wie die Kernel-Version des Betriebssystems in zugrunde liegenden VMs festzulegen.

Autoscaling

Sowohl AWS Elastic Beanstalk als auch App Engine unterstützen automatische Skalierung. Mit einem Autoscaling können Sie die Anzahl der ausgeführten Back-End-Instanzen basierend auf der Ressourcennutzung Ihrer Anwendung automatisch erhöhen oder reduzieren lassen.

Das Autoscaling von AWS Elastic Beanstalk kann mit folgenden Skalierungsoptionen konfiguriert werden:

  • Die Startkonfiguration ermöglicht es Ihnen, Skalierungsauslöser auszuwählen und Parameter für diese zu beschreiben.
  • Mit der manuellen Skalierung können Sie die minimale und maximale Anzahl von Instanzen, Verfügbarkeitszonen und die Skalierungsruhephasen festlegen.
  • Mit der automatischen Skalierung können Sie messwertbasierte Parameter einrichten. Zu den unterstützten Auslösern gehören: Netzwerk eingehend/ausgehend, CPU-Auslastung, Laufwerk lesen/schreiben und Vorgänge/Byte, Latenz, Anzahl der Anfragen, Anzahl der fehlerfreien/fehlerhaften Hosts.
  • Die zeitbasierte Skalierung ermöglicht es Ihnen, Instanzen basierend auf Ihrer Vorhersage auf einer wiederkehrenden Basis oder einem geplanten einmaligen Ereignis herunter- oder hochzuskalieren. Sie können dabei die maximale, minimale und/oder eine gewünschte Anzahl von Instanzen festlegen.

Die Standardumgebung von App Engine bietet drei Skalierungsoptionen:

  • Die Startkonfiguration ermöglicht es Ihnen, eine Skalierungsoption auszuwählen und Parameter zu beschreiben.
  • Mit der manuellen Skalierung können Sie beim Start die Anzahl der Instanzen für den Dienst festlegen.
  • Mit der grundlegenden Skalierung können Sie die maximale Anzahl von Instanzen und die Leerlaufzeit festlegen, nach deren Ablauf die Instanz nach Erhalt der letzten Anfrage heruntergefahren wird.
  • Mit der automatischen Skalierung können Sie die Mindest- und Höchstwerte für die Anzahl der Instanzen, Latenz und gleichzeitigen Verbindungen für einen Dienst festlegen.

Die flexible Umgebung von App Engine bietet folgende Skalierungsoptionen:

  • Die Startkonfiguration ermöglicht es Ihnen, eine Skalierungsoption auszuwählen und Parameter zu beschreiben.
  • Die manuelle Skalierung funktioniert genauso wie in der App Engine-Standardumgebung.
  • Mit der automatischen Skalierung können Sie eine minimale und maximale Anzahl von Instanzen, die Cool-down-Zeit und die Ziel-CPU-Auslastung festlegen.

Anwendungsupgrades und A/B-Tests

Die Schritte für die Bereitstellung oder Aktualisierung einer Anwendung sind in AWS Elastic Beanstalk und App Engine identisch:

  1. Beschreiben Sie Ihre Anwendung in einer Konfigurationsdatei.
  2. Stellen Sie die neue Version mithilfe eines Befehlszeilentools bereit.

Beide Dienste ermöglichen auch eine Bereitstellung über ihre Verwaltungskonsolen.

Bei AWS Elastic Beanstalk kann die Durchführung von direkten Aktualisierungen zu einem kurzen Ausfall der Anwendung führen. Um Ausfallzeiten zu vermeiden, können Sie eine Blau-/Grün-Bereitstellung durchführen, bei der Sie die neue Version in einer separaten Umgebung bereitstellen und anschließend Umgebungs-URLs austauschen. Sie können nur eine aktive Version pro Umgebung bereitstellen. Eine gewichtete Round-Robin-Verteilung ist mit einem DNS-basierten Ansatz möglich.

Mit App Engine können Sie Updates für die aktuelle Version ohne Ausfallzeit ausführen, eine neue Version erstellen und zu dieser wechseln. Sie können durch entsprechende Konfiguration Ihrer App Engine-Anwendung auch den Traffic basierend auf der IP-Adresse des Senders oder auf einem Cookie aufteilen. Außerdem haben Sie die Möglichkeit, mehrere Versionen pro Dienst und Anwendung bereitzustellen.

Debugging

Zur Fehlerbehebung können Sie in der AWS Elastic Beanstalk-Konsole auf den Instanzen in Ihrer Entwicklungsumgebung einen AWS X-Ray-Daemon ausführen. Dieser Daemon sammelt Daten über Anfragen an Server und die Zusammenarbeit von Anwendungen mit anderen Diensten. Sie können eine Zuordnung der Dienste erstellen, mit der Sie Probleme in Ihrer Anwendung beheben und nach Möglichkeiten zur Optimierung suchen können.

In Google Cloud können Sie Cloud Debugger verwenden, um den Status einer App Engine-Anwendung an einer beliebigen Position im Code zu prüfen. Dabei müssen Sie keine Logging-Anweisungen verwenden und Ihre Anwendungen werden weder beendet noch verlangsamt. Während der Fehlerbehebung kommt es für Nutzer nicht zu Leistungseinbußen. Wenn Sie den Debugger in der Produktion verwenden, können Sie die lokalen Variablen und den Aufrufstapel erfassen und diese Variablen an eine bestimmte Zeilenposition in Ihrem Quellcode zurückverlinken. Mit dem Debugger lässt sich auch der Produktionsstatus Ihrer Anwendung analysieren und das Verhalten des Programmcodes in der Produktion nachvollziehen.

Monitoring

Das Monitoring von AWS Elastic Beanstalk-Umgebungen in der AWS Management Console besteht aus Basismesswerten wie CPU-Auslastung und Netzwerkeingang bzw. -ausgang. Amazon CloudWatch fügt den Umgebungszustand sowie grundlegende EC2-Monitoring-Messwerte für die zugrunde liegenden Instanzen hinzu. Der Nutzer kann auch Alarme für jeden dieser Messwerte hinzufügen. Alle EC2-Instanzen generieren Logs, die Sie zur Fehlerbehebung bei Anwendungen verwenden können.

Das Monitoring von App Engine-Anwendungen im Dashboard der Google Cloud Console bietet Einblick in Parameter wie Gesamtzahl der Anfragen, CPU- und Speicherauslastung, Latenz und Instanzlaufzeit. Mit der Operations-Suite von Google Cloud können Sie Benachrichtigungen für verschiedene Parameter erstellen und Logs speichern.

Netzwerk

Mit AWS Elastic Beanstalk können Sie die Konnektivität von AWS-Ressourcen nach Umgebung verwalten. Sie können Elastic Beanstalk auffordern, EC2-VMs an eine bestimmte VPC anzuhängen und Sicherheitsgruppen für diese Instanzen zu konfigurieren. Dadurch können Elastic Beanstalk-Anwendungen eine Transparenz der Netzwerkverbindung erzielen, die der flexiblen App Engine-Umgebung ähnelt.

Die App Engine-Standardumgebung abstrahiert die Netzwerkkonfiguration. Die einzigen für Ihre Arbeit relevanten netzwerkbezogenen Einstellungen gelten für das Load-Balancing und den benutzerdefinierten Domainnamen der externen Adresse Ihrer Anwendung. Sie können auch einen DOS-Schutzdienst einrichten und dafür mit der Datei dos.yaml eine "schwarze Liste" für das Netzwerk erstellen. Wird diese zusammen mit Ihrer Anwendung bereitgestellt, wird in App Engine eine Fehlerseite bei Anfragen aus verbotenen IP-Bereichen angezeigt.

Die flexible App Engine-Umgebung verwendet für das Hosten Ihrer Anwendung in Docker-Containern virtuelle Compute Engine-Maschinen (VMs). Sie haben folgende Möglichkeiten:

  • Konfigurieren Sie VMs, die in der flexiblen App Engine-Umgebung verwaltet werden, um sie VPC-Netzwerken hinzuzufügen. VPC-Netzwerke können im selben Projekt wie die Flex-Anwendung enthalten oder für mehrere Projekte freigegeben sein.
  • Konfigurieren Sie VPC-Netzwerke mit Instanzen der flexiblen App Engine-Umgebung, um sie über Cloud VPN mit anderen Zielen zu verbinden.
  • Wenden Sie mithilfe von Instanztags Firewalleinstellungen auf Instanzen der flexiblen App Engine-Umgebung an.
  • Ordnen Sie Netzwerk-Ports in Flex-Instanzen den Docker-Container-Ports zum Debuggen und zur Profilerstellung zu.

Diese Flexibilität vereinfacht das Erstellen von Anwendungen in der flexiblen App Engine-Umgebung, die eine transparente Verbindung mit anderen Diensten benötigen, die in Google Cloud oder außerhalb davon (lokal oder in einer anderen Cloud) ausgeführt werden.

Kosten

AWS berechnet keine zusätzlichen Gebühren für Elastic Beanstalk. Sie zahlen nur für zugrunde liegende EC2-Instanzen und andere Ressourcen.

Für die App Engine-Standardumgebung werden Gebühren für ausgeführte Instanzen pro Minute berechnet. Die Abrechnung beginnt, wenn eine Instanz startet, und endet 15 Minuten nachdem eine manuelle Instanz heruntergefahren wurde oder 15 Minuten nachdem eine einfache Instanz die Verarbeitung der letzten Anfrage abgeschlossen hat. Inaktive Instanzen, die die in den Leistungseinstellungen angegebene maximale Anzahl inaktiver Instanzen überschreiten, werden nicht berechnet. Es steht auch ein kostenloses Kontingent zur Verfügung: 28 kostenlose Instanzstunden pro Tag für Autoscaling-Module und 9 kostenlose Instanzstunden pro Tag für einfache und manuelle Skalierungsmodule.

In der flexiblen App Engine-Umgebung werden Gebühren für die Ressourcen der von Ihnen angegebenen virtuellen Maschinentypen berechnet. Die Kosten werden anhand der Nutzung folgender Parameter ermittelt:

  • vCPU (pro Kernstunde)
  • Speicher (pro GB-Stunde)
  • Nichtflüchtiger Speicher (pro GB und Monat)

Die Berechnung dieser Gebühren erfolgt pro Minute, mit einer Mindestzeit von zehn Nutzungsminuten.

Weitere Informationen finden Sie auf der Seite Compute Engine-Preise. Mit dem Google Cloud-Preisrechner können Sie die geschätzten Kosten für Ihre spezifische Arbeitslast ermitteln.

CaaS-Vergleich

Für CaaS bietet AWS Amazon EC2 Container Service (ECS) und Google Cloud Google Kubernetes Engine.

GKE und Amazon ECS haben sehr ähnliche Dienstmodelle. Bei jedem Dienst erstellen Sie einen Cluster mit Containerknoten. Jeder Knoten ist eine VM-Instanz und in jeder Instanz wird ein Knoten-Agent ausgeführt, der die Aufnahme in den Cluster anzeigt. Auf jedem Knoten wird auch ein Container-Daemon wie Docker gestartet, damit auf dem Knoten Container-Anwendungen ausgeführt werden können. Sie erstellen ein Docker-Image, das sowohl Ihre Anwendungsdateien als auch die Anleitung für die Ausführung Ihrer Anwendung enthält. Anschließend stellen Sie die Anwendung in Ihrem Cluster bereit.

Amazon ECS wird von Amazon entwickelt und gewartet. Google Kubernetes Engine basiert auf Kubernetes, einem Open-Source-System zur Containerverwaltung.

Auf übergeordneter Ebene lassen sich die Begriffe und Konzepte von Amazon ECS jenen von GKE folgendermaßen zuordnen:

Funktion Amazon ECS GKE
Clusterknoten Amazon EC2-Instanzen Compute Engine-Instanzen
Unterstützte Daemons Docker Docker oder rkt
Knoten-Agent Amazon ECS-Agent Kubelet
Containergruppe Aufgabe Pod
Dienst für die Bereitstellungsgröße Dienst Replikations-Controller
Befehlszeilentool Amazon ECS-Befehlszeile kubectl oder gcloud
Portabilität Läuft nur auf AWS Läuft überall dort, wo Kubernetes läuft

Plattformkomponenten

Cluster

Sowohl in Amazon ECS als auch in GKE ist ein Cluster eine logische Gruppierung von VM-Knoten. In Amazon ECS nutzt ein Cluster Amazon EC2-Instanzen als Knoten. Zum Erstellen eines Clusters müssen Sie lediglich einen Namen für den Cluster angeben. Amazon ECS erstellt dann den entsprechenden Cluster. Dieser Cluster ist jedoch standardmäßig leer. Bevor Ihre Anwendung gestartet werden kann, müssen Sie in diesem Cluster Containerinstanzen starten.

In GKE nutzt ein Cluster Compute Engine-Instanzen als Knoten. Zum Erstellen eines Clusters müssen Sie zuerst eine Basiskonfiguration für die gewünschten Werte angeben. Dazu gehören folgende Elemente:

  • Clustername
  • Bereitstellungszonen
  • Compute Engine-Maschinentypen
  • Clustergröße

Nachdem Sie Ihren Cluster konfiguriert haben, erstellt GKE den Cluster in der oder den gewünschten Zonen.

Containergruppen

Sowohl Amazon ECS als auch GKE gruppieren mehrere interdependente oder verknüpfte Container in übergeordneten Diensteinheiten. In Amazon ECS werden diese Einheiten Aufgaben genannt und durch Aufgabendefinitionen festgelegt. In GKE werden diese Einheiten als Pods bezeichnet und durch eine PodSpec definiert. Sowohl bei Aufgaben als auch bei Pods werden Container am selben Standort gespeichert sowie gemeinsam geplant und in einem gemeinsamen Kontext mit gemeinsamer IP-Adresse und gemeinsamem Portraum ausgeführt.

Container-Daemons

Jede Knoten-Maschine muss einen Container-Daemon ausführen, um Containerdienste zu unterstützen. Amazon ECS unterstützt Docker als Container-Daemon. Google Kubernetes Engine unterstützt sowohl Docker als auch rkt.

Knoten-Agents

Bei Amazon ECS führt jeder Amazon EC2-Knoten einen Amazon ECS-Agent aus, der Container für Amazon ECS startet. Bei GKE führt auf ähnliche Weise jeder GKE-Knoten ein Kubelet aus, das die Integrität und Stabilität der Container, die auf dem Knoten ausgeführt werden, gewährleistet.

Diensterkennung

Amazon ECS bietet kein natives Verfahren zur Diensterkennung in einem Cluster. Als Behelfslösung können Sie einen Drittanbieterdienst wie Consul zur Diensterkennung konfigurieren, um diese in einem bestimmten Cluster zu aktivieren.

GKE-Cluster ermöglichen die Diensterkennung mithilfe des Kubernetes DNS-Add-ons, das standardmäßig aktiviert ist. Jedem Kubernetes-Dienst wird eine virtuelle IP-Adresse zugewiesen, die so lange gültig bleibt, wie der Dienst vorhanden ist. Der DNS-Server überwacht die Kubernetes API auf neue Dienste und erstellt gegebenenfalls eine Reihe von DNS-Einträgen für jeden Dienst. Durch diese Einträge können Kubernetes-Pods die Namensauflösung von Kubernetes-Diensten automatisch ausführen.

Planung

Amazon ECS unterstützt nur seinen nativen Planer.

GKE ist auf Kubernetes aufgebaut, einer modularen Architektur. Daher ist GKE vollständig kompatibel mit dem Kubernetes-Planer. Dieser ist Open Source und kann in jeder Umgebung ausgeführt werden, in der Kubernetes verwendet werden kann.

Bereitstellungsautomatisierung

In Amazon ECS können Sie ein Skript erstellen, um Aufgaben auf jedem Knoten bereitzustellen. Diese Funktion ist jedoch nicht in den Dienst eingebunden.

In GKE können Sie mithilfe eines DaemonSets eine Kopie eines bestimmten Pods auf jedem Knoten in einem Cluster ausführen. Wenn Knoten dem Cluster hinzugefügt oder aus dem Cluster entfernt werden, kopiert DaemonSet den Pod automatisch auf neue Knoten oder bereinigt die alten. Wenn Sie DaemonSet löschen, werden alle Pods bereinigt, die damit erstellt wurden.

Laufwerksverwaltung

Da Laufwerke in Amazon ECS immer zu einem Host gehören, kann ein Container, der mit einem bestimmten Laufwerk verbunden ist, nicht zu einem anderen Host verschoben werden.

Im Gegensatz dazu kann GKE Laufwerke dynamisch auf einem Knoten bereitstellen und die Laufwerke automatisch einem bestimmten Pod zuweisen. Sie müssen einen Pod nicht auf einem bestimmten Knoten ausführen, um ein bestimmtes Laufwerk verwenden zu können.

Identitäts- und Zugriffsverwaltung

Amazon ECS ist vollständig in AWS Identity and Access Management (IAM) eingebunden. GKE unterstützt den IAM-Dienst von Google Cloud derzeit nicht.

Mehrinstanzenfähigkeit

Mehrinstanzenfähigkeit können Sie in Amazon ECS durch Erstellung von separaten Clustern herstellen. Dazu müssen Sie AWS IAM manuell konfigurieren, um die Nutzung auf jedem Cluster zu beschränken.

Im Gegensatz dazu unterstützt GKE Namespaces, mit denen Nutzer Cluster logisch gruppieren und einen Bereich angeben können, um mandantenfähige Cluster zu unterstützen. Namespaces ermöglichen Folgendes:

  • Das Erstellen von mehreren Nutzer-Communities auf einem einzigen Cluster
  • Die Übertragung von Befugnissen für Partitionen des Clusters auf vertrauenswürdige Nutzer
  • Die Begrenzung der Ressourcen, die jede Community verbrauchen kann
  • Die Begrenzung von verfügbaren Ressourcen auf die Ressourcen, die für eine bestimmte Nutzer-Community relevant sind
  • Die Isolation der Ressourcen, die von einer bestimmten Nutzer-Community verwendet werden, von anderen Nutzer-Communities auf dem Cluster

Systemdiagnosen

In Amazon ECS können Sie mithilfe von Amazon ELB-Systemdiagnosen Fehler ermitteln. Amazon ELB führt Systemdiagnosen über HTTP/TCP aus. Für Systemdiagnosen müssen alle containerisierten Dienste – auch solche, die sonst keinen TCP-Port überwachen müssen – einen HTTP-Server einrichten. Zusätzlich muss jeder Dienst an einen ELB gebunden sein, auch wenn für den Dienst sonst kein Load-Balancing erforderlich ist.

In GKE können Sie Systemdiagnosen mithilfe von Bereitschafts- und Aktivitätsprüfungen ausführen:

  • Bereitschaftsprüfungen erlauben es Ihnen, den Status eines Pods während der Initialisierung zu überprüfen.
  • Aktivitätsprüfungen ermöglichen es, Pods, die nicht mehr ordnungsgemäß funktionieren, zu erkennen und neu zu starten.

Diese Prüfungen sind in der Kubernetes API enthalten und können als Teil einer PodSpec konfiguriert werden.

Portabilität

Da der Amazon ECS-Agent nur auf Amazon EC2-Instanzen ausgeführt werden kann, lassen sich Amazon ECS-Konfigurationen letztendlich nur auf Amazon ECS ausführen. Im Gegensatz dazu können Kubernetes Engine-Konfigurationen für jede Kubernetes-Installation ausgeführt werden, da GKE auf Kubernetes aufbaut.

Kosten

Amazon berechnet Gebühren für die Amazon EC2-Instanzen und das Amazon EBS-Laufwerksvolumen, die Sie in Ihrer Bereitstellung nutzen. Es entstehen keine weiteren Kosten für den Container-Verwaltungsdienst von Amazon ECS.

Bei Google Cloud fallen Gebühren für die Compute Engine-Instanzen und den nichtflüchtigen Speicher an, den Sie in Ihrer Bereitstellung verwenden. Zusätzlich werden in GKE stundenweise Gebühren für die Clusterverwaltung erhoben. Bei Clustern mit fünf oder weniger Knoten entstehen dafür keine Kosten. Weitere Informationen finden Sie unter GKE-Preise.

Weitere Informationen

Weitere Artikel zu Google Cloud für AWS-Experten: