Was ist der Unterschied zwischen Google App Engine und Google Compute Engine?

Der grundlegende Unterschied besteht darin, dass Google App Engine ( GAE ) ein Plattform als Dienst (PaaS) während Google Compute Engine ( GCE ) ist eine Infrastruktur als Service (IaaS) .

Um Ihre Anwendung in GAE auszuführen, müssen Sie nur Ihren Code schreiben und in GAE implementieren, ohne weitere Probleme. Da GAE vollständig skalierbar ist, werden automatisch mehr Instanzen erfasst, falls der Datenverkehr zunimmt, und die Instanzen werden verringert, wenn der Datenverkehr abnimmt. Ihnen werden die Ressourcen in Rechnung gestellt, die Siewirklich nutzen, ich meine, Ihnen werden dieInstance-Hours,Übertragene Daten,Speicheretc Ihre App wirklich verwendet. Die Einschränkung ist jedoch, dass Sie Ihre Anwendung nur inPython, PHP, Java, NodeJS, .NET, Ruby und ** Goerstellen können. /.

Andererseits bietet Ihnen GCE die vollständige Infrastruktur in Form vonVirtual Machine. Sie haben die vollständige Kontrolle über die Umgebung und Laufzeit dieser VMs, da Sie dort jedes Programm schreiben oder installieren können. Tatsächlich ist GCE die Möglichkeit, Google Data Center virtuell zu nutzen. In GCE müssen Sie Ihre Infrastruktur manuell konfigurieren, umscalabilityzu verarbeiten, indem SieLoad Balancerverwenden.

Sowohl GAE als auch GCE sind Teil von Google Cloud Platform .

Update:Im März 2014 kündigte Google einen neuen Dienst unter App Engine mit dem NamenManaged Virtual Machinean. Managed VMs bieten App Engine-Anwendungen ein bisschen mehr Flexibilität in Bezug auf App-Plattform, CPU und Speicheroptionen. Wie bei GCE können Sie in diesen VMs für App Engine-Anwendungen eine benutzerdefinierte Laufzeitumgebung erstellen. Tatsächlich verwaltete VMs von App Engine verwischen in gewissem Maße die Grenze zwischen IAAS und PAAS.

Einfach ausgedrückt: Compute Engine gibt Ihnen einen Server, für den Sie die volle Kontrolle/Verantwortung haben. Sie haben direkten Zugriff auf das Betriebssystem und installieren die gesamte gewünschte Software, bei der es sich normalerweise um einen Webserver, eine Datenbank usw. handelt.

In der App Engine verwalten Sie nicht das Betriebssystem einer der zugrunde liegenden Software. Sie laden nur Code (Java, PHP, Python oder Go) und voila hoch - es läuft einfach ...

Die App-Engine spart Unmengen an Kopfschmerzen, insbesondere für unerfahrene Benutzer. Sie weist jedoch zwei erhebliche Nachteile auf: 1. Sie ist teurer (es gibt jedoch eine kostenlose Quote, die die Computing-Engine nicht bietet). 2. Sie haben weniger Kontrolle, sodass bestimmte Dinge einfach nicht möglich sind möglich oder nur auf eine bestimmte Weise möglich (z. B. Speichern und Schreiben von Dateien).

Oder um es noch einfacher zu machen (da wir manchmal nicht zwischen GAE Standard und GAE Flex unterscheiden können):

Compute Engine ist analog zu einem virtuellen PC, auf dem Sie beispielsweise eine kleine Website + Datenbank bereitstellen würden. Sie verwalten alles, einschließlich der Steuerung der installierten Festplatten. Wenn Sie eine Website bereitstellen, müssen Sie DNS usw. einrichten.

Google App Engine (Standard) ist wie ein schreibgeschützter Sandkastenordner, in den Sie Code hochladen, aus dem Sie ihn ausführen können, und sich nicht um den Rest kümmern (ja: schreibgeschützt - es gibt einen festen Satz von Bibliotheken) installiert und Sie können keine Bibliotheken von Drittanbietern nach Belieben bereitstellen. DNS/Sub-Domains usw. sind viel einfacher zuzuordnen.

