¿Cuál es la diferencia entre Google App Engine y Google Compute Engine?

Me preguntaba cuál es la diferencia entre App Engine y Compute Engine. ¿Alguien puede explicarme la diferencia?

App Engine es una plataforma como servicio. Significa que simplemente implementa su código, y la plataforma hace todo lo demás por usted. Por ejemplo, si su aplicación tiene mucho éxito, App Engine creará automáticamente más instancias para manejar el aumento de volumen.

Más información sobre App Engine

Compute Engine es una infraestructura como servicio. Debe crear y configurar sus propias instancias de máquina virtual. Le brinda más flexibilidad y generalmente cuesta mucho menos que App Engine. El inconveniente es que debe administrar su aplicación y máquinas virtuales usted mismo.

Leer más sobre Compute Engine

Puede mezclar App Engine y Compute Engine, si es necesario. Ambos funcionan bien con las otras partes de Google Cloud Platform .

EDITAR (mayo de 2016):

Una distinción más importante: los proyectos que se ejecutan en App Engine pueden reducirse a cero instancias si no se reciben solicitudes. Esto es extremadamente útil en la etapa de desarrollo, ya que puede pasar semanas sin exceder la generosa cuota gratuita de horas de instancia. El tiempo de ejecución flexible (es decir, "VM administradas") requiere al menos una instancia para ejecutarse constantemente.

EDITAR (abril de 2017):

Cloud Functions (actualmente en versión beta) es el siguiente nivel desde App Engine en términos de abstracción, ¡no hay instancias! Permite a los desarrolladores desplegar fragmentos de código del tamaño de un bocado que se ejecutan en respuesta a diferentes eventos, que pueden incluir solicitudes HTTP, cambios en Cloud Storage, etc.

La mayor diferencia con App Engine es que las funciones tienen un precio por 100 milisegundos, mientras que las instancias de App Engine se cierran solo después de 15 minutos de inactividad. Otra ventaja es que Cloud Functions se ejecuta de inmediato, mientras que una llamada a App Engine puede requerir una nueva instancia, y el inicio en frío de una nueva instancia puede demorar unos segundos o más (según el tiempo de ejecución y el código).

Esto hace que Cloud Functions sea ideal para (a) llamadas raras: no es necesario mantener una instancia activa solo en caso de que ocurra algo, (b) cargas que cambian rápidamente donde las instancias a menudo giran y se apagan, y posiblemente más casos de uso.

Más información sobre las funciones en la nube

La diferencia básica es que Google App Engine ( GAE ) es una Plataforma como Servicio ( PaaS ), mientras que Google Compute Engine ( GCE ) es una Infraestructura como Servicio ( IaaS ) .

Para ejecutar su aplicación en GAE solo necesita escribir su código e implementarlo en GAE, no hay otro dolor de cabeza. Como GAE es totalmente escalable, adquirirá automáticamente más instancias en caso de que el tráfico aumente y disminuya las instancias cuando disminuya el tráfico. Se le cobrarán los recursos que realmente utiliza , es decir, se le facturarán las horas de instancia , los datos transferidos , el almacenamiento , etc., que su aplicación realmente utilizó. Pero la restricción es que puede crear su aplicación solo en Python, PHP, Java, NodeJS, .NET, Ruby y ** Go .

Por otro lado, GCE le proporciona una infraestructura completa en forma de máquina virtual . Usted tiene control completo sobre el entorno y el tiempo de ejecución de esas máquinas virtuales, ya que puede escribir o instalar cualquier programa allí. En realidad, GCE es la forma de usar los centros de datos de Google de forma virtual. En GCE, debe configurar manualmente su infraestructura para manejar la escalabilidad mediante Load Balancer .

Tanto GAE como GCE son parte de Google Cloud Platform .

Actualización: en marzo de 2014, Google anunció un nuevo servicio en App Engine llamado Managed Virtual Machine . Managed VM ofrece a las aplicaciones de motor de aplicaciones un poco más de flexibilidad sobre la plataforma de aplicaciones, CPU y opciones de memoria. Al igual que GCE, puede crear un entorno de tiempo de ejecución personalizado en estas máquinas virtuales para la aplicación del motor de aplicaciones. Las máquinas virtuales realmente administradas de App Engine difuminan la frontera entre IAAS y PAAS hasta cierto punto.

En pocas palabras: el motor de cómputo le brinda un servidor del que tiene el control / responsabilidad total. Tiene acceso directo al sistema operativo e instala todo el software que desea, que generalmente es un servidor web, una base de datos, etc.

