AWS OpsWorks vs AWS Beanstalk vs AWS CloudFormation?

Gostaria de saber quais são as vantagens e desvantagens de usar AWS OpsWorks versus AWS Beanstalk e AWS CloudFormation?

Estou interessado em um sistema que pode ser escalonado automaticamente para lidar com qualquer grande número de solicitações simultâneas da web (de 1000 solicitações por minuto a 10 milhões de rpm), incluindo uma camada de banco de dados que também pode ser escalonável automaticamente.

Em vez de ter uma instância separada para cada aplicativo, o ideal é compartilhar alguns recursos de hardware com eficiência. No passado, usei principalmente uma instância EC2 + RDS + Cloudfront + S3

O sistema de pilha hospedará alguns aplicativos ruby ​​on rails de alto tráfego que estamos migrando do Heroku, também alguns aplicativos python / django e alguns aplicativos PHP também.

Desde já, obrigado.

Gostaria de saber quais são as vantagens e desvantagens de usar AWS OpsWorks versus AWS Beanstalk e AWS CLoudFormation?

A resposta é: depende.

O AWS OpsWorks e o AWS Beanstalk são (me disseram) maneiras simplesmente diferentes de gerenciar sua infraestrutura, dependendo de como você pensa a respeito. CloudFormation é simplesmente uma forma de modelar sua infraestrutura.

Pessoalmente, estou mais familiarizado com o Elastic Beanstalk, mas com cada um deles. Eu prefiro porque ele pode fazer implantações via Git. É informação pública que o Elastic Beanstalk usa CloudFormation sob o capô para lançar seus ambientes.

Para meus projetos, eu uso os dois em conjunto. Eu uso o CloudFormation para construir um ambiente VPC com configuração personalizada, baldes S3 e tabelas DynamoDB que uso para meu aplicativo. Então eu inicio um ambiente Elastic Beanstalk dentro do VPC customizado que sabe como se comunicar com os recursos S3 / DynamoDB.

Estou interessado em um sistema que pode ser escalonado automaticamente para lidar com qualquer grande número de solicitações simultâneas da web (de 1000 solicitações por minuto a 10 milhões de rpm), incluindo uma camada de banco de dados que também pode ser escalonável automaticamente.

Sob o capô, OpsWorks e Elastic Beanstalk usam EC2 + CloudWatch + Auto Scaling, que é capaz de lidar com as cargas de que você está falando. RDS fornece suporte para bancos de dados baseados em SQL escalonáveis.

Em vez de ter uma instância separada para cada aplicativo, o ideal é compartilhar alguns recursos de hardware com eficiência. No passado, usei principalmente uma instância EC2 + RDS + Cloudfront + S3

Dependendo do que você quer dizer com " alguns recursos de hardware", você sempre pode iniciar instâncias autônomas do EC2 junto com os ambientes OpsWorks ou Elastic Beanstalk. Atualmente, o Elastic Beanstalk oferece suporte a um webapp por ambiente. Não me lembro do que o OpsWorks oferece suporte.

O sistema de pilha hospedará alguns aplicativos ruby ​​on rails de alto tráfego que estamos migrando do Heroku, também alguns aplicativos python / django e alguns aplicativos PHP também.

Tudo isso é totalmente compatível com a AWS. OpsWorks e Elastic Beanstalk se otimizaram para uma variedade de ambientes de desenvolvimento (Ruby, Python e PHP estão todos na lista), enquanto o EC2 fornece servidores brutos onde você pode instalar o que quiser.

OpsWorks é uma ferramenta de orquestração como Chef - na verdade, é derivada de Chef - Puppet, Ansible ou Saltstalk. Você usa Opsworks para especificar o estado em que deseja que sua rede esteja, especificando o estado em que deseja que cada recurso - instâncias de servidor, aplicativos, armazenamento - esteja. E você especifica o estado em que deseja que cada recurso esteja especificando o valor que você deseja para cada atributo desse estado. Por exemplo, você pode querer que o serviço Apache esteja sempre ativo e em execução e inicie na inicialização com o Apache como o usuário e o Apache como o grupo Linux.

CloudFormation é um modelo json (**) que especifica o estado do (s) recurso (s) que deseja implantar, ou seja, deseja implantar uma instância AWS EC2 micro t2 em us-east-1 como parte do VPC 192.168.1.0/24 . No caso de uma instância EC2, você pode especificar o que deve ser executado nesse recurso por meio de seu script bash personalizado na seção de dados do usuário do recurso EC2. CloudFormation é apenas um modelo. O modelo é transformado em um recurso em execução apenas se você executá-lo por meio do AWS Management Console para CloudFormation ou se executar o comando aws cli para Cloudformation, ou seja, aws cloudformation ...

