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

10

Il vantaggio principale dell'architettura senza server è che tali programmi non necessitano di un server dedicato per l'esecuzione continua. Quindi vengono invocati su una richiesta e si fermano all'uscita dalla funzione.

Ciò significa che un programma senza server dovrà essere rapido da avviare, per essere reattivo. In che modo quindi gestisce azioni che richiedono tempo come la connessione al database? Si collega al database ogni volta o gestisce separatamente la connessione al database per funzionare invocazioni come avviene nelle applicazioni server?

architecture server backend

— utente registrato
fonte

9

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

I programmi senza server non si adattano perfettamente ad attività sensibili alla latenza come servire un sito Web. Sono più adatti per sporadiche attività in background che non si desidera eseguire sul server principale, senza dover gestire manualmente e caricare i server delle applicazioni extra. Possono anche essere adatti se la produttività degli sviluppatori è molto più importante delle risposte a bassa latenza.

— amon
fonte

Punti eccellenti. Suggerirei anche che uno dei maggiori vantaggi che spinge la gente a serverless è il costo. Se stai pagando un provider (ad esempio Amazon) basato solo sul numero di richieste e non stai pagando per mantenere in esecuzione un server inattivo, risparmierai denaro soprattutto durante la fase di avvio.

— Paolo,

2

@Paul Il vantaggio principale di serverless è la comodità (PaaS vs. IaaS). L'amministrazione sicura di un server è uno skillset che la maggior parte degli sviluppatori (me incluso) non ha. Sono certo che ci sono alcuni scenari in cui serverless è notevolmente più economico. Ma i server privati virtuali partono da $ 5 / mese, il che è molto competitivo, per dirlo alla leggera. Soprattutto se si considera che un VPS ha molte meno restrizioni, consentendo di eseguire software arbitrario e servizi permanenti. Questo è un po 'un confronto tra mela e arance. In un modello si paga per un server inattivo, in un altro si paga per tempi di avvio ripetuti.

— amon,

4

Dipende.

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

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

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

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

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

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

— Ewan
fonte