Qual è la differenza tra Google App Engine e Google Compute Engine?

Mi chiedevo quale fosse la differenza tra App Engine e Compute Engine. Qualcuno può spiegarmi la differenza?

App Engine è una piattaforma come servizio. Significa che devi semplicemente distribuire il tuo codice e la piattaforma fa tutto il resto per te. Ad esempio, se la tua app ha molto successo, App Engine creerà automaticamente più istanze per gestire il volume aumentato.

Ulteriori informazioni su App Engine

Compute Engine è un'infrastruttura come servizio. Devi creare e configurare le tue istanze di macchine virtuali. Ti dà più flessibilità e generalmente costa molto meno di App Engine. Lo svantaggio è che devi gestire tu stesso l'app e le macchine virtuali.

Ulteriori informazioni su Compute Engine

È possibile combinare sia App Engine che Compute Engine, se necessario. Entrambi funzionano bene con le altre parti della piattaforma cloud di Google .

EDIT (maggio 2016):

Un'altra distinzione importante: i progetti in esecuzione su App Engine possono ridimensionarsi a zero istanze se non arrivano richieste. Ciò è estremamente utile in fase di sviluppo in quanto è possibile andare avanti per settimane senza superare la generosa quota gratuita di ore-istanza. Il runtime flessibile (ovvero "VM gestite") richiede almeno un'istanza per essere eseguito costantemente.

EDIT (aprile 2017):

Funzioni cloud (attualmente in versione beta) è il livello successivo da App Engine in termini di astrazione - nessuna istanza! Consente agli sviluppatori di distribuire pezzi di codice di dimensioni ridotte che vengono eseguiti in risposta a diversi eventi, che possono includere richieste HTTP, modifiche nel Cloud Storage, ecc.

La differenza principale con App Engine è che le funzioni hanno un prezzo per 100 millisecondi, mentre le istanze di App Engine si chiudono solo dopo 15 minuti di inattività. Un altro vantaggio è che le funzioni cloud vengono eseguite immediatamente, mentre una chiamata ad App Engine può richiedere una nuova istanza e l'avvio a freddo di una nuova istanza può richiedere alcuni secondi o più (a seconda del runtime e del codice).

Ciò rende le funzioni cloud ideali per (a) chiamate rare - non è necessario mantenere attiva un'istanza nel caso in cui si verifichi qualcosa, (b) cambiare rapidamente i carichi in cui le istanze spesso ruotano e si chiudono, e probabilmente più casi d'uso.

Ulteriori informazioni sulle funzioni cloud

La differenza di base è che Google App Engine ( GAE ) è una piattaforma come servizio ( PaaS ) mentre Google Compute Engine ( GCE ) è un'infrastruttura come servizio ( IaaS ) .

Per eseguire la tua applicazione in GAE devi solo scrivere il tuo codice e distribuirlo in GAE, nessun altro mal di testa. Poiché GAE è completamente scalabile, acquisirà automaticamente più istanze nel caso in cui il traffico aumenti e diminuirà le istanze quando il traffico diminuisce. Ti verranno addebitate le risorse che usi davvero , intendo, ti verranno addebitate le ore di istanza , i dati trasferiti , l' archiviazione ecc. Che la tua app ha davvero utilizzato. Ma la restrizione è che puoi creare la tua applicazione solo in Python, PHP, Java, NodeJS, .NET, Ruby e ** Go .

D'altra parte, GCE offre un'infrastruttura completa sotto forma di macchina virtuale . Hai il controllo completo sull'ambiente e sul runtime di quelle macchine virtuali in quanto puoi scrivere o installare qualsiasi programma lì. In realtà GCE è il modo di utilizzare virtualmente i Data Center di Google. In GCE devi configurare manualmente la tua infrastruttura per gestire la scalabilità usando Load Balancer .

Sia GAE che GCE fanno parte di Google Cloud Platform .

Aggiornamento: a marzo 2014 Google ha annunciato un nuovo servizio in App Engine chiamato Managed Virtual Machine . Le VM gestite offrono alle applicazioni del motore di app un po 'più di flessibilità rispetto alle opzioni di piattaforma, CPU e memoria dell'app. Come GCE, è possibile creare un ambiente di runtime personalizzato in queste macchine virtuali per l'applicazione del motore di app. Le VM effettivamente gestite di App Engine sfocano il confine tra IAAS e PAAS.

Per dirla semplicemente: il motore di calcolo ti offre un server di cui hai il pieno controllo / responsabilità. Hai accesso diretto al sistema operativo e installi tutto il software che desideri, che di solito è un web server, un database, ecc ...