Google App Engine (Flexibel) ist in der Tat wie ein ganzes Dateisystem (nicht nur ein gesperrter Ordner), in dem Sie mehr Leistung als in der Standard-Engine haben, z. Sie haben Lese-/Schreibberechtigungen (jedoch weniger im Vergleich zu einer Compute Engine). Im GAE-Standard ist ein fester Satz von Bibliotheken für Sie installiert, und Sie können keine Bibliotheken von Drittanbietern nach Belieben bereitstellen. In der flexiblen Umgebung können Sie jede Bibliothek installieren, von der Ihre App abhängt, einschließlich benutzerdefinierter Erstellungsumgebungen (z. B. Python 3)).

Obwohl GAE Standard sehr umständlich zu handhaben ist (obwohl Google es einfach klingt), lässt es sich sehr gut skalieren, wenn es unter Druck gesetzt wird. Dies ist umständlich, da Sie die Kompatibilität mit der gesperrten Umgebung testen und sicherstellen müssen, dass keine von Ihnen verwendete Bibliothek von Drittanbietern eine andere Bibliothek von Drittanbietern verwendet, die möglicherweise nicht mit dem GAE-Standard kompatibel ist. Das Einrichten in der Praxis dauert länger, kann sich aber auf längere Sicht für einfache Bereitstellungen lohnen.

Neben den Hinweisen zu App Engine und Compute Engine über der Liste finden Sie hier auch einen Vergleich mit Google Kubernete Engine und einige Hinweise, die auf Erfahrungen mit einer Vielzahl von Apps von klein bis sehr groß basieren. Weitere Informationen finden Sie in der Dokumentation zu Google Cloud Platform mit einer allgemeinen Beschreibung der Funktionen in App Engine Standard und Flex auf der Seite Auswählen einer App Engine-Umgebung . Für einen weiteren Vergleich der Bereitstellung von App Engine und Kubernetes siehe den Beitrag von Daz Wilkin App Engine Flex oder Kubernetes Engine .

App Engine Standard

Profis

• Sehr sparsam für Apps mit geringem Datenverkehr in Bezug auf die direkten Kosten und auch die Kosten für die Wartung der App.
• Die automatische Skalierung ist schnell. Die automatische Skalierung in App Engine basiert auf Lightweight Instanzklassen F1-F4 .
• Versionsverwaltung und Traffic Splitting sind schnell und bequem. Diese Funktionen sind nativ in App Engine (sowohl Standard als auch Flex) integriert.
• Minimales Management, Entwickler müssen sich nur auf ihre App konzentrieren. Entwickler müssen sich nicht um die zuverlässige Verwaltung von VMs wie in GCE oder um Cluster wie in GKE kümmern.
• Der Zugriff auf den Datenspeicher ist schnell. Bei der ersten Veröffentlichung von App Engine befand sich die Laufzeitumgebung neben Datastore. Später wurde Datastore als eigenständiges Produkt aufgeteilt Cloud Datastore , aber der gemeinsame Standort von App Engine Standard, der mit Datastore bereitgestellt wird, bleibt erhalten.
• Der Zugriff auf Memcache wird unterstützt.
• Die App Engine-Sandbox ist sehr sicher. Verglichen mit der Entwicklung auf GCE oder anderen virtuellen Maschinen, bei denen Sie Ihre eigene Sorgfalt anwenden müssen, um zu verhindern, dass die virtuelle Maschine auf Betriebssystemebene übernommen wird, ist die App Engine Standard-Sandbox standardmäßig relativ sicher.

Nachteile

• Im Allgemeinen eingeschränkter als in anderen Umgebungen Instanzen sind kleiner. Obwohl dies für eine schnelle automatische Skalierung gut ist, können viele Apps von größeren Instanzen profitieren, z. B. von GCE-Instanzen mit einer Größe von bis zu 96 Kernen.
• Das Netzwerk ist nicht in GCE integriert
• App Engine kann nicht hinter einen Google Cloud Load Balancer gestellt werden. Beschränkt auf unterstützte Laufzeiten: Python 2.7, Java 7 und 8, Go 1.6-1.9 und PHP 5.5. In Java, es gibt eine gewisse Unterstützung für Servlets, aber nicht den vollständigen J2EE-Standard.

App Engine Flex

Profis

