Applicazioni cloud-native: come crearle secondo nuove prospettive di sviluppo

Ormai l’attività di progettazione delle moderne app sta palesemente aderendo al paradigma ‘cloud-native’, un fenomeno alimentato dalla diffusione in questi anni dell’onda d’innovazione del cloud: dopo la sua nascita, i servizi della nuvola si sono febbrilmente evoluti, attraverso ricerca e sviluppo, applicazioni, modelli innovativi in larga parte realizzati dai grandi player e provider globali, come Google, Amazon, Microsoft…

Le applicazioni cloud-native sono progettate e ingegnerizzate apposta per sfruttare appieno la natura dell’infrastruttura cloud: in confronto a quelle tradizionali, che usano server permanentemente designati al loro supporto, le app realizzate per ottimizzare i vantaggi dell’uso della nuvola funzionano affidandosi a una capacità di elaborazione che risulta disaccoppiata dalla rigida appartenenza a specifiche risorse hardware. Questa abilità di astrarre il funzionamento dell’applicazione dal legame con determinati server fisici porta vari benefici: chi sviluppa la app non si deve più preoccupare di amministrare e manutenere l’infrastruttura fisica, risparmia risorse, personale addetto, ha minori rischi e, soprattutto, può finalmente concentrarsi su ciò che per lui realmente conta, cioè lo sviluppo dell’applicazione e delle sue funzionalità. Chi migra verso l’approccio cloud-native per ottenere tutti questi benefici di praticità e convenienza non può però certo prescindere dall’abilità di padroneggiare la tecnologia che sta dietro le quinte di queste sfolgoranti opportunità di business.

ISCRIVITI

Verso il modello di sviluppo ‘API-first’

Lo sviluppatore che vuol creare applicazioni cloud native deve prima di tutto cambiare mentalità e guardare la progettazione da una nuova prospettiva: basta continuare a pensare che il codice applicativo debba per forza avere accesso diretto alle risorse hardware, come nelle tradizionali applicazioni monolitiche: la nuvola, certo, non avrebbe difficoltà a gestirle, ma creare app moderne, a proprio agio nel cloud, abili nello sfruttare i pregi di un’infrastruttura distribuita, elastica, scalabile a piacimento nell’utilizzo delle risorse IT, è tutta un’altra cosa.

Per la natura stessa del cloud, sviluppatori di app cloud-native si diventa soltanto attraverso una metamorfosi, dopo la quale il paradigma di sviluppo ‘API-first’ assume una priorità assoluta, venendo prima della definizione di qualsiasi altro requisito di progetto: prima, quindi, dell’ideazione di qualunque funzionalità della app mobile, o del dispositivo IoT (Internet of Things) che si sta sviluppando.

Partire con lo sviluppo ‘API-first’ prima di ogni altra cosa sottintende un accurato processo di documentazione, progettazione e costruzione della API (application programming interface) dell’applicazione, e questo si potrebbe considerare un inaccettabile vincolo di progetto, che obbliga a ‘congelare’ la creazione di tutte le altre caratteristiche e funzionalità dell’applicazione, finché non si è terminato lo sviluppo della API. Se non fosse che, fortunatamente, oggi sono accessibili online piattaforme open source di documentazione delle API, come API Blueprint: quest’ultima fornisce un linguaggio di descrizione ad alto livello per le API web, e permette di progettare e creare prototipi di API da realizzare, o di documentare e collaudare quelle già create. In sostanza, API Blueprint consente di attivare un mockserver API di test, che combina perfettamente con la documentazione della API, e con cui è possibile costruire e collaudare le integrazioni per la stessa rispetto a un reale servizio, ancor prima che la API venga completata.

Uno dei principali vantaggi dell’approccio API-first risiede nel fatto che è una filosofia di sviluppo in cui una scelta progettuale non pregiudica definitivamente altre variabili di progetto, ma è reversibile: non sempre infatti ha senso applicare questo approccio in qualunque caso d’uso, e se in fase di sviluppo ci si accorge che è inutile, si può sempre abbandonarlo senza perdere i progressi compiuti, o calare la produttività; d’altro canto, il rovescio della medaglia è che se si costruisce un’applicazione che richiede questa strategia senza prima pianificare lo sviluppo della API, ci si può infilare in un tunnel di problemi tecnici da cui uscire può richiedere molto tempo.

Filosofia serverless: far funzionare una app ‘senza i server’

Premesso che lo sviluppo API-first e lo sviluppo di applicazioni cloud-native sono concetti che non si escludono mutualmente, perché è possibile creare un’applicazione cloud-native senza una API, ed è possible realizzare un’applicazione API-first senza il cloud, esiste un caso in cui questi due concetti si fondono armonicamente assieme, ed è quello degli ambienti ‘serverless’: il modello serverless, attualmente, si può collocare al gradino più alto di evoluzione tra i livelli di astrazione oggi disponibili per lo sviluppo applicativo.

Ma cosa significa davvero serverless? Naturalmente, non vuol dire che la app, o la API, può funzionare senza server: significa invece che, al posto di usare i tradizionali server di un cloud provider geograficamente dislocati in precise località fisiche, la app funziona senza un’infrastruttura permanente, perché i server necessari vengono auto-creati solo per un determinato tempo (anche pochi millisecondi), scalati in base alla necessità della app, e poi sono eliminati quando non servono più, perché hanno terminato l’elaborazione dei suoi dati e funzioni. Questo approccio basato su microservizi significa per gli sviluppatori poter realizzare app e API serverless, in luogo delle tradizionali API REST: con una API serverless si evitano i problemi si sovracapacità nella creazione dei servizi di backend; i server scalano in automatico, e non si paga per il tempo in cui rimangono inattivi; l’infrastruttura gode di una solida affidabilità e disponibilità, e non ha necessità di funzioni di load-balancing, né di patch di sicurezza. Tra gli esempi più comuni di sviluppo del modello serverless si può citare il servizio AWS Lambda, di Amazon Web Services.