Phenquestions
Computer fisici
Abbiamo fatto molta strada dai grandi server dell'era delle dotcom. A quei tempi, l'infrastruttura dei server era per lo più on-premise. Un'azienda gestiva le sue soluzioni su un server fisico. Le persone hanno utilizzato interi server separati per scopi diversi (backup, server di posta, server Web, ecc.). Quando un determinato server non riusciva a tenere il passo con le crescenti esigenze dell'azienda, veniva sostituito da un server più nuovo e più veloce. Hai scalato ottenendo hardware migliore. Hai scalato verticalmente.
Hypervisor
Poi è arrivata l'era degli hypervisor. Ha guadagnato slancio con l'ascesa di VMWare e le persone si sono rese conto che potevano avere un rack per dominarli tutti. Un rack per eseguire tutti i vari casi d'uso e fornire a ciascuno di essi la propria macchina virtuale separata. Ciò ha anche dato origine al cloud computing e le aziende hanno smesso di investire direttamente nell'hardware dei server e hanno scelto invece di "affittare" i server virtuali.
Enormi e costosi data center sono stati gestiti da provider cloud in tutto il mondo. Le aziende ne hanno tratto vantaggio fornendo i propri servizi a livello globale, utilizzando la più ampia gamma possibile di data center. Ciò è stato fatto principalmente per ridurre le latenze, migliorare l'esperienza del cliente e mirare a un mercato più ampio.
Ciò ha fatto pensare anche agli autori di software in termini di sistemi distribuiti. Hanno scritto software per funzionare non su un singolo computer gigante, ma su molti computer mediocri in modo coerente e affidabile. Hai ridimensionato orizzontalmente.
Puoi ancora ridimensionare verticalmente. Infatti, grazie alla virtualizzazione, il provisioning di più risorse è diventato più semplice. Hai spento la VM, regolato le sue risorse e pagato un piccolo extra al tuo provider cloud. Pezzo di torta.
I server fisici sottostanti non sono scomparsi. I fornitori di servizi cloud sono ora responsabili della gestione della complessità delle interfacce di rete, della compatibilità del sistema operativo e di altre patologie terrificanti.
Contenitori
Poi sono arrivati i contenitori. I contenitori erano questa incredibile astrazione leggera. Un ambiente virtuale con un sistema operativo che consente di impacchettare e distribuire il software come una singola unità. Come le macchine virtuali, ogni contenitore è stato eseguito inconsapevolmente di altri contenitori, ma condividevano lo stesso kernel del sistema operativo.
Ciò ha permesso alle persone di distribuire software su server (fisici o virtuali non importa) a un livello di astrazione ancora più elevato. Non ti importava del sistema operativo di produzione. Finché supporta la tua tecnologia di containerizzazione, eseguirà il tuo software. Inoltre, i container sono più facili da avviare, il che ha reso i servizi più scalabili che mai.
Ciò ha ulteriormente aumentato la flessibilità dei sistemi distribuiti. Con tecnologie come Kubernetes puoi avere legioni di container che eseguono una serie complessa di servizi. I sistemi distribuiti offrono molti vantaggi, alta disponibilità, robustezza e capacità di autoguarirsi da un guasto del nodo.
Allo stesso tempo, poiché sono così complessi, sono anche più difficili da progettare, distribuire, mantenere, monitorare ed eseguire il debug. Questo è contro la tendenza originale di astrarre la complessità dal tuo software e delegare tale responsabilità al tuo provider cloud. È qui che entra in gioco l'architettura serverless.
Serverless o Function-as-a-Service (FaaS)
L'idea del serverless ha guadagnato terreno soprattutto grazie ad AWS Lambda, e qui lo userò come modello per parlare di serverless. I principi su cui si basa FaaS sono:
- Paghi per quello che usi
- Non devi preoccuparti del ridimensionamento
- Ti concentri sul tuo codice, lasci la gestione dell'infrastruttura ad AWS
Quando nessuno accede ai tuoi servizi, i servizi non sono attivi. Questo non era il caso delle tradizionali soluzioni di hosting dove si paga per un VPS sempre attivo e funzionante, anche se fermo non facendo nulla di più utile che ascoltare una nuova richiesta.
Nell'architettura serverless il tuo servizio non è in esecuzione a meno che qualcuno non voglia effettivamente usarlo. Quando arriva una richiesta, viene creato un servizio al volo per gestirla.
Come funziona?
La tua funzione (ad esempio un programma Python, Go o Java) si trova come file su AWS Lambda. Con questa funzione associ determinati eventi trigger, come un gateway API, o un nuovo oggetto che entra nel tuo bucket S3. E alcune risorse come un database o un altro archivio di oggetti o un'istanza EC2.
In risposta a uno qualsiasi degli eventi trigger associati, AWS Lambda crea un container con la tua funzione al suo interno. La funzione viene eseguita e fornisce una risposta. Ad esempio, se una nuova immagine arriva nel tuo bucket S3, AWS Lambda può avere un codice di machine learning al suo interno, che analizzerà questa immagine e scriverà il suo output su un DynamoDB (uno dei servizi di datastore di AWS).
Non devi pagare per un intero server ma solo per la quantità di memoria che hai assegnato alla tua funzione, il numero di richieste che ricevi e per quanto tempo viene eseguita la tua funzione.
Inoltre, non devi preoccuparti di ridimensionare i container in risposta a un pesante carico di lavoro in entrata. Se si verificano molti eventi trigger contemporaneamente, AWS si occuperà di avviare nuovi container e pianificare i carichi di lavoro tra di essi e tutte le altre complessità.
Non è una soluzione completa
Quando sono arrivate le macchine virtuali, i server fisici non hanno cessato di esistere. Quando sono arrivati i container, usavamo ancora le VM. Il FaaS è un'astrazione di livello superiore e si adatta molto bene al design moderno di API RESTful, servizi senza stato e linguaggi leggeri come Node.js o Python.
Tuttavia, funziona ancora su un server fisico (gestito da AWS, ad esempio), ascolta ancora le richieste in arrivo (non le paghi direttamente) e devi ancora archiviare i dati in modo persistente, motivo per cui ha integrazioni per S3, EC2 e altri servizi. È comunque un'astrazione utile.
