In che modo le architetture senza server gestiscono le connessioni al database?

Poiché un'app serverless non mantiene nessuno stato tra le esecuzioni, non può mantenere un pool di connessioni al database. Le app serverless devono affrontare gli stessi limiti degli script CGI degli anni '90. In generale, un processo server permanente sarà in grado di sovraperformare un'architettura processo per richiesta o contenitore per richiesta perché il server esegue l'inizializzazione una sola volta, non una sola volta per richiesta.

I programmi serverless non sono particolarmente adatti per attività sensibili alla latenza come la pubblicazione di un sito web. Sono più adatti per attività di background sporadiche che non si desidera eseguire sul server principale, senza dover gestire manualmente e bilanciare il carico di server di applicazioni aggiuntivi. Possono anche essere accettabili se la produttività degli sviluppatori è molto più importante delle risposte a bassa latenza.

Dipende.

L'implementazione dietro le quinte del lambda runner inciderà su questo. Possiamo vedere che in AWS il contenitore potrebbe essere riutilizzato.

link

Quindi potremmo vedere il pool di connessioni / riutilizzo almeno per alcune richieste. Inoltre dovremmo considerare il database stesso e il modo in cui tratta le richieste di connessione in entrata.

Questo tipo di domanda per me sottolinea alcuni dei problemi con "serverless" è ancora molto nuovo e immaturo, quindi i dettagli non sono stati risolti.

Dobbiamo sempre ricordare che serverless non significa nessun server. Se la velocità con cui chiami un lambda è abbastanza alta, potrebbe avere effettivamente più server o "contenitori" in esecuzione.

In pratica il tempo di avvio e le risorse come gli indirizzi IP di lambda possono essere un problema reale. Forse mentre maturano, apparirà un consenso su come eseguirli e questi problemi avranno risposte solide.