En el motor de aplicaciones no administras el sistema operativo de ninguno de los programas subyacentes. Solo carga código (Java, PHP, Python o Go) y listo, simplemente se ejecuta ...

El motor de aplicaciones ahorra toneladas de dolor de cabeza, especialmente para personas sin experiencia, pero tiene 2 inconvenientes significativos: 1. más costoso (pero tiene una cuota gratuita que el motor de cómputo no tiene) 2. tiene menos control, por lo tanto, ciertas cosas simplemente no son posible, o solo posible de una manera específica (por ejemplo, guardar y escribir archivos).

O para hacerlo aún más simple (ya que a veces no podemos diferenciar entre GAE Standard y GAE Flex):

Compute Engine es análogo a una PC virtual, donde desplegaría un pequeño sitio web + base de datos, por ejemplo. Usted administra todo, incluido el control de las unidades de disco instaladas. Si implementa un sitio web, está a cargo de configurar DNS, etc.

Google App Engine (estándar) es como una carpeta de espacio aislado de solo lectura donde carga código para ejecutar y no se preocupa por el resto (sí: solo lectura: hay un conjunto fijo de bibliotecas instaladas para usted y no puede implementar Bibliotecas de terceros a voluntad). DNS / Subdominios, etc. es mucho más fácil de mapear.

De hecho, Google App Engine (Flexible) es como un sistema de archivos completo (no solo una carpeta bloqueada), donde tiene más potencia que el motor Estándar, por ejemplo, tiene permisos de lectura / escritura (pero menos en comparación con un Compute Engine ) En el estándar GAE, tiene un conjunto fijo de bibliotecas instaladas para usted y no puede implementar bibliotecas de terceros a voluntad. En el entorno flexible, puede instalar cualquier biblioteca de la que dependa su aplicación, incluidos los entornos de compilación personalizados (como Python 3).

Aunque GAE Standard es muy engorroso de manejar (aunque Google lo hace parecer simple), escala muy bien cuando se lo presiona. Es engorroso porque necesita probar y garantizar la compatibilidad con el entorno bloqueado y asegurarse de que cualquier biblioteca de terceros que use no use ninguna otra biblioteca de terceros que desconozca y que no funcione en el estándar GAE. Lleva más tiempo configurarlo en la práctica, pero puede ser más gratificante a largo plazo para implementaciones simples.

Además de las notas de App Engine vs Compute Engine arriba de la lista, aquí también se incluye una comparación con Google Kubernete Engine y algunas notas basadas en la experiencia con una amplia gama de aplicaciones, desde pequeñas hasta muy grandes. Para obtener más información, consulte la descripción de alto nivel de la documentación de Google Cloud Platform sobre las características de App Engine Standard y Flex en la página Elección de un entorno de App Engine . Para otra comparación de la implementación de App Engine y Kubernetes, vea la publicación de Daz Wilkin App Engine Flex o Kubernetes Engine .

App Engine Standard

Pros

• Muy económico para aplicaciones de bajo tráfico en términos de costos directos y también el costo de mantenimiento de la aplicación.
• El escalado automático es rápido. El escalado automático en App Engine se basa en las clases de instancias livianas F1-F4 .
• La gestión de versiones y la división del tráfico son rápidas y convenientes. Estas características están integradas en App Engine (tanto Standard como Flex) de forma nativa.
• Gestión mínima, los desarrolladores necesitan centrarse solo en su aplicación. Los desarrolladores no necesitan preocuparse por administrar máquinas virtuales de manera confiable, como en GCE, o aprender sobre clústeres, como con GKE.
• El acceso al almacén de datos es rápido. Cuando se lanzó App Engine por primera vez, el tiempo de ejecución se ubicó junto con Datastore. Más tarde, Datastore se dividió como el producto independiente Cloud Datastore, pero la ubicación conjunta de App Engine Standard con Datastore permanece.
• El acceso a Memcache es compatible.
• El entorno limitado de App Engine es muy seguro. En comparación con el desarrollo en GCE u otras máquinas virtuales, donde necesita hacer su propia diligencia para evitar que la máquina virtual sea tomada a nivel del sistema operativo, el entorno limitado estándar de App Engine es relativamente seguro de manera predeterminada.

Contras

