{"id":33935,"date":"2019-10-31T21:55:27","date_gmt":"2019-10-31T18:55:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/serverless-po-stoechkam\/"},"modified":"2019-10-31T21:55:27","modified_gmt":"2019-10-31T18:55:27","slug":"serverless-po-stoechkam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/serverless-po-stoechkam","title":{"rendered":"Serverless a rack","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nServerless non significa l'assenza fisica di server. Non \u00e8 un \"killer\" dei container n\u00e9 una moda passeggera. \u00c8 un nuovo approccio alla costruzione dei sistemi nel cloud. Nell'articolo di oggi tratteremo dell'architettura delle applicazioni Serverless, vedremo quale ruolo gioca il provider dei servizi Serverless e i progetti open-source. Alla fine parleremo delle questioni relative all'applicazione del Serverless.
\n<\/a><\/noindex>
\nVoglio scrivere la parte server dell'applicazione (anche un negozio online). Potrebbe essere una chat, un servizio per la pubblicazione di contenuti o un bilanciatore di carico. In ogni caso, ci saranno molte preoccupazioni: dovr\u00f2 preparare l'infrastruttura, definire le dipendenze dell'applicazione e riflettere sul sistema operativo dell'host. Poi dovr\u00f2 aggiornare piccoli componenti che non influenzano il funzionamento del resto del monolite. E non dimentichiamoci della scalabilit\u00e0 sotto carico.<\/p>\n

E se usassimo container efimeri, in cui le dipendenze richieste sono gi\u00e0 preinstallate, e i container stessi sono isolati l'uno dall'altro e dal sistema operativo dell'host? Suddivideremmo il monolite in microservizi, ognuno dei quali pu\u00f2 essere aggiornato e scalato indipendentemente dagli altri. Mettendo il codice in un tale container, posso eseguirlo su qualsiasi infrastruttura. Gi\u00e0 meglio. <\/p>\n

E se non voglio configurare i container? Non voglio pensare alla scalabilit\u00e0 dell'applicazione. Non voglio pagare per il tempo di inattivit\u00e0 dei container attivi quando il carico sul servizio \u00e8 minimo. Voglio scrivere codice. Concentrarmi sulla logica di business e portare i prodotti sul mercato a velocit\u00e0 della luce. <\/p>\n

Questi pensieri mi hanno portato al calcolo serverless. In questo caso, Serverless significa non assenza fisica di server, ma assenza di preoccupazioni nella gestione dell'infrastruttura.<\/em><\/p>\n

L'idea \u00e8 che la logica dell'applicazione venga suddivisa in funzioni indipendenti. Esse hanno una struttura basata su eventi. Ogni funzione esegue un \"micro-compito\". Tutto ci\u00f2 che \u00e8 richiesto allo sviluppatore \u00e8 caricare le funzioni nella console fornita dal provider cloud e abbinarle alle fonti di eventi. Il codice verr\u00e0 eseguito su richiesta in un container preparato automaticamente, e io pagher\u00f2 solo per il tempo di esecuzione. <\/p>\n

Vediamo ora come sar\u00e0 il processo di sviluppo di un'applicazione.<\/p>\n

Dal punto di vista dello sviluppatore<\/h2>\n

\nIn precedenza abbiamo iniziato a parlare dell'app per il negozio online. Nel metodo tradizionale, la logica principale del sistema \u00e8 eseguita da un'applicazione monolitica. E il server con l'applicazione \u00e8 attivo costantemente, anche se non ci sono carichi di lavoro.<\/p>\n

Per passare al serverless, suddividiamo l'applicazione in microtask.<\/strong> Per ciascuno di essi scriviamo la nostra funzione. Le funzioni sono indipendenti l'una dall'altra e non memorizzano informazioni sullo stato (stateless). Possono anche essere scritte in lingue diverse. Se una di esse 'crolla', l'applicazione non si fermer\u00e0 completamente. L'architettura dell'app sar\u00e0 simile a questa:<\/p>\n

\"Serverless
\nLa suddivisione in funzioni nel Serverless \u00e8 simile a quella dei microservizi. Ma un microservizio pu\u00f2 eseguire pi\u00f9 compiti, mentre una funzione, in teoria, dovrebbe svolgere uno solo. Immaginiamo di dover raccogliere statistiche e restituirle su richiesta dell'utente. Nel metodo a microservizi, questo compito viene eseguito da un singolo servizio con due punti di ingresso: uno per la scrittura e uno per la lettura. Nella computazione serverless, saranno due funzioni distinte, non collegate tra loro. Lo sviluppatore risparmia risorse computazionali se, ad esempio, le statistiche vengono aggiornate pi\u00f9 frequentemente di quanto vengano scaricate. <\/p>\n

Le funzioni serverless devono essere eseguite in un breve intervallo di tempo (timeout), che \u00e8 determinato dal fornitore del servizio. Ad esempio, per AWS il timeout \u00e8 di 15 minuti. Quindi, le funzioni a lungo termine (long-lived) dovranno essere adattate ai requisiti - questo \u00e8 ci\u00f2 che differenzia il Serverless dalle altre tecnologie popolari oggi (container e Platform as a Service).<\/p>\n

Assegniamo un evento a ciascuna funzione.<\/strong> L'evento \u00e8 un trigger per l'azione:<\/p>\n

Evento<\/strong>
\nL'azione che esegue la funzione<\/strong><\/p>\n

Un'immagine del prodotto \u00e8 stata caricata nello storage
\nComprimere l'immagine e caricarla nel catalogo<\/p>\n

L'indirizzo del negozio fisico \u00e8 stato aggiornato nel database
\nCaricare una nuova posizione sulle mappe<\/p>\n

Il cliente paga per il prodotto
\nAvviare il processo di pagamento<\/p>\n

Gli eventi possono includere richieste HTTP, dati in streaming, code di messaggi e cos\u00ec via. Le fonti degli eventi sono le modifiche o l'emergere di dati. Inoltre, le funzioni possono essere attivate tramite un timer.<\/p>\n

L'architettura \u00e8 stata sviluppata, e l'app \u00e8 quasi diventata serverless. Proseguiamo verso il fornitore del servizio.<\/p>\n

Dal lato del fornitore<\/h2>\n

\nDi solito, i calcoli serverless sono offerti dai fornitori di servizi cloud. Vengono chiamati in vari modi: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions. <\/p>\n

Utilizzeremo il servizio tramite console o area personale del fornitore. Il codice delle funzioni pu\u00f2 essere caricato in uno dei seguenti modi:<\/p>\n