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

Question

Ich habe mich gefragt, was der Unterschied zwischen App Engine & Compute Engine ist. Kann mir das jemand erklären?

Answer 1

App Engine ist eine Plattform als Service. Das bedeutet, dass Sie einfach Ihren Code bereitstellen und die Plattform alles andere für Sie erledigt. Wenn Ihre App zum Beispiel sehr erfolgreich wird, erstellt App Engine automatisch mehr Instanzen, um das erhöhte Volumen zu bewältigen.

Lesen Sie mehr über App Engine

Compute Engine ist eine Infrastruktur als Service. Sie müssen Ihre eigenen virtuellen Maschinen erstellen und konfigurieren. Es bietet Ihnen mehr Flexibilität und kostet im Allgemeinen viel weniger als App Engine. Der Nachteil ist, dass Sie Ihre App und virtuellen Maschinen selbst verwalten müssen.

Lesen Sie mehr über Compute Engine

Sie können sowohl App Engine als auch Compute Engine mischen, falls erforderlich. Beide funktionieren gut mit den anderen Teilen der Google Cloud Platform.

EDIT (Mai 2016):

Noch eine wichtige Unterscheidung: Projekte, die auf App Engine laufen, können auf null Instanzen herunterskalieren, wenn keine Anfragen eingehen. Dies ist äußerst nützlich in der Entwicklungsphase, da Sie wochenlang ohne Überschreiten des großzügigen kostenlosen Kontingents an Instanz-Stunden auskommen können. Die flexible Laufzeit (d.h. "managed VMs") erfordert mindestens eine ständig laufende Instanz.

EDIT (April 2017):

Cloud Functions (derzeit im Beta-Test) ist der nächste Schritt von App Engine in Bezug auf die Abstraktion - keine Instanzen! Es ermöglicht Entwicklern, kleinere Code-Schnipsel bereitzustellen, die als Reaktion auf verschiedene Ereignisse ausgeführt werden, darunter HTTP-Anfragen, Änderungen in Cloud Storage usw.

Der größte Unterschied zu App Engine besteht darin, dass Functions pro 100 Millisekunden abgerechnet werden, während die Instanzen von App Engine erst nach 15 Minuten Inaktivität heruntergefahren werden. Ein weiterer Vorteil ist, dass Cloud Functions sofort ausgeführt werden, während ein Aufruf an App Engine eine neue Instanz erfordern kann - und das Kaltstarten einer neuen Instanz kann einige Sekunden oder länger dauern (je nach Laufzeit und Ihrem Code).

Dies macht Cloud Functions ideal für (a) seltene Aufrufe - kein Bedarf, eine Instanz nur für den Fall am Leben zu halten, dass etwas passiert, (b) sich schnell ändernde Lasten, bei denen Instanzen häufig gestartet und heruntergefahren werden, und möglicherweise mehr Anwendungsfälle.

Lesen Sie mehr über Cloud Functions

Answer 2

Der grundlegende Unterschied besteht darin, dass Google App Engine (GAE) ein Platform as a Service (PaaS) ist, während Google Compute Engine (GCE) ein Infrastructure as a Service (IaaS) ist.

Um Ihre Anwendung in GAE auszuführen, müssen Sie einfach Ihren Code schreiben und in GAE bereitstellen, keine anderen Sorgen. Da GAE vollständig skalierbar ist, werden automatisch mehr Instanzen erworben, falls der Datenverkehr steigt, und die Instanzen verringern sich, wenn der Datenverkehr abnimmt. Sie werden nur für die Ressourcen berechnet, die Sie wirklich verwenden, also werden Sie für die Instance-Stunden, übertragene Daten, Speicher usw. berechnet, die Ihre App wirklich genutzt hat. Die Einschränkung besteht darin, dass Sie Ihre Anwendung nur in Python, PHP, Java, NodeJS, .NET, Ruby und **Go erstellen können.

Andererseits bietet Ihnen GCE die volle Infrastruktur in Form einer virtuellen Maschine. Sie haben die vollständige Kontrolle über die Umgebung und Laufzeit dieser VMs, da Sie dort Programme schreiben oder installieren können. Tatsächlich ist GCE der Weg, um die Google-Datenzentren virtuell zu nutzen. In GCE müssen Sie Ihre Infrastruktur manuell konfigurieren, um die Skalierbarkeit mit Hilfe eines Load Balancers zu handhaben.

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

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

Answer 3

