Quais são os prós e os contras do AWS Elastic Beanstalk em comparação com outras estratégias de implantação?

Sou bastante novo em toda a pilha e implantações do Netflix OSS em geral. Como pano de fundo para o meu nível atual de conhecimento em termos de operações, minha principal função é como engenheiro de aplicativos front-end. No entanto, eu gosto do lado operacional, por isso estou tentando configurar uma nova estratégia de implantação e as ferramentas para um novo projeto.

Nossos Objetivos

• Implantações super fáceis (queremos apertar um botão para atualizar a produção)
• Implantações automatizadas para ambientes de teste (usando Jenkins)
• Facilidade de manutenção (temos um aplicativo para escrever, não queremos gastar nosso tempo brincando com problemas de produção)
• Capacidade de lidar com uma arquitetura orientada a serviços (muitos aplicativos pequenos, vários idiomas e repositórios de dados)
• Flexibilidade suficiente para garantir que não precisaremos alterar estratégias tão cedo (já estamos tentando nos afastar do RightScale)

Estamos bem com um pouco mais de tempo de configuração inicial, se isso nos poupar algumas dores de cabeça no futuro.

Então, nesse sentido, eu tenho ouvido podcasts, assistindo palestras de operações e lendo toneladas de postagens de blog, com base em nossos objetivos e no que eu considero algumas práticas recomendadas, começamos a formar um plano usando Asgard, enrolando nosso pacote em uma jarra e enrolando-o em uma AMI.

Planejamos tudo isso e gostamos das vantagens do processo versus o uso de um servidor Chef e instâncias convergentes em tempo real (sentimos que isso era propenso a erros, devido à nossa linha do tempo limitada e à falta de entendimento sobre o fluxo de trabalho do servidor Chef). No entanto, um colega de trabalho olhou um pouco sozinho e sentiu que o Elastic Beanstalk atendia às nossas necessidades.

Eu examinei e criei um ambiente de teste com um arquivo WAR e um banco de dados RDS anexado. As coisas parecem funcionar e acredito que podemos automatizar implantações em um ambiente de teste usando Jenkins por meio da API da AWS. Parece simples o suficiente ... talvez simples demais.

O que eu queria saber é: qual é o problema? Se o Elastic Beanstalk é tão simples e eficaz, por que não se fala mais? Estou tendo dificuldades para encontrar opiniões e fatos objetivos suficientes sobre as duas estratégias diferentes de implantação, então pensei em perguntar.

Você usa Elastic Beanstalk? Em caso afirmativo, por que e quais fatores levam a essa decisão? Do que você gosta e não gosta?

Se você não usa o Elastic Beanstalk, mas o considera, o que você usa e por que não usou o Elastic Beanstalk?

Quais são as vantagens e desvantagens de uma estratégia de implantação baseada em Elastic Beanstalk para uma SOA? Ou seja, o Elastic Beanstalk funcionará bem com muitos aplicativos pequenos que dependem um do outro para funcionar?

Avaliei o Elastic Beanstalk, além de outras ofertas da AWS, enquanto tentava melhorar nossas instâncias da AWS roladas manualmente. Os motivos pelos quais optei por não usá-lo foram devido a complicações que poderiam resultar na migração do meu aplicativo existente e não na oferta em si. O problema é que você não tem tanto controle sobre a implantação / configuração de aplicativos dos servidores. Se você estiver iniciando um novo aplicativo, pode ser útil não lidar com essas coisas no momento, se você tiver um aplicativo existente, será mais um desafio se encaixar no modelo do Beanstalk.

O Beanstalk oferece uma oferta semelhante ao Heroku e outros fornecedores de PaaS, mas não traz muitos benefícios para aqueles que querem apenas se concentrar em fazer seu aplicativo. Você pelo menos consegue determinar os recursos virtualizados em maior grau do que outros fornecedores de PaaS.

Problemas que eu estava enfrentando com meus aplicativos:

• Implantações baseadas em Git - eu as amo, mas nosso repositório é de mais de 1 GB. Bastante grande para empurrar regularmente. Esse repositório também contém cerca de 40 aplicativos (que realmente devem ser divididos), mas isso levaria algum tempo. Carregar qualquer tipo de pacote poderia funcionar, mas a maioria de nossos aplicativos levaria uma grande quantidade de trabalho para transformá-lo em um pacote.

• Integração com outros serviços - Pelo que vi, o Beanstalk assume que qualquer coisa com a qual você está se conectando é um único serviço. Isso funciona bem se os seus serviços estiverem atrasados ​​e com o ELB, mas nossos nós foram separados por nós através do HAProxy em execução em cada servidor de aplicativos. Se você estiver executando seus datastores e outros serviços como um único ponto de extremidade, deverá ficar bem.

Na minha avaliação, também incluí OpsWorks e CloudFormation. O OpsWorks tem problemas semelhantes de integração com o funcionamento da automação existente para esses aplicativos. O CloudFormation não fez muito mais do que alguns scripts Python e Chef já estavam cuidando de nós.

Acabei optando por usar o AWS Autoscaling Groups em vez de alguma automação fornecida pela Asgard . Essa foi a menor alteração no código de configuração / aplicativo existente e nos forneceu os benefícios que procurávamos, gerenciamento simples de vários servidores disponíveis por meio da API da AWS.

As restrições impostas pelo Elastic Beanstalk em seu aplicativo são muito úteis. Você precisará certificar-se de que seu aplicativo seja praticamente sem estado, forneça um ponto de extremidade para um serviço e confie em outros serviços para o estado. Se você está tentando criar serviços autônomos reutilizáveis, vários aplicativos no Beanstalk são um ótimo começo.

Se / quando você chegar ao ponto de querer mais configurações, o OpsWorks é um ótimo próximo passo. As funções predefinidas devem facilitar a transição e fornecem uma estrutura de automação em torno do Chef para ajudar a coordenar o provisionamento de vários servidores.

Eu vejo o ponto de perda de controle, mas não vejo necessariamente a apatridia. Tudo o que a eb realmente faz é implantar automação, que por sinal é incrível. Eu vejo o objetivo de um grande repositório. Em geral, acho que a separação de funções de aplicativos lógicos em aplicativos de beans separados e, em seguida, ter ambientes de "teste" e "prod" abaixo, é muito bom. Temos ambientes de módulos como uploader, ele não faz muito e, em teoria, acrescenta muitos custos, mas você está usando instâncias menores apenas mais. Executamos um nginx centralizado e tivemos que escrever um monte de identificadores de mensagens sns personalizados para notificar o ngnix sobre alterações na política de dimensionamento automático. Outro grande problema de eb é a incapacidade de reduzir os balanços de carga, já que usamos o ngnix, por que? elb não suporta websocket.