• Generalmente más limitado que otros entornos Las instancias son más pequeñas. Aunque esto es bueno para el escalado automático rápido, muchas aplicaciones pueden beneficiarse de instancias más grandes, como tamaños de instancia de GCE de hasta 96 núcleos.
• Las redes no están integradas con GCE
• No se puede poner App Engine detrás de un Google Cloud Load Balancer. Limitado a tiempos de ejecución compatibles: Python 2.7, Java 7 y 8, Go 1.6-1.9 y PHP 5.5. En Java, hay algún soporte para Servlets pero no el estándar J2EE completo.

App Engine Flex

Pros

• Puede usar un tiempo de ejecución personalizado
• Integración nativa con redes GCE
• La gestión de versiones y tráfico es conveniente, igual que la Norma
• Los tamaños de instancia más grandes pueden ser más adecuados para aplicaciones complejas grandes, especialmente aplicaciones Java que pueden usar mucha memoria

Contras

• La integración de red no es perfecta: no hay integración con equilibradores de carga internos o nubes privadas virtuales compartidas
• El acceso a Memcache administrado no está generalmente disponible

Google Kubernetes Engine

Pros

• La integración nativa con contenedores permite tiempos de ejecución personalizados y un mayor control sobre la configuración del clúster.
• Encarna muchas prácticas recomendadas para trabajar con máquinas virtuales, como entornos de tiempo de ejecución inmutables y la capacidad fácil de volver a versiones anteriores.
• Proporciona un marco de implementación consistente y repetible
• Basado en estándares abiertos, especialmente Kubernetes, para la portabilidad entre nubes y locales.
• La gestión de versiones se puede lograr con los contenedores Docker y el Registro de contenedores de Google

Contras

• La división y administración del tráfico es de bricolaje, posiblemente aprovechando Istio y Envoy
• Algunos gastos generales de gestión
• Algún tiempo para aumentar los conceptos de Kubernetes, como pods, implementaciones, servicios, ingreso y espacios de nombres
• Es necesario exponer algunas IP públicas a menos que el uso de Private Clusters , ahora en versión beta, elimine esa necesidad, pero aún debe proporcionar acceso a las ubicaciones desde donde se ejecutarán los comandos de kubectl.
• La integración de monitoreo no es perfecta
• Mientras que el equilibrio de carga interno L3 es compatible de forma nativa en Kubernetes Engine, el equilibrio de carga interno L7 es de bricolaje, posiblemente aprovechando Envoy

Compute Engine

Pros

• Fácil de aumentar: no es necesario aumentar en Kubernetes o App Engine, solo reutilice lo que sepa de la experiencia anterior. Esta es probablemente la razón principal para usar Compute Engine directamente.
• Control completo: puede aprovechar muchas funciones de Compute Engine directamente e instalar la última de sus cosas favoritas para mantenerse a la vanguardia.
• No hay necesidad de IP públicas. Algunos software heredados pueden ser demasiado difíciles de bloquear si hay algo expuesto en IP públicas.
• Puede aprovechar el sistema operativo optimizado para contenedores para ejecutar contenedores Docker

Contras

• Principalmente hágalo usted mismo, lo que puede ser difícil de hacer de manera adecuada para la confiabilidad y la seguridad, aunque puede reutilizar soluciones de varios lugares, incluido el Iniciador de la nube.
• Más gastos generales de gestión. Existen muchas herramientas de administración para Compute Engine, pero no necesariamente comprenderán cómo ha implementado su aplicación, como lo hacen las herramientas de monitoreo de App Engine y Kubernetes Engine.
• El escalado automático se basa en instancias de GCE, que pueden ser más lentas que App Engine
• Tendencia es instalar software en instancias GCE de copos de nieve, lo que puede ser un esfuerzo para mantener

Como ya se explicó, Google Compute Engine (GCE) es la Infraestructura como servicio (IaaS), mientras que Google App Engine (GAE) es la Plataforma como servicio (PaaS). Puede consultar el siguiente diagrama para comprender la diferencia de una mejor manera (Tomado y explicado mejor aquí ):

Google Compute Engine
GCE es un servicio importante proporcionado por Google Cloud Platform (GCP), ya que la mayoría de los servicios de GCP usan instancias de GCE (VM) debajo de la capa de administración (no estoy seguro de cuál no). Esto incluye App Engine, Cloud Functions, Kubernetes Engine (motor de contenedor anterior), Cloud SQL, etc. Las instancias de GCE son la unidad más personalizable allí y, por lo tanto, solo deben usarse cuando su aplicación no se puede ejecutar en ningún otro servicio GCP. La mayoría de las veces las personas usan GCE para transferir sus aplicaciones On-Prem a GCP, ya que requiere cambios mínimos. Más tarde, pueden optar por utilizar otros servicios de GCP para componentes separados de sus aplicaciones.

