Implantação manual vs. Amazon Elastic Beanstalk

Quais são as vantagens que obtemos com o uso do Elastic Beanstalk em vez da criação manual da instância EC2 e da configuração do servidor tomcat e implantação, etc, para um aplicativo da Web Java típico. O balanceamento de carga, o monitoramento e o escalonamento automático são as únicas vantagens?

Suponha que para meu aplicativo da web que usa banco de dados eu instalei o banco de dados na própria instância do EC2. Quando o escalonamento automático ocorrer, o banco de dados será criado na instância recém-criada ou acessará o banco de dados que criei na instância mestre ... Se ele criar apenas uma réplica quando o escalonamento automático ocorrer, como será a sincronização de dados entre as instâncias?

Todas as coisas que você mencionou, como balanceamento de carga, monitoramento e escalonamento automático, são definitivamente vantagens.

No entanto, você tem que pensar sobre isso da seguinte maneira: em uma verdadeira Plataforma como Serviço (PAAS), o objetivo é separar o aplicativo da plataforma. Como desenvolvedor, você só se preocupa com seu aplicativo. A plataforma é "alugada" para você. As "instâncias" da plataforma são automaticamente atualizadas, administradas, dimensionadas, balanceadas, etc. para você. Você acabou de fazer upload de seu arquivo WAR e ele simplesmente funciona (pelo menos teoricamente).

EC2 por si só não é PAAS. É mais parecido com IAAS ( Infrastructure as a Service ). Você ainda precisa cuidar das instâncias do servidor, instalar software nelas, mantê-las atualizadas, etc.

Elastic Beanstalk é um sistema PAAS. Assim como o App Engine e o Azure, entre muitos outros.

Em um verdadeiro sistema PAAS, o DBMS é um componente separado do (s) servidor (es) de aplicativos da web. O motivo é óbvio: o DBMS não pode ser instalado nas instâncias que estão sendo usadas para o servidor de aplicativos porque, à medida que as instâncias são criadas e destruídas com base em seu tráfego, o DBMS seria perdido! Ter o DBMS e o servidor de aplicativos na mesma máquina / instância geralmente não é uma boa ideia.

Em um sistema PAAS, o DBMS é um serviço separado. Para a Amazon, seria Amazon RDS . Assim como no Elastic Beanstalk, onde você não precisa se preocupar com o servidor de aplicativos e apenas carrega seu arquivo WAR, com RDS, você não precisa se preocupar com o DBMS e apenas implanta seu (s) banco (s) de dados.

Elastic Beanstalk e RDS funcionam muito bem juntos, especialmente quando implementados na mesma zona de disponibilidade, onde a latência seria muito baixa.

Por fim, o uso do Elastic Beanstalk não custa nada mais do que os recursos implantados (instâncias do EC2 e o balanceador de carga). No entanto, o RDS não é barato e definitivamente seria mais caro do que usar uma única instância do EC2 para o servidor de aplicativos e o DBMS.

Elastic Beanstalk faz mais do que apenas balanceamento de carga, monitoramento e escalonamento automático.

1) Gerencia versões de aplicativos, armazenando e gerenciando diferentes versões de seu aplicativo, permitindo que você alterne facilmente entre as diferentes versões de seus aplicativos.

2) Possui o conceito de “ambientes” para cada aplicação, permitindo a você implantar diferentes versões de sua aplicação em cada ambiente. Isso é útil, por exemplo, se você deseja configurar ambientes separados de QA e DEV e deseja implantar facilmente um build primeiro no DEV e depois implantar a mesma versão do aplicativo no QA quando sua equipe de QA estiver pronta para o próximo build.

3) Externaliza as propriedades importantes de configuração do contêiner (configurações de memória do Tomcat, por exemplo) para o console e API do Elastic Beanstalk. Por causa disso, você pode salvar facilmente as configurações e copiá-las entre os ambientes.

4) Visualize os arquivos de log do aplicativo por meio do console e role e arquive automaticamente os arquivos de log no S3. (É certo que esse recurso está um pouco fraco no momento.)

Tive um aplicativo implantado tanto no EC2 dedicado (Nginx e Gunicorn) quanto no Beanstalk Environment (CentOS e Apache2).

Minhas observações:

• BeanStalk é Paas. Criar manualmente uma instância EC2 (IAAS) é como fazer tudo do zero, mas você tem um controle sólido.

• BeanStalk vem com CentOS e Apache (Httpd) padrão. Você pode escolher o sistema operacional em uma instância dedicada.

• Essas coisas que importavam para mim,

  • Havia muitos erros 504 aparecendo no ambiente Beanstalk.
  • Foi difícil depurar quando o servidor BeanStalk travou, pois os logs também não apareciam e não podiam ssh na máquina. Isto é muito importante.
  • Instalar / configurar ferramentas como Celery, Redis (é necessário rodar outra porta) etc.,. na instância dedicada é muito mais fácil.

• No meu caso, tive que dimensionar o servidor (Beanstalk) para executar a instalação de alguns pacotes (como o pandoc). Essas coisas são mais simples no Ubuntu.

• O dimensionamento é muito mais fácil no BeanStalk. A clonagem de servidores é direta no BeanStalk.

• Eu tinha tomado micro em ambos os casos (dedicado e Beanstalk). Achei que a microinstância dedicada era melhor.

• Implantação automatizada no Beanstalk. Tive que escrever scripts para automatizar o mesmo, o que é bom, já que é apenas uma vez.