Implantação manual vs. Amazon Elastic Beanstalk

114

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?

Elango
fonte

Respostas:

144

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.

stepaniano
fonte
3
Muito bem colocado. Apenas um complemento: você pode especificar um AMI personalizado para servir de base para cada criação de instância. Portanto, você pode, por exemplo, personalizar uma imagem do Apache com todas as configurações e aplicativos necessários e usá-la como AMI de base (há um campo Custom AMI ID na configuração do ambiente Beanstalk) Ainda assim, os dados gerados em tempo de execução seriam realmente excluídos em cada encerramento de instância (e o balanceador de carga fará isso!).
André Felipe
1
Uma coisa que me pegou de surpresa foi o fato de que o Elastic Beanstalk cria um balanceador de carga para cada ambiente implantado. Os balanceadores de carga não são realmente caros para executar, mas eles têm quase o mesmo custo que uma microinstância.
Ken Liu,
@KenLiu, o Load Balancer é mais poderoso do que uma microinstância.
BigSack de
7
@BigSack - o que eu estava tentando enfatizar é que o Elastic Beanstalk deve ser gratuito, mas a AWS não deixa claro que cada ambiente alocará um balanceador de carga que custará cerca de US $ 15 por mês. Eu não estava comparando com uma microinstância.
Ken Liu
Até onde eu sei, o RDS é quase equivalente em preço ao EC2 atualmente, enquanto fornece muito mais utilidade, manutenção e confiabilidade.
Justin Schier
38

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.)

Ken Liu
fonte
De qualquer forma, no meu conceito, acho que ele quer entender sobre o desempenho, que não gosto no beanstalk, mau funcionamento na implantação e casos de desastre, e tudo pode ser igual ou melhor usando LAMBDA. Difícil, mas é uma solução mágica para sua alta disponibilidade.
Lucas Rodrigues Sena
Apenas para adicionar ao último ponto: você pode enviar facilmente todos os logs de aplicativos para o CloudWatch.
SebaGra
6

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.

Super Nova
fonte