O Google Cloud Platform e a Amazon Web Services oferecem várias infraestruturas para rodar uma aplicação web. Mesmo assim, testar um serviço novo pode assustar. Quando você está começando a explorar um serviço, geralmente quer subir uma instância mínima direto pela linha de comando.
Neste post, você vai ver como se familiarizar rapidamente com nove serviços do Google Cloud e da AWS usando os " Quickstarts" que criei. Um Quickstart, aqui, é um script de baixo nível que leva você até o "Hello World!" do serviço correspondente e, ao mesmo tempo, ajuda a entender o que está acontecendo por trás.
Esses Quickstarts ajudam a vencer aquela primeira fase intimidadora, em que você ainda entende pouco ou nada da tecnologia, e chegar ao ponto confortável em que dá para dizer: "Funciona!". Daí em diante, é só ir somando aos poucos as funcionalidades que quiser explorar.
Princípios de design dos Quickstarts
Todos os Quickstarts seguem os mesmos princípios: são automatizados, mínimos e completos.
Automatizados
A interface gráfica é ótima para uma fuçada inicial, mas, no estágio do "Hello, World!", scripts funcionam melhor — você consegue fazer deploy do mesmo serviço várias vezes enquanto ajusta e adiciona funcionalidades.
Mínimos
Scripts de "Hello, World!" são mínimos: o mínimo de código necessário para obter a resposta HTTP.
O GCP usa o termo " Quickstart" para tutoriais sobre o caminho mais rápido para colocar uma tecnologia específica para rodar. Meu repositório simplifica isso, focando nos scripts executáveis, que costumam ser ainda mais enxutos do que o que aparece nesses artigos.
Na AWS, um Quick Start é um template do CloudFormation para colocar uma tecnologia específica em execução. É útil, mas optei por shell scripts porque eles ajudam a entender os comandos de mais baixo nível — algo que faz diferença quando, mais adiante, você for montar um sistema completo.
Gosto de pensar nisso como um Quickstart ainda mais rápido.
Completos
Os scripts fazem o deploy de tudo o que é necessário, incluindo IAM roles, clusters etc. Os únicos pré-requisitos são as ferramentas de linha de comando e a autenticação em uma conta de nuvem. Com isso pronto, a ideia é subir tudo o que for preciso. Assim, se algo der errado, dá para começar do zero sem ter que descobrir como deixar cada componente em um estado estável.
De preferência, os scripts podem ser executados de novo, permitindo subir um código novo sobre um deploy anterior. Alguns dos scripts daqui funcionam assim, outros não — porque adicionar essa capacidade exigiria código demais. Nesses casos, remova a instância antiga antes do novo deploy ou suba cada nova versão com um nome diferente. (Mas fique de olho nos custos! Apague as instâncias antigas o quanto antes.)
Pré-requisitos
O README de cada diretório descreve os pré-requisitos. Entre eles estão:
gcloud, autenticado (comgcloud init)- A AWS CLI com credenciais.
- Um plugin da AWS CLI para o Lightsail.
- A ferramenta
ebdo Elastic Beanstalk. - A ferramenta
ecs-clipara o ECS, mas o próprio script instala isso para você. - Para processar a saída dos comandos, alguns scripts exigem
envsubst(instalado com o pacotegettext) ejq.
Infraestruturas suportadas
Aqui estão os scripts que criei 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
O repositório no Git tem scripts deploy.sh para cada tecnologia de infraestrutura, nos subdiretórios. Se quiser ousar, dá para rodar todos a partir do run_all.sh, no diretório raiz.
Se achar útil e quiser ver mais, mande um pull request com o seu script, ou abra uma issue pedindo o seu favorito.
O Elastic Kubernetes Service seria um bom próximo passo, e depois o EC2, o Google Compute Engine e ofertas de outros provedores de nuvem.
Diferenças de simplicidade
As tecnologias de infraestrutura variam em simplicidade e flexibilidade.
No App Engine Standard Environment e no Cloud Functions, o script é só um único comando deploy, seguido do acesso a uma URL conhecida. Em outros casos, a complexidade é maior. O Cloud Run e o ECS, por exemplo, exigem buildar e fazer push de um container, enquanto o Lambda também precisa de uma IAM role.
No fim, essas diferenças não pesam tanto. Depois que o "Hello, World!" está no ar, esses scripts ajudam a automatizar a complexidade.
Leitura complementar
Para uma explicação dos passos até o "Hello, World!", veja os artigos Quickstart ou "Getting Started" linkados em cada README.