Nel motore dell'app non gestisci il sistema operativo di nessuno dei software sottostanti. Carichi solo codice (Java, PHP, Python o Go) e voilà: funziona solo ...

Il motore delle app consente di risparmiare tonnellate di mal di testa, soprattutto per le persone inesperte ma presenta 2 svantaggi significativi: 1. più costosi (ma ha una quota gratuita che il motore di calcolo non ha) 2. hai meno controllo, quindi alcune cose non lo sono possibile o solo in un modo specifico (ad esempio salvataggio e scrittura di file).

O per renderlo ancora più semplice (poiché a volte non riusciamo a distinguere tra GAE Standard e GAE Flex):

Compute Engine è analogo a un PC virtuale, dove ad esempio distribuiresti un piccolo sito Web + database. Gestisci tutto, incluso il controllo delle unità disco installate. Se distribuisci un sito Web, sei incaricato di impostare DNS ecc.

Google App Engine (standard) è come una cartella sandbox di sola lettura da cui carichi il codice per eseguire e non preoccuparti del resto (sì: sola lettura - ci sono un set fisso di librerie installato per te e non puoi distribuire Librerie di terzi a volontà). DNS / sottodomini ecc. È molto più facile mappare.

Google App Engine (flessibile) è in realtà come un intero file system (non solo una cartella bloccata), in cui hai più potenza del motore standard, ad esempio hai autorizzazioni di lettura / scrittura (ma meno rispetto a un motore di calcolo ). Nello standard GAE hai un set fisso di librerie installato per te e non puoi distribuire librerie di terze parti a piacimento. Nell'ambiente flessibile è possibile installare qualsiasi libreria da cui dipende l'app, inclusi gli ambienti di build personalizzati (come Python 3).

Sebbene GAE Standard sia molto complicato da gestire (sebbene Google lo sembri semplice), si adatta molto bene quando viene messo sotto pressione. È ingombrante perché è necessario testare e garantire la compatibilità con l'ambiente bloccato e assicurarsi che qualsiasi libreria di terze parti che si utilizza non utilizzi altre librerie di terze parti di cui non si è a conoscenza e che potrebbero non funzionare sullo standard GAE. Richiede più tempo per configurarlo in pratica, ma può essere più gratificante a lungo termine per distribuzioni semplici.

Oltre alle note App Engine vs Compute Engine sopra l'elenco qui include anche un confronto con Google Kubernete Engine e alcune note basate sull'esperienza con una vasta gamma di app da piccole a molto grandi. Per ulteriori punti, consultare la documentazione di Google Cloud Platform descrizione di alto livello delle funzionalità in App Engine Standard e Flex nella pagina Scelta di un ambiente di App Engine . Per un altro confronto sulla distribuzione di App Engine e Kubernetes, vedere il post di Daz Wilkin App Engine Flex o Kubernetes Engine .

App Engine Standard

Professionisti

• Molto economico per le app a basso traffico in termini di costi diretti e anche di costi di manutenzione dell'app.
• Il ridimensionamento automatico è veloce. Il ridimensionamento automatico in App Engine si basa sulle classi di istanze leggere F1-F4 .
• La gestione della versione e la suddivisione del traffico sono veloci e convenienti. Queste funzionalità sono integrate in App Engine (sia Standard che Flex) in modo nativo.
• Gestione minima, gli sviluppatori devono concentrarsi solo sulla loro app. Gli sviluppatori non devono preoccuparsi di gestire le macchine virtuali in modo affidabile, come in GCE, o di conoscere i cluster, come con GKE.
• L'accesso a Datastore è veloce. Quando App Engine è stato rilasciato per la prima volta, il runtime è stato co-localizzato con Datastore. Successivamente Datastore è stato suddiviso come prodotto autonomo Cloud Datastore, ma rimane la co-posizione di App Engine Standard con Datastore.
• L'accesso a Memcache è supportato.
• La sandbox di App Engine è molto sicura. Rispetto allo sviluppo su GCE o altre macchine virtuali, in cui è necessario eseguire la propria diligenza per impedire che la macchina virtuale venga acquisita a livello di sistema operativo, la sandbox standard di App Engine è relativamente sicura per impostazione predefinita.

Contro