Google App Engine
GAE es el primer servicio ofrecido por GCP (mucho antes de que Google llegara al negocio de la nube). Se escala automáticamente de 0 a instancias ilimitadas (usa GCE debajo). Viene con 2 sabores Ambiente estándar y Ambiente flexible.

El entorno estándar es realmente rápido, se reduce a 0 instancias cuando nadie está usando su aplicación, aumenta y disminuye en segundos y tiene servicios y bibliotecas dedicadas de Google para el almacenamiento en caché, la autenticación, etc. La advertencia con el entorno estándar es que es muy restrictivo ya que se ejecuta en una caja de arena. Debe usar tiempos de ejecución administrados solo para lenguajes de programación específicos. Las adiciones recientes son Node.js (8.x) y Python 3.x. Los tiempos de ejecución más antiguos están disponibles para Go, PHP, Python 2.7, Java, etc.

El entorno flexible es más abierto, ya que le permite utilizar tiempos de ejecución personalizados, ya que utiliza contenedores acoplables. Por lo tanto, si su tiempo de ejecución no está disponible en los tiempos de ejecución proporcionados, siempre puede crear su propio dockerfile para el entorno de ejecución. La advertencia es que requiere tener al menos 1 instancia en ejecución, incluso si nadie está usando su aplicación, además de que la ampliación y la reducción requieren unos minutos.

No confunda GAE flexible con Kubernetes Engine, ya que el último usa Kubernetes real y proporciona mucha más personalización y características. GAE Flex es útil cuando desea contenedores sin estado y su aplicación se basa únicamente en protocolos HTTP o HTTPS. Para otros protocolos, Kubernetes Engine (GKE) o GCE es su única opción. Mira mi otra respuesta para una mejor explicación.

App Engine ofrece a los desarrolladores la capacidad de controlar los núcleos de Google Compute Engine, así como proporcionar un front-end orientado a la web para las aplicaciones de procesamiento de datos de Google Compute Engine.

Por otro lado, Compute Engine ofrece una gestión directa y completa del sistema operativo de sus máquinas virtuales. Para presentar su aplicación, necesitará recursos, y Google Cloud Storage es ideal para almacenar sus activos y datos, sin importar para qué se utilicen. Obtiene acceso rápido a datos con alojamiento en todo el mundo. La fiabilidad está garantizada con un tiempo de actividad del 99.95%, y Google también ofrece la capacidad de realizar copias de seguridad y restaurar sus datos, y lo creas o no, el almacenamiento es ilimitado.

Puede administrar sus activos con Google Cloud Storage, almacenarlos, recuperarlos, mostrarlos y eliminarlos. También puede leer y escribir rápidamente en hojas de datos planas que se guardan en Cloud Storage. El siguiente en la línea de Google Cloud es BigQuery. Con BigQuery, puede analizar cantidades masivas de datos, estamos hablando de millones de registros, en segundos. El acceso se maneja a través de una interfaz de usuario sencilla, o una transferencia de estado representativa, o una interfaz REST.

El almacenamiento de datos, como puede sospechar, no es un problema, y ​​se escala a cientos de TB. Se puede acceder a BigQuery a través de una gran cantidad de bibliotecas de clientes, incluidas aquellas para Java, .NET, Python, Go, Ruby, PHP y Javascript. Está disponible una sintaxis similar a SQL llamada NoSQL, a la que se puede acceder a través de estas bibliotecas de cliente o mediante una interfaz de usuario web. Finalmente, hablemos sobre las opciones de base de datos de la plataforma Google Cloud, Cloud SQL y Cloud Datastore.

Hay una gran diferencia. Cloud SQL es para bases de datos relacionales, principalmente MySQL, mientras que Cloud Datastore es para bases de datos no relacionales que usan noSQL. Con Cloud SQL, tiene la opción de alojar en los EE. UU., Europa o Asia, con 100 GB de almacenamiento y 16 GB de RAM por instancia de base de datos.

Cloud Datastore está disponible sin cargo por hasta 50 K de instrucciones de lectura / escritura por mes y 1 GB de datos almacenados también por mes. Sin embargo, hay una tarifa si excede estas cuotas. App Engine también puede trabajar con otros miembros menos conocidos y más específicos de la plataforma Google Cloud, incluidos Cloud Endpoints para crear backends API, API de predicción de Google para análisis de datos y pronóstico de tendencias, o la API de Google Translate, para resultados multilingües.