• Kann eine benutzerdefinierte Laufzeit verwenden
• Eingeborene Integration in GCE-Netzwerke
• Die Versions- und Verkehrsverwaltung ist genauso komfortabel wie bei Standard
• Die größeren Instanzen eignen sich möglicherweise besser für große komplexe Anwendungen, insbesondere für Java) - Anwendungen, die viel Arbeitsspeicher benötigen

Nachteile

• Die Netzwerkintegration ist nicht perfekt - keine Integration mit internen Load Balancern oder Shared Virtual Private Clouds
• Zugriff auf verwalteten Memcache nicht allgemein verfügbar

Google Kubernetes Engine

Profis

• Die native Integration in Container ermöglicht benutzerdefinierte Laufzeiten und eine bessere Kontrolle über die Clusterkonfiguration.
• Verkörpert viele bewährte Methoden für die Arbeit mit virtuellen Maschinen, z. B. nveränderliche Laufzeitumgebungen und die einfache Möglichkeit, ein Rollback auf frühere Versionen durchzuführen
• Bietet ein konsistentes und wiederholbares Bereitstellungsframework
• Basierend auf offenen Standards, insbesondere Kubernetes, für die Portabilität zwischen Clouds und lokalen Systemen.
• Die Versionsverwaltung kann mit Docker-Containern und der Google Container Registry durchgeführt werden

Nachteile

• Die Aufteilung und Verwaltung des Datenverkehrs erfolgt auf eigene Faust, möglicherweise mithilfe von Istio und Envoy
• Etwas Verwaltungsaufwand
• Einige Zeit, um Kubernetes-Konzepte wie Pods, Bereitstellungen, Dienste, Ingress und Namespaces näher kennenzulernen
• Sie müssen einige öffentliche IP-Adressen offen legen, es sei denn, Sie verwenden Private Cluster , jetzt in der Beta-Version. Sie müssen jedoch weiterhin Zugriff auf Speicherorte gewähren, von denen aus Kubectl-Befehle ausgeführt werden.
• Überwachungsintegration nicht perfekt
• Während der interne L3-Lastausgleich von Haus aus von Kubernetes Engine unterstützt wird, ist der interne L7-Lastausgleich eine Eigenleistung, bei der möglicherweise Envoy zum Einsatz kommt

Compute Engine

Profis

• Einfaches Hochfahren - Kubernetes oder App Engine müssen nicht hochgefahren werden. Verwenden Sie einfach alles, was Sie aus früheren Erfahrungen wissen. Dies ist wahrscheinlich der Hauptgrund für die direkte Verwendung von Compute Engine.
• Volle Kontrolle - Sie können viele Funktionen der Compute Engine direkt nutzen und die neuesten Versionen Ihrer Lieblingssachen installieren, um immer auf dem neuesten Stand zu bleiben.
• Keine Notwendigkeit für öffentliche IPs. Einige ältere Softwareprodukte sind möglicherweise zu schwer zu sperren, wenn öffentliche IP-Adressen betroffen sind.
• Sie können das containeroptimierte Betriebssystem für die Ausführung von Docker-Containern nutzen

Nachteile

• Meistens zum Selbermachen, was aus Gründen der Zuverlässigkeit und Sicherheit schwierig sein kann, obwohl Sie Lösungen von verschiedenen Orten aus, einschließlich des Cloud Launcher, wiederverwenden können.
• Mehr Verwaltungsaufwand. Es gibt viele Verwaltungstools für Compute Engine, die jedoch nicht unbedingt verstehen, wie Sie Ihre Anwendung bereitgestellt haben, wie die Überwachungstools App Engine und Kubernetes Engine
• Die automatische Skalierung basiert auf GCE-Instanzen, die langsamer als App Engine sein können
• Die Tendenz besteht darin, Software auf Snowflake GCE-Instanzen zu installieren, was einige Wartungsarbeiten erfordern kann

App Engine bietet Entwicklern die Möglichkeit, Google Compute Engine-Kerne zu steuern und ein Web-Front-End für Datenverarbeitungsanwendungen von Google Compute Engine bereitzustellen.