Einfach ausgedrückt: Der Compute Engine bietet Ihnen einen Server, für den Sie die volle Kontrolle/Verantwortung haben. Sie haben direkten Zugriff auf das Betriebssystem und können alle Software installieren, die Sie möchten, normalerweise einen Webserver, eine Datenbank usw...

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

App Engine erspart eine Menge Kopfschmerzen, insbesondere für unerfahrene Personen, hat jedoch zwei wesentliche Nachteile: 1. teurer (hat jedoch ein kostenloses Kontingent, das die Compute Engine nicht hat) 2. Sie haben weniger Kontrolle, sodass bestimmte Dinge einfach nicht möglich sind oder nur auf eine bestimmte Weise möglich sind (zum Beispiel das Speichern und Schreiben von Dateien).

Answer 4

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 zum Beispiel eine kleine Website + Datenbank bereitstellen würden. Sie verwalten alles, einschließlich der Kontrolle über installierte Festplatten. Wenn Sie eine Website bereitstellen, sind Sie für das Einrichten von DNS usw. verantwortlich.

Google App Engine (Standard) ist wie ein schreibgeschützter abgeschotteter Ordner, in den Sie Code hochladen, um ihn auszuführen, ohne sich um den Rest kümmern zu müssen (ja: schreibgeschützt - es sind eine feste Reihe von Bibliotheken installiert, und Sie können nicht nach Belieben Bibliotheken von Drittanbietern bereitstellen). Das Zuordnen von DNS / Subdomains usw. ist so viel einfacher.

Google App Engine (Flexible) ist tatsächlich wie ein ganzes Dateisystem (nicht nur ein gesperrter Ordner), in dem Sie mehr Macht haben als beim Standard-Motor, z. B. haben Sie Lese-/Schreibberechtigungen (aber weniger im Vergleich zu einem Compute Engine). Im GAE-Standard sind eine feste Reihe von Bibliotheken für Sie installiert, und Sie können nicht nach Belieben Bibliotheken von Drittanbietern bereitstellen. In der flexiblen Umgebung können Sie jede Bibliothek installieren, von der Ihre App abhängt, einschließlich individueller Entwicklungsumgebungen (wie Python 3).

Obwohl GAE Standard sehr umständlich zu handhaben ist (obwohl Google es einfach erscheinen lässt), skaliert es sehr gut unter Druck. Es ist umständlich, weil Sie die Kompatibilität mit der gesperrten Umgebung testen und sicherstellen müssen und sicherstellen, dass keine anderen Bibliotheken von Drittanbietern verwendet werden, die auf GAE Standard möglicherweise nicht funktionieren. Es dauert in der Praxis länger, es einzurichten, kann aber langfristig für einfache Bereitstellungen lohnender sein.

Answer 5

Zusätzlich zu den oben genannten Notizen zu App Engine vs. Compute Engine enthält die Liste hier auch einen Vergleich mit Google Kubernetes Engine und einige Anmerkungen basierend auf Erfahrungen mit einer Vielzahl von Apps von klein bis sehr groß. Für weitere Punkte siehe die Google Cloud Platform-Dokumentation hochrangige Beschreibung der Funktionen in App Engine Standard und Flex auf der Seite Choosing an App Engine Environment. Für einen weiteren Vergleich der Bereitstellung von App Engine und Kubernetes siehe den Beitrag von Daz Wilkin App Engine Flex or Kubernetes Engine.

App Engine Standard

Vorteile

• Sehr wirtschaftlich für Apps mit wenig Traffic in Bezug auf direkte Kosten und auch die Kosten für die Wartung der App.
• Das automatische Skalieren ist schnell. Das Autoscaling in App Engine basiert auf leichten Instanzklassen F1-F4.
• Versionenverwaltung und Traffic-Aufteilung sind schnell und bequem. Diese Funktionen sind in App Engine (Standard und Flex) nativ integriert.
• Minimales Management, Entwickler müssen sich nur auf ihre App konzentrieren. Entwickler müssen sich keine Gedanken darüber machen, VMs in einer zuverlässigen, wie in GCE, zu verwalten, oder über Cluster, wie bei GKE, zu lernen.
• Der Zugriff auf Datastore ist schnell. Als App Engine erstmalig veröffentlicht wurde, war die Laufzeit mit Datastore zusammengelegt. Später wurde Datastore als eigenständiges Produkt Cloud Datastore aufgeteilt, aber die Kollokation von App Engine Standard mit Datastore bleibt bestehen.
• Der Zugriff auf Memcache wird unterstützt.
• Die App Engine-Sandbox ist sehr sicher. Im Vergleich zur Entwicklung auf GCE oder anderen virtuellen Maschinen, wo Sie Ihre eigenen Anstrengungen unternehmen müssen, um zu verhindern, dass die virtuelle Maschine auf Betriebssystemebene übernommen wird, ist die App Engine Standard-Sandbox standardmäßig relativ sicher.