Si bien puede hacer una buena cantidad de dinero con App Engine por sí solo, es posible que se dispare cuando se tiene en cuenta su capacidad para trabajar de manera fácil y eficiente con sus servicios de plataforma Google Cloud.

Si está familiarizado con otros servicios populares:

Google Compute Engine -> AWS EC2

Google App Engine -> Heroku o AWS Elastic Beanstalk

Funciones de Google Cloud -> Funciones de AWS Lambda

Lo explicaré de una manera que tenga sentido para mí:

• Compute Engine : si usted es una persona que lo hace usted mismo o tiene un equipo de TI y solo desea alquilar una computadora en la nube que tenga un sistema operativo específico (por ejemplo, Linux), vaya a Compute Engine. Tienes que hacer todo por ti mismo.

• App Engine : si usted es (por ejemplo) un programador de Python y desea alquilar una computadora preconfigurada en la nube que tenga Linux con un servidor web en ejecución y la última Python 3 con los módulos necesarios y algunos complementos para integrar con otros servicios externos, vas a App Engine.

• Contenedor sin servidor (Cloud Run) : si desea implementar la imagen exacta de su entorno de configuración local (por ejemplo: python 3.7 + flask + sklearn) pero no desea tratar con el servidor, el escalado, etc. Cree un contenedor en su máquina local (a través de Docker) y luego implementarlo en Google Run.

• Microservicio sin servidor (Cloud Functions) : si desea escribir un montón de API (funciones) que hacen un trabajo específico, vaya a google Cloud Functions. Solo se enfoca en esas funciones específicas, el resto del trabajo (servidor, mantenimiento, escalado, etc.) se realiza por usted para exponer sus funciones como microservicios.

A medida que profundizas, pierdes algo de flexibilidad pero no te preocupan los aspectos técnicos innecesarios. También paga un poco más, pero ahorra tiempo y costos (parte de TI): alguien más (google) lo está haciendo por usted.

Si no desea preocuparse por el equilibrio de carga, el escalado, etc., es crucial dividir su aplicación en un montón de servicios web "sin estado" que escriban cualquier cosa persistente en un almacenamiento separado (base de datos o almacenamiento de blobs). Entonces descubrirás lo increíble que es Cloud Run y ​​Cloud Functions.

Personalmente, encontré que Google Cloud Run es una solución increíble, libertad absoluta en el desarrollo (siempre que no tenga estado), exponerla como un servicio web, acoplar su solución, implementarla con Cloud Run. Deje que Google sea su TI y DevOps, no necesita preocuparse por el escalado y el mantenimiento.

He probado todas las demás opciones y cada una es buena para diferentes propósitos, pero Google Run es simplemente increíble. Para mí, es el verdadero servidor sin perder flexibilidad en el desarrollo.

Los servicios en la nube ofrecen una gama de opciones desde servicios totalmente administrados hasta servicios menos administrados. Los servicios menos administrados dan más control a los desarrolladores. Lo mismo es la diferencia en Compute y App engine también. La imagen de abajo detalla más sobre este punto

Google Compute Engine (GCE)

Máquinas virtuales (VM) alojadas en la nube. Antes de la nube, estos a menudo se llamaban Servidores Privados Virtuales (VPS). Los usaría de la misma manera que usaría un servidor físico, donde instala y configura el sistema operativo, instala su aplicación, instala la base de datos, mantiene el sistema operativo actualizado, etc. Esto se conoce como Infraestructura- as-a-Service (IaaS).

Las máquinas virtuales son más útiles cuando tiene una aplicación existente ejecutándose en una máquina virtual o servidor en su centro de datos, y desea migrarla fácilmente a GCP.

Motor de aplicaciones de Google

App Engine aloja y ejecuta su código, sin requerir que se ocupe del sistema operativo, las redes y muchas de las otras cosas que tendría que administrar con un servidor físico o VM. Piense en ello como un tiempo de ejecución, que puede implementar, versionar y escalar automáticamente su aplicación. Esto se llama Plataforma como servicio (PaaS).

App Engine es más útil cuando desea una implementación automatizada y un escalado automatizado de su aplicación. A menos que su aplicación requiera una configuración personalizada del sistema operativo, App Engine a menudo es ventajoso sobre la configuración y administración de máquinas virtuales a mano.