• Generalmente più vincolato rispetto ad altri ambienti Le istanze sono più piccole. Anche se questo è utile per il ridimensionamento automatico rapido, molte app possono trarre vantaggio da istanze più grandi, come dimensioni di istanze GCE fino a 96 core.
• La rete non è integrata con GCE
• Impossibile inserire App Engine dietro un bilanciamento del carico di Google Cloud. Limitato ai runtime supportati: Python 2.7, Java 7 e 8, Go 1.6-1.9 e PHP 5.5. In Java, esiste un supporto per i servlet ma non lo standard J2EE completo.

App Engine Flex

Professionisti

• Può usare un runtime personalizzato
• Integrazione nativa con reti GCE
• La gestione della versione e del traffico è conveniente, come quella standard
• Le dimensioni di istanze più grandi possono essere più adatte a grandi applicazioni complesse, in particolare le applicazioni Java che possono usare molta memoria

Contro

• L'integrazione di rete non è perfetta: nessuna integrazione con bilanciamento del carico interno o cloud privato virtuale condiviso
• Accesso a Memcache gestito non generalmente disponibile

Google Kubernetes Engine

Professionisti

• L'integrazione nativa con i contenitori consente runtime personalizzati e un maggiore controllo sulla configurazione del cluster.
• Incarna molte best practice che lavorano con macchine virtuali, come ambienti di runtime immutabili e facile capacità di ripristinare le versioni precedenti
• Fornisce un framework di distribuzione coerente e ripetibile
• Basato su standard aperti, in particolare Kubernetes, per la portabilità tra cloud e locali.
• La gestione delle versioni può essere eseguita con i contenitori Docker e il registro contenitori di Google

Contro

• La suddivisione e la gestione del traffico sono fai-da-te, probabilmente sfruttando Istio e Envoy
• Alcune spese generali di gestione
• Un po 'di tempo per accelerare i concetti di Kubernetes, come pod, distribuzioni, servizi, ingresso e spazi dei nomi
• È necessario esporre alcuni IP pubblici a meno che l'uso di cluster privati , ora in versione beta, elimini tale necessità ma è comunque necessario fornire l'accesso a posizioni da cui verranno eseguiti i comandi kubectl.
• Il monitoraggio dell'integrazione non è perfetto
• Mentre il bilanciamento del carico interno L3 è supportato in modo nativo su Kubernetes Engine, il bilanciamento del carico interno L7 è fai-da-te, probabilmente sfruttando Envoy

Calcola il motore

Professionisti

• Facile da accelerare: non è necessario accelerare su Kubernetes o App Engine, basta riutilizzare tutto ciò che si conosce dalla precedente esperienza. Questo è probabilmente il motivo principale per l'utilizzo diretto di Compute Engine.
• Controllo completo: puoi sfruttare direttamente molte funzionalità di Compute Engine e installare le ultime cose preferite per rimanere al limite.
• Non sono necessari indirizzi IP pubblici. Alcuni software legacy potrebbero essere troppo difficili da bloccare se qualcosa è esposto su IP pubblici.
• È possibile sfruttare il sistema operativo ottimizzato per container per l'esecuzione di contenitori Docker

Contro

• Principalmente fai-da-te, che può essere difficile da svolgere adeguatamente per affidabilità e sicurezza, anche se puoi riutilizzare soluzioni da vari luoghi, incluso il Cloud Launcher.
• Più spese generali di gestione. Esistono molti strumenti di gestione per Compute Engine ma non capiranno necessariamente come hai distribuito la tua applicazione, come fanno gli strumenti di monitoraggio di App Engine e Kubernetes Engine
• Il ridimensionamento automatico si basa su istanze GCE, che possono essere più lente di App Engine
• La tendenza è di installare software su istanze GCE a fiocco di neve, che può essere un po 'difficile da mantenere

Come già spiegato, Google Compute Engine (GCE) è l'Infrastruttura come servizio (IaaS) mentre Google App Engine (GAE) è Platform as a Service (PaaS). Puoi controllare il diagramma seguente per capire la differenza in un modo migliore (Tratto da e meglio spiegato qui ) -

Google Compute Engine
GCE è un servizio importante fornito da Google Cloud Platform (GCP) poiché la maggior parte dei servizi GCP utilizza istanze GCE (VM) sotto il livello di gestione (non sono sicuro di quale non lo faccia). Ciò include App Engine, Funzioni cloud, Kubernetes Engine (motore contenitore precedente), Cloud SQL, ecc. Le istanze GCE sono l'unità più personalizzabile e pertanto devono essere utilizzate solo quando l'applicazione non può essere eseguita su altri servizi GCP. Il più delle volte le persone usano GCE per trasferire le loro applicazioni On-Prem su GCP, poiché richiede modifiche minime. Successivamente, possono scegliere di utilizzare altri servizi GCP per componenti separati delle loro app.