Nachteile

• Allgemein enger begrenzt als andere Umgebungen. Die Instanzen sind kleiner. Obwohl dies für schnelles Autoscaling gut ist, können viele Apps von größeren Instanzen profitieren, wie z.B. GCE-Instanzgrößen mit bis zu 96 Kernen.
• Die Netzwerkintegration ist nicht mit GCE integriert
• App Engine kann nicht hinter einem Google Cloud Load Balancer platziert 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 gibt es zwar einige Unterstützung für Servlets, aber nicht den vollständigen J2EE-Standard.

App Engine Flex

Vorteile

• Kann eine benutzerdefinierte Laufzeit verwenden
• Native Integration mit GCE-Netzwerken
• Version- und Traffic-Management ist bequem, wie bei Standard
• Die größeren Instanzgrößen sind möglicherweise besser geeignet für große komplexe Anwendungen, insbesondere Java-Anwendungen, die viel Speicherplatz nutzen können

Nachteile

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

Google Kubernetes Engine

Vorteile

• Native Integration mit Containern ermöglicht benutzerdefinierte Laufzeiten und mehr Kontrolle über Clusterkonfiguration.
• Verkörpert viele bewährte Methoden bei der Arbeit mit virtuellen Maschinen, wie unveränderbaren Laufzeitumgebungen und einfacher Möglichkeit zur Rückkehr zu früheren Versionen
• Bietet ein konsistentes und wiederholbares Bereitstellungsframework
• Basiert auf offenen Standards, insbesondere Kubernetes, für Portabilität zwischen Clouds und On-Premises.
• Versionmanagement kann mit Docker-Containern und dem Google Container Registry durchgeführt werden

Nachteile

• Traffic-Aufteilung und -Management erfolgen selbstständig, möglicherweise unter Nutzung von Istio und Envoy
• Ein gewisser Verwaltungsaufwand
• Etwas Zeit, um sich mit Kubernetes-Konzepten wie Pods, Bereitstellungen, Diensten, Ingress und Namensräumen vertraut zu machen
• Einige öffentliche IPs exposen müssen, es sei denn, Sie verwenden Private Clusters, jetzt in der Beta-Version, die diese Notwendigkeit beseitigen, aber Sie müssen immer noch Zugang zu den Standorten gewähren, von wo aus kubectl-Befehle ausgeführt werden.
• Monitoring-Integration nicht perfekt
• Während L3 interne Lastenausgleich nativ auf Kubernetes Engine unterstützt wird, muss der L7 interne Lastenausgleich selbstständig durchgeführt werden, möglicherweise unter Nutzung von Envoy

Compute Engine

Vorteile

• Einfach einzufahren - keine Notwendigkeit, sich mit Kubernetes oder App Engine vertraut zu machen, sondern einfach das wiederverwenden, was Sie aus früheren Erfahrungen wissen. Dies ist wahrscheinlich der Hauptgrund für die direkte Nutzung von Compute Engine.
• Vollständige Kontrolle - Sie können viele Compute Engine-Funktionen direkt nutzen und die neuesten Ihrer Lieblingsinhalte installieren, um auf dem neuesten Stand zu bleiben.
• Keine Notwendigkeit für öffentliche IPs. Einige Legacy-Software kann zu schwierig zu sperren sein, wenn etwas auf öffentlichen IPs freigelegt ist.
• Sie können das Container-Optimized OS nutzen, um Docker-Container auszuführen

Nachteile

• Hauptsächlich Selbstverwaltung, was eine Herausforderung sein kann, um Zuverlässigkeit und Sicherheit sicherzustellen, obwohl Sie Lösungen aus verschiedenen Quellen wiederverwenden können, einschließlich des Cloud Launcher.
• Mehr Verwaltungsaufwand. Es gibt viele Verwaltungstools für Compute Engine, aber sie werden nicht unbedingt verstehen, wie Sie Ihre Anwendung bereitgestellt haben, wie es die App Engine- und Kubernetes Engine-Überwachungstools tun
• Das Autoscaling basiert auf GCE-Instanzen, was langsamer sein kann als bei App Engine
• Die Tendenz ist es, Software auf Snowflake-GCE-Instanzen zu installieren, was einige Mühe erfordern kann, um diese zu pflegen