Le architetture Serverless, un’anticipazione di futuro, con qualche brivido

3

In principio è stata la virtualizzazione. Se l’hardware è così potente, perché non usarlo per erogare più di una singola macchina? E così le server farm, hanno iniziato ad essere popolate da insiemi di host, macchine che erogavano macchine. E perché non rendere tutto questo un servizio? Boom. Era arrivato il cloud (il computer di qualcun altro, ndr).

Ma se l’obiettivo ultimo è comunque quello di erogare i servizi, perché non concentrarsi su questi? Limitare cioè l’esborso richiesto da una macchina virtuale al minimo indispensabile, usando ambienti a singolo processo, in un… Container?

Ecco, se dopo questo lungo preambolo pensate che con la narrazione siamo arrivati al presente, beh in realtà manca ancora un piccolo pezzo: le architetture Serverless.

Già perché i grossi vendor e provider come Amazon hanno iniziato, unitariamente all’offerta delle macchine virtuali, degli ambienti container come Kubernetes ad offrire anche solo ed esclusivamente servizi, attraverso piattaforme come AWS Lambda.

Proprio Lambda nella sua homepage recita:

You pay only for the compute time you consume.

Paghi solo il tempo computazionale che consumi

Ed a conti fatti, anche se ovviamente dipendentemente dal prezzo, questo tipo di approccio può tornare oggettivamente utile nelle situazioni a workload variabile, in cui solo a fronte di picchi di richieste interessa essere pronti ad erogare i servizi senza perdite di performance.

Il problema è che il tempo computazionale pagato include anche quello speso per errore, come nelle storie che vengono raccontate in questo bell’articolo di the New Stack intitolato Serverless Horror Stories.

Si parte dal programmatore che eroga il proprio blog mediante Lambda e, sbagliando una routine si ritrova con una fattura che in una notte da 5 dollari arriva 800, per passre all’ingegnere che realizza come in ambienti con workload fisso (dove per definizione le architetture Serverless pagano pegno, in quanto pensate per i workload variabili) si perde il 15% delle performance e si paga otto volte tanto, per concludere con l’azienda che, a causa di un problema di performance con un servizio Database Serverless, perdeva 300k dollari l’anno.

Insomma, come per tutte le cose, anche questa mirabolante nuova tecnologia ha una sua precisa collocazione, e soprattutto il suo utilizzo deve essere subordinato a degli attivi sistemi di controllo che possano avvertire prontamente sulle variazioni sensibili, poiché da 5 a 800 dollari diventa una brutta giornata, ma da 5000 a 800.000 si rischia l’infarto!

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

3 risposte a “Le architetture Serverless, un’anticipazione di futuro, con qualche brivido”

  1. Avatar JaK
    JaK

    L’articolo linkato, “Serverless Horror Stories” è interessante, ma ho trovato la conclusione un po’ “commerciale”. Gran parte degli errori narrati sarebbero stati evitati se si fosse fatto un serio piano testing delle applicazioni, utilizzando per il system-test un’istanza simulata dei servizi AWS.
    Per “testing” non intendo dire “famo dù prove!”, ma una serie di procedure automatiche che ogni sera vengono eseguite e, se falliscono, vengono salvate e integrate in un rapporto.
    L’uso di Next-generation tooling: Specialized AI-driven platforms like Tundra mi suona come usare una bomba a neutroni per accendere una sigaretta

  2. Avatar JustATiredMan
    JustATiredMan

    Mha, sarà… ma tutto mi da l’idea di essere cicliclo. Cos’altro è questo se non la versione moderna di quanto avveniva con i primi computer negli anni 50-60 dove si pagava per l’utilizzo ?
    Cos’altro non è il moderno concetto di applicazioni web, dove il tutto viene eseguito in un server remoto, e il browser funge da output, de non il vecchio modello server-centrico e terminali dei vecchi mainframe ?
    Certo, le tecnologie cambiano, e le cose vengono rese piu user friendly, abbiamo il multimedia etc. ma dal punto di vista concettuale rimangono cose già viste.

  3. Avatar Bios
    Bios

    Il prossimo step sarà il Thinking As A Service e il Brain As A Service.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *