El caso
El sitio de retiro tiene que estar en línea antes del viernes. Nadie del equipo quiere administrar un servidor.
La tienda de Isaac decidió vender por el sitio, con retiro en la tienda. El sistema lo hace un becario, con ayuda de una amiga desarrolladora, y el plazo es de dos semanas. Nadie quiere aprender a configurar una máquina, un balanceador o un certificado para esto. El equipo solo quiere subir el código y empezar a recibir pedidos.
Este post parte de Serverless y Cloud Run en Google Cloud, que presenta los modelos sin servidor, y de Compute Engine, donde la máquina es tuya para administrar. App Engine está en el medio: tú entregas el código, y la plataforma se encarga del resto.
El problema
Subir el código no debería exigir una lista de tareas
En Compute Engine, la tienda elige la imagen del sistema operativo, instala el runtime del lenguaje, configura el balanceo de carga, los certificados y las reglas de firewall, y tiene que encargarse de reiniciar una máquina que se cae. Es control total, pero también es una lista larga. Para un sitio simple, casi todo eso es trabajo que no vende nada.
La solución
App Engine: tú despliegas, la plataforma se encarga del resto
App Engine es una plataforma como servicio (PaaS) de Google Cloud. Envías la aplicación, y se encarga del balanceo de carga, de aumentar y reducir instancias según el tráfico, de las versiones anteriores y de verificar si las instancias están sanas.
| Pregunta | Compute Engine (IaaS) | App Engine (PaaS) |
|---|---|---|
| Quién elige y mantiene el sistema operativo | Tú | La plataforma |
| Quién configura el balanceo de carga | Tú | La plataforma |
| Quién maneja una versión nueva sin tirar la anterior | Tú | La plataforma, con división de tráfico |
| Cuánto control tienes sobre la máquina | Total | Menor, limitado a lo que ofrece la plataforma |
Ambientes
Dos ambientes, dos formas de ejecutar
App Engine tiene dos ambientes. La elección depende de dos preguntas: ¿la aplicación necesita escalar a cero? ¿Y necesita un ambiente que controles?
Standard
“¿Necesita escalar a cero y arrancar en segundos?”
- Ejemplo
- El sitio de pedidos de la tienda: casi ningún acceso de madrugada y un pico el viernes por la noche.
- Foco
- Cada lenguaje corre en su propio sandbox, entre los lenguajes soportados. Escala hasta cero instancias, y el cobro sigue las horas de instancia.
Flexible
“¿Necesita un ambiente que controles, o SSH?”
- Ejemplo
- Un panel de reposición que depende de una biblioteca del sistema y ejecuta un proceso en segundo plano.
- Foco
- Cada instancia es un contenedor en una VM de Compute Engine, con acceso SSH y procesos en segundo plano. Mantiene al menos una instancia encendida, así que nunca llega a cero.
Jerarquía
Aplicación, servicio y versión
App Engine organiza lo que publicas en cuatro niveles. Cada proyecto de Google Cloud tiene una aplicación. Dentro de ella están los servicios, que son componentes con configuraciones propias. Cada servicio tiene versiones, y cada versión corre en una o más instancias.
| Nivel (level) | Qué es | Ejemplo en la tienda |
|---|---|---|
| Aplicación (application) | Una por proyecto | La tienda entera |
| Servicio (service) | Un componente, con configuraciones propias | El sitio de pedidos y el panel de reposición |
| Versión (version) | Código y configuración, que pueden coexistir con otras versiones | La versión nueva del sitio de pedidos |
| Instancia (instance) | Una copia en ejecución de la versión, que atiende las solicitudes | Dos instancias de la versión nueva |
Como varias versiones pueden estar activas al mismo tiempo, el tráfico puede dividirse entre ellas. Por ejemplo, 90% para la versión actual y 10% para la nueva. Si la nueva da problemas, el tráfico vuelve a la anterior, sin volver a desplegar nada.
No confundas
App Engine × Cloud Run
App Engine
“¿Quieres publicar el código sin pensar en contenedores?”
- Ejemplo
- El sitio de la tienda, subido como código Python, con versiones y división de tráfico.
- Foco
- La plataforma prepara el ambiente del lenguaje. La aplicación, los servicios, las versiones y la división de tráfico ya vienen listos.
Cloud Run
“¿Ya tienes un contenedor que responde solicitudes HTTP?”
- Ejemplo
- El mismo sitio, empaquetado con el sistema operativo y las bibliotecas que tú elegiste.
- Foco
- Ejecuta cualquier contenedor HTTP, sin depender de los runtimes de App Engine. También escala a cero.
En la práctica
Qué ambiente para cada parte de la tienda
| Parte del sistema | Elección | Por qué |
|---|---|---|
| Sitio de pedidos, con pico el viernes por la noche | App Engine Standard | Escala a cero y arranca en segundos |
| Panel de reposición con biblioteca del sistema | App Engine Flexible | Corre en una VM y acepta SSH para depurar |
| Servicio de etiquetas, ya empaquetado en contenedor | Cloud Run | Ejecuta el contenedor que ya existe |
Términos clave
Cinco términos para fijar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
La tienda quiere un sitio de pedidos que no gaste nada de madrugada y que escale rápido en el pico del viernes. ¿Qué ambiente de App Engine debe usar?
02
El equipo necesita entrar por SSH a la máquina de la aplicación para investigar una falla. ¿Qué ambiente lo permite?
03
Isaac creó la aplicación de pedidos en la región de São Paulo y ahora quiere cambiar su región. ¿Qué es verdad?
En la tienda, App Engine ejecuta el sitio de pedidos sin que nadie administre una máquina. El siguiente paso de la ruta es Contenedores en la nube, para cuando el contenedor en sí es lo que empaquetas.