ElasticBeanstalk é um PAAS- você pode fazer upload dos aplicativos especificamente Ruby / Rails, node.js ou Python / django ou Python / Flask. Se você estiver executando qualquer coisa como Scala, Haskell ou qualquer outra coisa, crie uma imagem Docker para ela e carregue essa imagem Docker no Elastic Beanstalk (*).

Você pode fazer o upload do seu aplicativo para o Elastic Beanstalk executando o aws cli para CloudFormation ou criar uma receita para o Opsworks para fazer o upload do seu aplicativo para o Elastic Beanstalk. Você também pode executar o aws cli para Cloudformation por meio do Opsworks.

(*) Na verdade, a documentação da AWS em seu exemplo de aplicativo Ruby era tão pobre que perdi a paciência e incorporei o aplicativo de exemplo em uma imagem Docker e carreguei a imagem Docker no Elastic Beanstalk.

(**) Desde setembro de 2016, Cloudformation também suporta modelos YAML.

No Opsworks, você pode compartilhar "funções" de camadas em uma pilha para usar menos recursos, combinando as tarefas específicas que uma instância subjacente pode fazer.

Lista de compatibilidade de camada (contanto que os grupos de segurança sejam definidos corretamente):

HA Proxy : custom, db-master, and memcached.
MySQL :  custom, lb, memcached, monitoring-master, nodejs-app, php-app, rails-app, and web.
Java : custom, db-master, and memcached.
Node.js : custom, db-master, memcached, and monitoring-master
PHP : custom, db-master, memcached, monitoring-master, and rails-app.
Rails :  custom, db-master, memcached, monitoring-master, php-app.
Static :  custom, db-master, memcached.
Custom : custom, db-master, lb, memcached, monitoring-master, nodejs-app, php-app, rails-app, and web 
Ganglia :  custom, db-master, memcached, php-app, rails-app. 
Memcached :  custom, db-master, lb, monitoring-master, nodejs-app, php-app, rails-app, and web. 

referência: http://docs.aws.amazon.com/opsworks/latest/userguide/layers.html

AWS Beanstalk: é implantar e gerenciar aplicativos na nuvem AWS sem se preocupar com a infraestrutura que executa seus aplicativos da web com Elastic Beanstalk. Não precisa se preocupar com o EC2 ou outras instalações.

AWS OpsWorks O AWS OpsWorks nada mais é que um serviço de gerenciamento de aplicativos que torna mais fácil para os novos usuários DevOps modelar e gerenciar todo o seu aplicativo

AWS CloudFormation - crie e atualize seus ambientes.

AWS Opsworks - Gerencie seus sistemas dentro desses ambientes como fazemos com Chef ou Puppet

AWS Beanstalk - Criar, gerenciar e implantar.

Mas pessoalmente gosto do CloudFormation e do OpsWorks, ambos por usarem todo o seu poder para o que foram criados.

Use CloudFormation para criar seu ambiente, então você pode chamar Opsworks de scripts de formação de nuvem para iniciar sua máquina. Então você terá pilha Opsworks para gerenciá-lo. Por exemplo, adicione um usuário na caixa do Linux usando Opsworks ou faça patching de suas caixas usando receitas do chef. Você também pode anotar as receitas do chef para implantação. Caso contrário, você pode usar CodeDeploy especificamente construído para implantação.

AWS OpsWorks - esta é uma parte do serviço de gerenciamento da AWS. Isso ajuda a configurar o aplicativo usando scripts. Ele usa Chef como a estrutura devops para esse gerenciamento e operação de aplicativo. Existem modelos que podem ser usados ​​para configuração de servidor, banco de dados, armazenamento. Os modelos também podem ser personalizados para realizar qualquer outra tarefa. DevOps Engineers têm controle sobre as dependências e infraestrutura do aplicativo.

AWS Beanstalk - fornece o ambiente para linguagens como Java, Node Js, Python, Ruby Go. Elastic Bean stalk fornece o recurso para executar o aplicativo. Os desenvolvedores não se preocupam com a infraestrutura e não têm controle sobre a infraestrutura.

AWS CloudFormation - CloudFormation tem modelos de amostra para gerenciar os recursos da AWS em ordem.

Como muitos outros comentaram, AWS Beanstalk, AWS OpsWorks e AWS Cloud Formation oferece soluções diferentes para problemas diferentes.

A fim de cumprir com

I am interested in a system that can be auto scaled to handle any high number of simultaneous web requests (From 1000 requests per minute to 10 million rpm.), including a database layer that can be auto scalable as well.

E levando em consideração que você está em processo de migração, recomendo fortemente que você comece a dar uma olhada na solução AWS Lambda e AWS DynamoDB (ou híbrida).

Ambos os dois são projetados para escalonamento automático de uma forma simples e podem ser uma solução muito barata.

Basta usar o terraform e ECS ou EKS.

opsworks, beanstalk elástico e tecnologia antiga de cloudformation agora. -)