Salvo que seas un experto en los productos y servicios de Google y ese sea tu trabajo en el día a día, a la hora de plantearte subir un proyecto a la nube de Google, casi seguro que te surgen dudas. No solo por la cantidad abrumadora de productos, si no por la velocidad a la que aparecen y se actualizan. Vamos a intentar despejar algunas de esas dudas aquí.
Antes de nada, ¿qué opciones hay?
A día de hoy, para ejecutar nuestros proyectos (o parte de ellos), en Google Cloud, tenemos:
- App Engine
- Compute Engine
- Kubernetes Engine
- Cloud Functions
- Cloud Run
Los he ordenado tal y como salen en la consola de google, pero más adelante los ordenaremos de otra manera.
A esto habría que sumar otras tantas formas de almacenar los datos o el estado de nuestras aplicaciones, si es que lo tuvieran, pero en eso entraremos en otro momento.
Una máquina de las de toda la vida
Si lo que quieres es una máquina de las de toda la vida, aunque no tengas que preocuparte de que le falle la fuente de alimentación o ampliarle la RAM, lo más parecido es Google Compute Engine. Compute Engine en sí mismo es un universo de posibilidades, en el que puedes pagar por máquinas por uso (por horas), desde máquinas compartidas de 0.2 cores y 0.60gb de memoria, a máquinas de más de 400 cores y 11TB de memoria, varias opciones para discos persistentes, máquinas para ejecuciones poco prioritarias y no-críticas, etc. Tienes descuentos por uso prolongado y un sinfín de máquinas entre medias para elegir. Es fácil estar ejecutando un código en una máquina de Compute Engine, que se quede pequeña para algo y pararla, editarla para ampliarle memoria, procesadores o ambos, y reiniciarla.
Al ser lo más parecido a una máquina estándar, es fácil para alguien con algunos conocimientos de sistemas montar algo en Google Compute Engine. Se crea la máquina (tarda un par de minutos normalmente) y en seguida se tiene acceso por ssh. Hay distintas distribuciones para elegir (Debian por defecto).
Si no quieres instalar todo de cero, hay algunas imágenes pre-configuradas por Google, por ejemplo con Wordpress, Jenkins, etc, en Google Marketplace.
Opciones sin servidor (serverless)
Soy poco fan de la palabra serverless, porque uno podría pensar que es magia que ejecuta tu código en el aire, cuando la realidad es que hay una (o n) máquina/s pero tu no te enteras de que está/n ahí.
Dicho sea esto, hay básicamente tres opciones para ejecutar código sin servidor en Google Cloud: App Engine, Cloud Run y Cloud Functions. Un resumen general sería, si quieres ejecutar una aplicación entera, App Engine. Si tienes algunos componentes de tu aplicación en contenedores de Docker (si Docker te suena a marca de cereales te dejo un enlace ;) ), para ejecutar estos puedes usar Cloud Run, y si lo que quieres es ejecutar funciones muy concretas de código, Cloud Functions.
Con Cloud Functions, por ejemplo, tu solo defines la cantidad máxima de memoria que consumirá tu función (y alguna otra cosilla de seguridad), y luego puedes subirla escrita en Go, Node.js o Python. Google te devuelve un endpoint (una URL) correspondiente a tu función.
Con Cloud Run subes un contenedor de docker y Google te devuelve un endpoint. Igual que en Cloud Functions, configuras algunos temas de seguridad, pero poco más.
Ambas tienen algunas limitaciones (1000 funciones o servicios de Cloud Run por proyecto, etc), pero salvo que estés montando el siguiente Pokémon Go es difícil que te vayan a impedir trabajar en tu proyecto con ellas. Todas las soluciones serverless limitan a 2Gb de memoria como mucho.
Gestión de contenedores
Hemos comentado algo de todas las opciones que tiene Google Cloud, menos de Kubernetes Engine. Si queremos desplegar nuestro código en contenedores de Docker y, además, encargarnos de la gestión del clúster, Kubernetes Engine es la solución de Google. Para trabajar con contenedores es lo más parecido a Compute Engine, de hecho hay que elegir máquinas de Compute Engine como nodos del Clúster.
Gestión de la escalabilidad
Una de las principales diferencias entre los productos serverless y Kubernetes Engine, o Compute Engine, es la gestión de la escalabilidad. Compute Engine por sí mismo no escala, es algo que queda fuera completamente del producto, son máquinas virtuales y si necesitas escalar algo tendrás que parar, cambiar de máquina y arrancar de nuevo, y es solo un escalado vertical (máquina más potente).
En Kubernetes Engine la escalabilidad tienes que configurarla tú, hay que definir el número mínimo y máximo de nodos en el clúster, el tipo de nodos y al desplegar pods (contenedores de docker) tendrás que definir el número mínimo-máximo de instancias de cada uno de esos pods.
En los productos serverless tienes escalabilidad por defecto. Puedes configurarla, tunearla, ponerle topes por si te asusta que la cosa se vaya de madre y te dejen la tarjeta como una mojama, pero por defecto tu función/contenedor/aplicación va a escalar sin tener que preocuparte demasiado por el tema (en lo que a ejecución de código se refiere).
No todo es el código
Como no todo es el código, en otro post hablaremos de las distintas opciones a la hora de almacenar estados o datos de tu aplicación/proyecto. También profundizaremos en algunos ejemplos de casos de uso para las distintas herramientas que hemos comentado en este post.
Como siempre, dudas, sugerencias, cuestiones varias, nos podéis hacer llegar un correillo a hola@softspring.es o por redes sociales.