Google App Engine
GAE è il primo servizio offerto da GCP (molto prima che Google arrivasse al settore cloud). Scala automaticamente da 0 a istanze illimitate (usa GCE sotto). Viene fornito con 2 gusti Ambiente standard e Ambiente flessibile.

L'ambiente standard è molto veloce, si riduce a 0 istanza quando nessuno utilizza l'app, si ingrandisce e si riduce in pochi secondi e dispone di servizi e librerie Google dedicati per la memorizzazione nella cache, l'autenticazione ecc. L'avvertenza con l'ambiente standard è che è molto restrittiva poiché funziona in una sandbox. Devi utilizzare i runtime gestiti solo per linguaggi di programmazione specifici. Le recenti aggiunte sono Node.js (8.x) e Python 3.x. I runtime più vecchi sono disponibili per Go, PHP, Python 2.7, Java ecc.

L'ambiente flessibile è più aperto in quanto consente di utilizzare runtime personalizzati in quanto utilizza contenitori docker. Pertanto, se il runtime non è disponibile nei runtime forniti, è sempre possibile creare il proprio file docker per l'ambiente di esecuzione. L'avvertenza è che richiede almeno 1 istanza in esecuzione, anche se nessuno utilizza l'app, inoltre il ridimensionamento su e giù richiede pochi minuti.

Non confondere GAE flessibile con Kubernetes Engine, poiché quello successivo utilizza Kubernetes reali e offre molte più personalizzazioni e funzionalità. GAE Flex è utile quando si desidera contenitori senza stato e l'applicazione si basa solo sui protocolli HTTP o HTTPS. Per altri protocolli Kubernetes Engine (GKE) o GCE è la tua unica scelta. Controlla la mia altra risposta per una migliore spiegazione.

App Engine offre agli sviluppatori la possibilità di controllare i core di Google Compute Engine, oltre a fornire un front-end rivolto al Web per le applicazioni di elaborazione dei dati di Google Compute Engine.

D'altra parte, Compute Engine offre la gestione diretta e completa del sistema operativo delle macchine virtuali. Per presentare la tua app, avrai bisogno di risorse e Google Cloud Storage è l'ideale per archiviare risorse e dati, qualunque sia il motivo per cui sono utilizzati. Ottieni un rapido accesso ai dati con l'hosting in tutto il mondo. L'affidabilità è garantita con un uptime del 99,95% e Google offre anche la possibilità di eseguire il backup e il ripristino dei dati, e che ci crediate o no, l'archiviazione è illimitata.

Puoi gestire le tue risorse con Google Cloud Storage, archiviandole, recuperandole, visualizzandole ed eliminandole. Puoi anche leggere e scrivere rapidamente su fogli di dati piatti conservati in Cloud Storage. Il prossimo nella gamma di Google Cloud è BigQuery. Con BigQuery, puoi analizzare enormi quantità di dati, stiamo parlando di milioni di record, in pochi secondi. L'accesso viene gestito tramite un'interfaccia utente semplice o un'interfaccia REST rappresentativa o trasferimento di stato rappresentativo.

L'archiviazione dei dati non è un problema, come si potrebbe pensare, e si riduce a centinaia di TB. BigQuery è accessibile tramite una serie di librerie client, comprese quelle per Java, .NET, Python, Go, Ruby, PHP e Javascript. È disponibile una sintassi simile a SQL chiamata NoSQL a cui è possibile accedere tramite queste librerie client o tramite un'interfaccia utente Web. Infine, parliamo delle opzioni del database della piattaforma Google Cloud, Cloud SQL e Cloud Datastore.

C'è una grande differenza. Cloud SQL è per database relazionali, principalmente MySQL, mentre Cloud Datastore è per database non relazionali che utilizzano noSQL. Con Cloud SQL, puoi scegliere tra hosting negli Stati Uniti, in Europa o in Asia, con 100 GB di spazio di archiviazione e 16 GB di RAM per istanza di database.

Cloud Datastore è disponibile gratuitamente per un massimo di 50 K di istruzioni di lettura / scrittura al mese e 1 GB di dati memorizzati anche al mese. Tuttavia, se si superano queste quote, è prevista una commissione. App Engine può anche collaborare con altri membri meno noti e più mirati della piattaforma Google Cloud, inclusi gli endpoint cloud per la creazione di backend API, l'API Google Prediction per l'analisi dei dati e la previsione delle tendenze o l'API di Google Translate per l'output multilingue.

