Google Cloud Platform y Amazon Web Services ofrecen muchísimas infraestructuras distintas para ejecutar una aplicación web. Sin embargo, animarse a probar un servicio nuevo puede ser intimidante. Cuando estás empezando a conocer uno, lo habitual es querer levantar una instancia mínima desde la línea de comandos.
En este post vas a ver cómo familiarizarte rápidamente con nueve servicios de Google Cloud y AWS usando los "Quickstarts" que armé. En este caso, un Quickstart es un script de bajo nivel que te lleva hasta el "¡Hello World!" del servicio correspondiente y, de paso, te ayuda a entender los procesos que lo hacen posible.
Con estos Quickstarts es fácil dejar atrás esa primera etapa intimidante, en la que quizá entiendas poco o nada de la tecnología, y llegar al cómodo momento en el que podés decir: "¡Funciona!". A partir de ahí, podés ir sumando de a poco las funcionalidades que quieras explorar.
Principios de diseño de los Quickstarts
Todos los Quickstarts se construyen bajo los mismos principios: son automatizados, mínimos y completos.
Automatizados
La GUI sirve para una exploración inicial, pero los scripts funcionan mejor en la etapa del "¡Hello, World!", porque te permiten desplegar el mismo servicio una y otra vez mientras lo ajustas y le sumas funcionalidades.
Mínimos
Los scripts de "¡Hello, World!" son mínimos: el menor código necesario para obtener la respuesta HTTP.
GCP usa el término "Quickstart" para referirse a un tutorial sobre la forma más rápida de poner en marcha una tecnología específica. Mi repositorio simplifica esa idea enfocándose en los scripts ejecutables, que suelen ser todavía más simples que los que aparecen en esos artículos.
En AWS, un Quick Start es una plantilla de CloudFormation para poner en marcha una tecnología específica. Eso es útil, pero yo opté por shell scripts porque ayudan a entender los comandos de más bajo nivel, algo importante cuando después tengas que construir un sistema completo.
Me gusta pensarlo como un Quickstart aún más rápido.
Completos
Los scripts despliegan todo lo necesario: roles de IAM, clusters, etc. Los únicos requisitos previos son las herramientas de línea de comandos y la autenticación con una cuenta de la nube. Con eso listo, la idea es lanzar todo lo que haga falta. Así, si algo falla, podés empezar de cero sin tener que averiguar cómo dejar cada componente en un estado estable.
Lo ideal es que los scripts se puedan volver a ejecutar, de modo que puedas desplegar código nuevo sobre un despliegue anterior. Algunos de los scripts del repositorio lo permiten, otros no, porque agregar esa capacidad sumaría demasiado código. En esos casos, eliminá la instancia anterior antes de volver a desplegar, o lanzá cada nueva versión con un nombre distinto. (¡Pero ojo con los costos! Borrá las instancias viejas lo antes posible).
Requisitos previos
El README de cada directorio describe los requisitos previos, que incluyen:
gcloud, autenticado (congcloud init).- La herramienta AWS CLI con credenciales.
- Un plugin de AWS CLI para Lightsail.
- La herramienta
ebde Elastic Beanstalk. - La herramienta
ecs-clipara ECS, aunque el script la instala por ti. - Para procesar la salida de los comandos, algunos necesitan
envsubst(se instala con el paquetegettext) yjq.
Las infraestructuras compatibles
Estos son los scripts que creé para:
- AWS Elastic Beanstalk
- AWS Lambda
- Amazon Elastic Container Service
- Amazon Lightsail
- Google App Engine Standard Environment
- Google App Engine Flexible Environment
- GCP Cloud Functions
- GCP Cloud Run
- Google Kubernetes Engine
Scripts
El repositorio de git tiene scripts deploy.sh para cada tecnología de infraestructura, en sus respectivos subdirectorios. Si te animás a la aventura, podés ejecutarlos todos desde run_all.sh en el directorio raíz.
Si te resulta útil y querés ver más, envía un pull request con tu script o abre un issue pidiendo el que más te interese.
Elastic Kubernetes Service sería un buen próximo paso, y después EC2, Google Compute Engine y las ofertas de otros proveedores de nube.
Diferencias en simplicidad
Las tecnologías de infraestructura varían en simplicidad y flexibilidad.
En App Engine Standard Environment y Cloud Functions, el script es un único comando deploy, seguido del acceso a una URL conocida. En otros casos la cosa se complica un poco. Por ejemplo, Cloud Run y ECS requieren construir y publicar un contenedor, mientras que Lambda además necesita un rol de IAM.
Aun así, esas diferencias dejan de ser significativas. Una vez que el "¡Hello, World!" está corriendo, estos scripts se encargan de automatizar la complejidad.
Lecturas adicionales
Para conocer en detalle los pasos hasta el "¡Hello, World!", consulta los artículos de Quickstart o "Getting Started" enlazados en cada README.