Architettura senza server: come implementare le modifiche nella logica aziendale comune?

Question

Architettura senza server: come implementare le modifiche nella logica aziendale comune?

#1 da (1 voti)
#2 da (0 voti)

4

Di recente ho sentito parlare sempre più di architetture serverless basate su prodotti come AWS Lambdas, funzioni di Azure, funzioni di Google Cloud, ecc.

Comprendo vantaggi dell'utilizzo di tali architetture, ma ciò che mi sfugge è il modo in cui piccoli componenti della logica aziendale possono essere condivisi in modo efficiente tra quelle funzioni. Darò un esempio:

Il back-end della mia app è composto da un gruppo di funzioni implementate in uno dei servizi sopra menzionati. Ognuna di queste funzioni utilizza un framework di registrazione. Non vorrei mettere la logica di logging in una funzione a sé stante perché non voglio il sovraccarico di effettuare una chiamata di funzione remota ogni volta che voglio registrare qualcosa. Il problema sorge quando voglio apportare una modifica al framework di registrazione. Ora, ho bisogno di ri-distribuire TUTTE le funzioni che usano questo framework per applicare la modifica.

Al contrario, nelle architetture "regolari", avrei solo bisogno di distribuire l'applicazione, il che è qualcosa che probabilmente farò comunque una volta in poco tempo.

Quindi, è un problema intrinseco con queste architetture senza server? o mi manca qualcosa?

lambda cloud-computing aws

posta the-lights 13.06.2016 - 07:53

fonte

2 risposte

0

AWS e forse altri forniscono un servizio integrato per la registrazione che sei invitato a utilizzare. Se non si desidera utilizzarlo, è probabilmente necessario spostare un oggetto in un archivio cloud.

In una classica architettura della funzione lambda, il tuo servizio viene lanciato su chiamata, le risorse vengono assegnate per la durata del programma, quindi fred. In genere non si ha accesso alla persistenza del sovraccarico, perché una volta terminata l'esecuzione del servizio, le risposte non sono disponibili.

Per il modello di implementazione, per quanto ho capito, AWS lamba non offre la possibilità di usare una lib per diversi pacchetti per quanto ho capito; dovresti comprimere tutti i servizi in un unico pacchetto di distribuzione con la libreria inclusa, che non è un'architettura molto scalabile.

risposta data 13.06.2016 - 09:36

fonte

Leggi altre domande sui tag lambda cloud-computing aws

Possibili problemi di prestazioni che implementano il database multi-tenant? rami, build, rilasci e multi-piattaforme

score 1 · Accepted Answer

Architettonicamente, ha senso implementare un componente condiviso di questo tipo separatamente in modo che le sue preoccupazioni fossero correttamente isolate dalle altre. Invece di chiamarlo come componente interno, si invierà una chiamata (potenzialmente ignifuga) a un'altra "funzione" per la registrazione a livello di sistema. Ciò ha anche senso per la scalabilità, poiché quando il sistema si ridimensiona in base alla richiesta, il componente del logger potrebbe diventare un collo di bottiglia a meno che non si riduca.

Se doveva essere un componente condiviso (ad esempio una logica o una libreria comune), un modo per mitigare i problemi di distribuzione è con l'integrazione / generazione / distribuzione continua che automatizza il testing, il packaging e la distribuzione (test). dovresti dover ridistribuire tutte le funzioni ~~microservices~~ con il componente condiviso aggiornato. Tuttavia, con una buona integrazione e processi di implementazione, è possibile mitigare i rischi scoprendo i problemi prima della piena implementazione. Ad esempio, vedi distribuzione blu / verde . È un lavoro extra sviluppare i processi di distribuzione, ma poiché i processi continui * hanno valore per altri motivi, è un compromesso facile per molti team.