Sebbene tu possa fare un buon importo con App Engine da solo, sono potenziali razzi quando si tiene conto della sua capacità di lavorare in modo facile ed efficiente con i suoi altri servizi della piattaforma Google Cloud.

Se hai familiarità con altri servizi popolari:

Google Compute Engine -> AWS EC2

Google App Engine -> Heroku o AWS Elastic Beanstalk

Funzioni Google Cloud -> Funzioni AWS Lambda

Lo spiegherò in un modo che aveva senso per me:

• Compute Engine : se sei una persona fai-da-te o hai un team IT e vuoi semplicemente noleggiare un computer su cloud con un sistema operativo specifico (ad esempio Linux), scegli il motore di calcolo. Devi fare tutto da solo.

• App Engine : se sei (ad esempio) un programmatore python e vuoi noleggiare un computer preconfigurato su cloud con Linux con un web server in esecuzione e l'ultimo python 3 con moduli necessari e alcuni plug-in con cui integrarti altri servizi esterni, vai per App Engine.

• Serverless Container (Cloud Run) : se si desidera distribuire l'immagine esatta dell'ambiente di configurazione locale (ad esempio: python 3.7 + flask + sklearn) ma non si desidera gestire server, ridimensionamento, ecc. Si crea un contenitore sul tuo computer locale (tramite docker) e quindi distribuiscilo su Google Run.

• Serverless Microservice (funzioni cloud) : se vuoi scrivere un sacco di API (funzioni) che svolgono un lavoro specifico, scegli google funzioni cloud. Ti concentri solo su quelle funzioni specifiche, il resto del lavoro (server, manutenzione, ridimensionamento, ecc.) È fatto per te al fine di esporre le tue funzioni come microservizi.

Man mano che approfondisci, perdi un po 'di flessibilità ma non sei preoccupato per gli aspetti tecnici non necessari. Paghi anche un po 'di più ma risparmi tempo e costi (parte IT): qualcun altro (google) lo sta facendo per te.

Se non si desidera preoccuparsi del bilanciamento del carico, del ridimensionamento, ecc., È fondamentale dividere l'app in un insieme di servizi Web "stateless" che scrivono qualsiasi cosa persistente in un archivio separato (database o archivio BLOB). Quindi scoprirai quanto sono fantastiche le funzioni Cloud Run e Cloud.

Personalmente, ho trovato Google Cloud Run una soluzione fantastica, assoluta libertà di sviluppo (purché apolidi), esponendolo come un servizio web, agganciando la tua soluzione, implementandola con Cloud Run. Lascia che Google sia il tuo IT e DevOps, non devi preoccuparti di ridimensionamento e manutenzione.

Ho provato tutte le altre opzioni e ognuna è buona per scopi diversi, ma Google Run è semplicemente fantastico. Per me, è il vero serverless senza perdere flessibilità nello sviluppo.

I servizi cloud offrono una gamma di opzioni da servizi completamente gestiti a servizi meno gestiti. Meno servizi gestiti danno più controllo agli sviluppatori. Lo stesso vale per il motore di calcolo e delle app. L'immagine qui sotto elabora di più su questo punto

Google Compute Engine (GCE)

Macchine virtuali (VM) ospitate nel cloud. Prima del cloud, questi erano spesso chiamati Virtual Private Server (VPS). Li useresti nello stesso modo in cui utilizzeresti un server fisico, in cui installi e configura il sistema operativo, installa la tua applicazione, installa il database, mantieni il sistema operativo aggiornato, ecc. Questo è noto come Infrastruttura: as-a-Service (IaaS).

Le macchine virtuali sono molto utili quando si dispone di un'applicazione esistente in esecuzione su una macchina virtuale o un server nel proprio data center e si desidera migrarla facilmente su GCP.

Google App Engine

App Engine ospita ed esegue il tuo codice, senza la necessità di gestire il sistema operativo, la rete e molte altre cose che dovresti gestire con un server fisico o una VM. Pensalo come un runtime, che può distribuire, versione e ridimensionare automaticamente la tua applicazione. Questo si chiama Platform-as-a-Service (PaaS).

App Engine è particolarmente utile quando si desidera la distribuzione e il ridimensionamento automatici dell'applicazione. A meno che l'applicazione non richieda una configurazione del sistema operativo personalizzata, App Engine è spesso vantaggioso rispetto alla configurazione e gestione manuale delle macchine virtuali.