Como as arquiteturas sem servidor gerenciam as conexões com o banco de dados?

Diz-se que a principal vantagem da arquitetura sem servidor é que esses programas não precisam de um servidor dedicado para executar continuamente. Em seguida, são chamados em uma solicitação e param de sair da função.

Isso significa que um programa sem servidor precisará ser rápido para iniciar, por ser responsivo. Como ele lida com ações demoradas, como conexão com o banco de dados? Ele se conecta ao banco de dados toda vez ou gerencia a conexão com o banco de dados separadamente para executar chamadas como é feito em aplicativos de servidor?

Como um aplicativo sem servidor não mantém nenhum estado entre as execuções, ele não pode manter um pool de conexão com o banco de dados. Aplicativos sem servidor realmente enfrentam as mesmas restrições que os scripts CGI dos anos 90. Em geral, um processo permanente do servidor poderá superar uma arquitetura de processo por solicitação ou contêiner por solicitação, porque o servidor inicializa uma vez, não uma vez por solicitação.

Os programas sem servidor não são adequados para tarefas sensíveis à latência, como veicular um site. Eles são mais adequados para tarefas em segundo plano esporádicas que você não deseja executar no servidor principal, sem precisar gerenciar e balancear manualmente servidores de aplicativos extras. Eles também podem ser adequados se a produtividade do desenvolvedor for muito mais importante que as respostas de baixa latência.

Depende.

A implementação nos bastidores do corredor lambda afetará isso. Podemos ver que na AWS o contêiner pode ser reutilizado.

http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html

Portanto, pudemos ver o pool de conexão / reutilização para algumas solicitações, pelo menos. Também devemos considerar o próprio banco de dados e como ele trata as solicitações de conexão recebidas.

Esse tipo de pergunta para mim sublinha que alguns dos problemas com 'sem servidor' ainda são muito novos e imaturos, portanto os detalhes não foram detalhados.

Devemos sempre lembrar que sem servidor não significa nenhum servidor. Se a taxa na qual você chama um lambda for alta o suficiente, você poderá efetivamente ter vários servidores ou 'contêineres' em execução.

Na prática, o tempo de inicialização e os recursos, como endereços IP de lambdas, podem ser um problema real. Talvez, à medida que amadureçam, apareça um consenso sobre como executá-los e esses problemas obtenham respostas sólidas.