Andererseits bietet Compute Engine eine direkte und vollständige Betriebssystemverwaltung Ihrer virtuellen Maschinen. Für die Präsentation Ihrer App benötigen Sie Ressourcen. Google Cloud Storage eignet sich ideal zum Speichern Ihrer Assets und Daten, unabhängig davon, wofür sie verwendet werden. Mit Hosting rund um den Globus erhalten Sie schnellen Datenzugriff. Die Zuverlässigkeit wird bei einer Verfügbarkeit von 99,95% garantiert. Google bietet auch die Möglichkeit, Ihre Daten zu sichern und wiederherzustellen. Ob Sie es glauben oder nicht, der Speicherplatz ist unbegrenzt.

Sie können Ihre Assets mit Google Cloud Storage verwalten, speichern, abrufen, anzeigen und löschen. Sie können auch schnell flache Datenblätter lesen und beschreiben, die im Cloud-Speicher gespeichert sind. Als Nächstes in der Google Cloud-Aufstellung folgt BigQuery. Mit BigQuery können Sie gewaltige Datenmengen analysieren, wir sprechen von Millionen von Datensätzen innerhalb von Sekunden. Der Zugriff wird über eine einfache Benutzeroberfläche oder eine Repräsentationsstatusübertragung oder über die REST Schnittstelle abgewickelt.

Datenspeicherung ist, wie Sie vielleicht vermuten, kein Problem und lässt sich auf Hunderte von TB skalieren. Auf BigQuery kann über eine Vielzahl von Client-Bibliotheken zugegriffen werden, einschließlich derer für Java, .NET, Python, Go, Ruby, PHP und Javascript. Eine SQL-ähnliche Syntax namens NoSQL ist verfügbar, auf die über diese Client-Bibliotheken oder über eine Web-Benutzeroberfläche zugegriffen werden kann. Lassen Sie uns zum Schluss über die Datenbankoptionen der Google Cloud-Plattform, Cloud SQL und Cloud Datastore sprechen.

Es gibt einen großen Unterschied. Cloud SQL ist für relationale Datenbanken vorgesehen, in erster Linie für MySQL, während Cloud Datastore für nicht relationale Datenbanken vorgesehen ist, die noSQL verwenden. Bei Cloud SQL haben Sie die Wahl, entweder in den USA, in Europa oder in Asien mit 100 GB Speicher und 16 GB RAM pro Datenbankinstanz) zu hosten.

Cloud Datastore ist kostenlos für bis zu 50 K Lese-/Schreibanweisungen pro Monat und 1 GB Daten, die auch pro Monat gespeichert werden, verfügbar. Bei Überschreitung dieser Kontingente wird jedoch eine Gebühr erhoben. App Engine kann auch mit weniger bekannten, zielgerichteteren Mitgliedern der Google Cloud-Plattform zusammenarbeiten, einschließlich der Cloud-Endpunkte zum Erstellen von API-Backends, der Google Prediction-API für Datenanalysen und Trendprognosen oder der Google Translate-API für die mehrsprachige Ausgabe.

Mit App Engine können Sie zwar eine ganze Menge selbst erledigen, es kann jedoch schnell gehen, wenn Sie die Fähigkeit berücksichtigen, einfach und effizient mit den anderen Google Cloud-Plattformdiensten zu arbeiten.

Wie bereits erläutert, ist Google Compute Engine (GCE) die Infrastruktur als Dienst (IaaS), während Google App Engine (GAE) Plattform als Dienst (PaaS) ist. Sie können das folgende Diagramm überprüfen, um den Unterschied besser zu verstehen (entnommen aus und besser erklärt hier ) -

Google Compute Engine
GCE ist ein wichtiger Dienst, der von der Google Cloud Platform (GCP) bereitgestellt wird, da die meisten GCP-Dienste GCE-Instanzen (VMs) unterhalb der Verwaltungsebene verwenden (nicht sicher, welche nicht). Dies umfasst App Engine, Cloud-Funktionen, Kubernetes Engine (frühere Container Engine), Cloud SQL usw. GCE-Instanzen sind die am besten anpassbaren Einheiten und sollten daher nur verwendet werden, wenn Ihre Anwendung nicht auf anderen GCP-Diensten ausgeführt werden kann. In den meisten Fällen verwenden Benutzer GCE, um ihre On-Prem-Anwendungen auf GCP zu übertragen, da nur minimale Änderungen erforderlich sind. Später können sie andere GCP-Dienste für eine separate Komponente ihrer Apps verwenden.

