É possível (ou eficiente) executar um backend completo com o AWS Lambda (por exemplo, o Elastic Beanstalk)?

Question

Eu sou relativamente novo no mundo dos servidores, então me perdoe se isso é básico (e o primeiro bit do texto será explicando minha lógica para ter certeza de que não é falho). Todas as minhas perguntas ficarão em negrito para facilitar sua ajuda:).

Estou pesquisando e ensinando algumas das tecnologias da AWS, e notei no seu Hub Móvel que, se você quiser a lógica da nuvem, elas só permitem a configuração "automática" das funções do Lambda. Depois de ler e pesquisar, descobri alguns recursos que apontam para a arquitetura "sem servidor" (que a introdução do Lambda suporta). No passado, entendi que o Elastic Beanstalk foi introduzido para ajudar a tornar o gerenciamento de servidores (especialmente para dispositivos móveis) significativamente mais simples.

Para dispositivos móveis, há duas opções (obviamente mais, mas, para simplificar, vamos concordar):

• Configure um Elastic Beanstalk que tenha pelo menos 1 instância sendo executada 24/7 e tenha vários pontos de extremidade para cada URL
• Com o API Gateway, podemos rotear URLs facilmente para funções específicas do Lambda. Com isso, podemos atender a qualquer solicitação (muito parecido com a configuração de um aplicativo do Elastic Beanstalk).

Tudo isso me leva a acreditar que um back-end completo do Lambda seria completamente possível e fácil de criar por uma fração do custo de ter um servidor rodando 24/7. Isso está correto?

Agora, supondo que o acima esteja correto, precisamos determinar se o uso do Lambda é realmente benéfico em relação ao Elastic Beanstalk.

Para servidores simples, podemos configurar algumas funções do Lambda e chamá-lo um dia (e é provavelmente muito mais simples e barato (pelo menos para projetos pequenos) do que usar o Elastic Beanstalk).

No entanto, para servidores mais complexos com mais URLs e conexões de banco de dados, as coisas ficam mais interessantes.

Estes são os problemas que vejo com o uso do Lambda na situação acima

• Cada URL teria seu próprio gateway de API com sua própria função do Lambda. Se algum código ou módulo é usado em múltiplas funções, nós teríamos que copiar e colar isso em cada função.
• Gerenciar várias funções do Lambda (e Gateways de API) é simplesmente mais trabalho do que gerenciar um único projeto / repositório / como você quiser chamar sua base de código.
• Cada função que requer uma conexão com o banco de dados precisa se conectar dentro da função (por exemplo, ter uma conexão constante em um aplicativo Node.js).

A única maneira (que eu poderia pensar) de evitar os dois primeiros problemas é fazer uma função robusta que atua como um despacho (a função principal pega um parâmetro do gateway da API e determina qual arquivo será executado na função do Lambda) .

Existem alguns pontos importantes que eu estou perdendo para determinar se vale a pena usar o Lambda sobre o Elastic Beanstalk?

    

Answer 1

Para manter todos informados, não obtive respostas, por isso perguntei no StackOverflow e obtive o seguinte resposta de mbaird . Há um pouco de discussão nos comentários, então sinta-se à vontade para dar uma olhada e dar crédito a ele.

It sounds like you have it figured out already. You are correct that using Lambda instead of having a server running 24/7 can be a significant cost savings. This article makes the claim:

And it's saving some of Amazon's customers big bucks, with at least one happy Lambda customer saving 80% off their cloud bills. You might want to look at the Serverless Framework which manages some of the pain points.

     

Acho que, com o tempo, muitos dos pontos problemáticos desaparecerão, conforme a Amazon acrescenta   mais recursos para o Lambda e mais ferramentas de terceiros são criadas para ele.   Estou constantemente descobrindo novos usos para o Lambda, mas também estou   constantemente descobrindo usos que parecem ser um bom ajuste no começo, mas   realmente não funciona no Lambda, pelo menos não ainda. Por exemplo eu realmente   precisa de alguma maneira para limitar o número de instâncias de uma função Lambda   que pode ser executado simultaneamente para impedir a saída disponível   conexões de banco de dados ou atingir limites de uso em APIs de terceiros. Eu   também realmente precisa de funções Lambda para rodar dentro do meu VPC, mas isso é   deveria estar chegando muito em breve.