Google App Engine
GAE ist der erste von GCP angebotene Dienst (lange bevor Google zum Cloud-Geschäft kam). Es wird automatisch von 0 bis zu unbegrenzt vielen Instanzen skaliert (es verwendet GCE darunter). Es kommt mit 2 Geschmacksrichtungen Standard Environment und Flexible Environment.

Die Standardumgebung ist sehr schnell, skaliert auf 0 Instanzen, wenn niemand Ihre App verwendet, skaliert in Sekunden auf und ab und verfügt über dedizierte Google-Dienste und -Bibliotheken für Caching, Authentifizierung usw. Die Einschränkung bei der Standardumgebung ist, dass sie sehr restriktiv ist da läuft es in einer sandbox. Sie müssen verwaltete Laufzeiten nur für bestimmte Programmiersprachen verwenden. Die jüngsten Ergänzungen sind Node.js (8.x) und Python 3.x). Die älteren Laufzeiten sind für Go, PHP, Python 2.7, = verfügbar Java etc.

Flexible Environment ist offener, da Sie benutzerdefinierte Laufzeiten verwenden können, da Docker-Container verwendet werden. Wenn Ihre Laufzeit in den angegebenen Laufzeiten nicht verfügbar ist, können Sie jederzeit eine eigene Docking-Datei für die Ausführungsumgebung erstellen. Die Einschränkung dabei ist, dass mindestens eine Instanz ausgeführt werden muss, auch wenn niemand Ihre App verwendet, und dass das Vergrößern und Verkleinern einige Minuten dauert.

Verwechseln Sie GAE flexible nicht mit Kubernetes Engine, da das letztere aktuelle Kubernetes verwendet und viel mehr Anpassungsmöglichkeiten und Funktionen bietet. GAE Flex ist nützlich, wenn Sie zustandslose Container benötigen und Ihre Anwendung nur auf HTTP- oder HTTPS-Protokollen basiert. Für andere Protokolle ist Kubernetes Engine (GKE) oder GCE Ihre einzige Wahl. Check meine andere Antwort zur besseren Erklärung.

Ich erkläre es auf eine Weise, die mir Sinn machte:

• Compute Engine: Wenn Sie eine Do-it-yourself-Person sind oder ein IT-Team haben und nur einen Computer in der Cloud mit einem bestimmten Betriebssystem (z. B. Linux) mieten möchten, entscheiden Sie sich für die Compute Engine . Du musst alles alleine machen.

• App Engine: Wenn Sie (zum Beispiel) ein python= Programmierer sind und einen vorkonfigurierten Computer in der Cloud mieten möchten, auf dem Linux ausgeführt wird und auf dem ein Webserver ausgeführt wird und die neueste Version python 3 mit den erforderlichen Modulen und einigen Plug-Ins für die Integration mit anderen externen Diensten, wählen Sie die App Engine.

• Serverless Container (Cloud Run): Wenn Sie das genaue Image Ihrer lokalen Setup-Umgebung bereitstellen möchten (zum Beispiel: python 3.7 + flask + sklearn) aber Sie Ich möchte mich nicht um Server, Skalierung usw. kümmern. Sie erstellen einen Container auf Ihrem lokalen Computer (über Docker) und stellen ihn dann für Google Run bereit.

• Serverless Microservice (Cloud Functions): Wenn Sie eine Reihe von APIs (Funktionen) schreiben möchten, die bestimmte Aufgaben erfüllen, entscheiden Sie sich für Google Cloud Functions. Sie konzentrieren sich nur auf diese spezifischen Funktionen, der Rest der Arbeit (Server, Wartung, Skalierung usw.) wird für Sie erledigt, um Ihre Funktionen als Microservices verfügbar zu machen.

Wenn Sie tiefer gehen, verlieren Sie zwar etwas an Flexibilität, machen sich aber keine Gedanken über unnötige technische Aspekte. Sie zahlen auch ein bisschen mehr, sparen aber Zeit und Kosten (IT-Teil): Jemand anderes (Google) erledigt dies für Sie.

Grundsätzlich ist Google Cloud für mich meine IT- und DevOp-Abteilung. Ich entwickle auf meinem Computer, erstelle einen Container über Docker, stelle ihn für Cloud Run bereit und kümmere mich nicht um Skalierung und Wartung. Ich habe alle anderen Optionen ausprobiert und jede ist für einen anderen Zweck gut.