Platformization 102: i modelli architetturali a confronto

Nella puntata precedente abbiamo provato a dare una prima, veloce e non dettagliata introduzione al concetto di piattaforma. In particolare abbiamo analizzato quali sono – o, almeno, quali dovrebbero essere – i principali benefici che la scelta di questo tipo di strumento può portare all’interno della quotidianità aziendale. Tutto questo, rimanendo (volutamente) ad un livello di dettaglio molto alto.

Scopo di questo articolo è quello di analizzare nello specifico alcuni aspetti “architetturali” che vanno tenuti in considerazione quando si intende ponderare la scelta di una piattaforma quale mezzo di miglioramento delle attività che si svolgono all’interno dell’azienda e/o dei processi che compongono ciascuna di esse.

Ma prima, è opportuno riprendere un concetto che abbiamo “sfiorato” nel nostro precedente articolo…

Come già detto, il concetto di Piattaforma e quello di Cloud oggi vengono (molto spesso) confusi e/o associati. Effettivamente questi due termini sono fortemente collegati l’uno all’altro ma non sono di certo un sinonimo!

Il concetto di Piattaforma esiste già da molti anni ed in diverse “aree” del mondo IT: da quanti anni scriviamo documenti utilizzando il nostro programma di scrittura preferito? A suo modo, quel programma è una piattaforma, in quanto ci offre la possibilità di redigere un documento utilizzando una serie di Strumenti che ci consentono di formattare, impaginare, inserire immagini di gattini, colori, etc…
Nel corso degli anni quello stesso programma si è però evoluto, fino a consentirci addirittura di scrivere – quello stesso documento descritto sopra – mentre siamo seduti comodamente sul divano di casa (invece che davanti al nostro computer), grazie ad un’app presente all’interno del nostro dispositivo mobile (Smartphone e/o Tablet).
Infine, oggi ci troviamo di fronte alla possibilità non soltanto di poter scrivere quel documento utilizzando un’applicazione dedicata, ma anche di poterlo fare “Online” – cioè, utilizzando il nostro browser preferito – e addirittura di poterlo condividere con i colleghi, eliminando così la scocciatura del “ping pong” di continue revisioni e/o versioni di documenti da dover integrare (con conseguente sforzo immane).

Ebbene, “dietro alle quinte” di tale innovazione del nostro programma preferito di scrittura altro non c’è che il Cloud, in grado di rispondere alle crescenti esigenze del prodotto (scalabilità) riducendo drasticamente il TCO della soluzione end-to-end (costi).

“Ok boomer, ma perché stiamo parlando di documenti, gattini e cloud?”

un lettore confuso

Lo stiamo facendo perché questo semplice esempio ci dimostra la relazione che sussiste tra il concetto di piattaforma e quello di cloud, in relazione al caso d’uso specifico che si vuole realizzare.

Modelli architetturali di riferimento

Cerchiamo di portare i concetti appena descritti all’interno di scenari architetturali che offrano supporto all’implemetazione efficace ed efficiente dei casi d’uso aziendali. Soffermiamoci su quelli che potremmo chiamare – forse erroneamente – modelli architetturali di riferimento: con questi termini si intende l’insieme dei comuni paradigmi di implementazione di scenari applicativi complessi all’interno delle aziende, incentrati sul coinvolgimento di una piattaforma che – sempre di più – risiede in cloud.

Quella riportata nell’immagine è una rappresentazione della pila di componenti che sono necessari a supportare l’esecuzione di un’applicazione (in uno scenario “tipico”). Al suo interno, risultano evidenziati i componenti “a carico” dello sviluppatore (in blu) e del gestore dell’infrastruttura (in grigio), per uno scenario di Platform as a Service (PaaS) cloud-based.

Due però sono i modelli architetturali che una Piattaforma in cloud di moderna generazione è in grado di offrire al cliente/sviluppatore che vi si rivolge:

1. Piattaforma “pura” – in questo particolare modello, l’approccio allo sviluppo prevede che vengano selezionati, istanziati ed utilizzati i vari (micro-)servizi che la piattaforma stessa è in grado di offrire.

Una precisazione: con il termine (micro-)servizio ci riferiamo a una componente software che consente di coprire un sotto-caso d’uso specifico della nostra applicazione, senza obbligarci a dover implementare – seppur in quota parte – tale funzionalità. Sono di fatto degli acceleratori che, attraverso l’inclusione all’interno dell’applicazione, mi consentono di snellire lo sviluppo e di semplificarne la gestione dell’intero ciclo di vita (design, implementazione, test, rilascio e aggiustamenti/estensioni).

Secondo questo modello architetturale, la piattaforma svolge il ruolo di attore protagonista nella realizzazione dell’applicazione riducendo drasticamente il tempo necessario ad implementare e/o gestire l’applicazione stessa, senza richiedere investimenti cospicui preliminari: il costo totale delle risorse di piattaforma, comprese all’interno della soluzione, cresce sulla base dell’utilizzo che viene fatto di questa.

Se volessimo tornare al caso d’uso precedente – quello del programma per redigere testi – questo modello architetturale comprende l’utilizzo di tutte le funzionalità che mi vengono messe a disposizione dallo stesso. Se per esempio volessimo inserire un’immagine all’interno del nostro foglio, ci sarà sufficiente attivare la funzionalità di importazione immagini e scegliere il file da caricare.

Di contro, la maggiore flessibilità fa sì che la nostra applicazione sia (direttamente o indirettamente) collegata al ciclo di vita ed alle limitazioni dei (micro-)servizi che essa stessa utilizza. Eventuali operazioni di migrazioni dell’applicazione ad una nuova piattaforma, dovranno obbligatoriamente prevedere una serie di aggiustamenti ed adeguamenti per sfruttare i servizi della piattaforma di atterraggio (aka, refactor dell’applicazione).

2. Piattaforma per la virtualizzazione – questo modello ha cominciato a stuzzicare l’interesse delle aziende negli ultimi periodi (~2 anni) e poggia le sue radici sui concetti di Orchestrazione di Container all’interno dei quali vengono eseguite applicazioni (strutturate, solitamente, secondo il paradigma a micro-servizi).

Tecnicamente parlando (ma non troppo…giuro!) questo approccio consente ad uno sviluppatore di “dimenticarsi” dello stack che supporterà l’esecuzione della propria applicazione, delegando ad un set opportuno di “immagini” – e qualche riga/script di configurazione – il setup di tutta l’infrastruttura. Chiaramente, in scenari molto complessi, questo tipo di approccio risulta molto flessibile – dal punto di vista dello sviluppatore – ma allo stesso tempo non garantisce livelli di scalabilità in scenari di “esecuzione distribuita”. Anche per questo motivo si è resa necessaria l’introduzione di uno strato di orchestrazione di tali immagini che ha visto emergere una tecnologia sulle altre: Kubernetes.

Leggendo quanto scritto sopra e tra le righe della descrizione di quello che fa questo (potente) strumento, qualcuno potrebbe chiedersi perché stiamo parlando di una piattaforma di virtualizzazione di infrastrutture? -> Giusta osservazione…

Il perché è presto detto: questo potente strumento – che, tra l’altro, è alla base di molte delle piattaforme che offrono servizi in Cloud nella formula PaaS – viene spesso messo a disposizione degli sviluppatori come servizio “di piattaforma”, offrendo quindi la possibilità di diversificare l’approccio allo sviluppo, che non per forza si lega ai servizi pre-confezionati che questa mette a disposizione.

Come mostrato in figura, l’orchestratole di container è il punto di riferimento dello sviluppatore all’interno della piattaforma (non è egli stesso la piattaforma!): i suoi sforzi sono focalizzati non soltanto nella scrittura del codice, ma anche sulla configurazione del comportamento che l’orchestratore stesso dovrà seguire nel gestire le immagini che costituiscono l’applicazione. Ma non finisce qui! Vi ricordate i (micro-)servizi che abbiamo descritto al punto 1? Bene, questi sono sempre disponibili all’interno della piattaforma, ma questa volta non è compito dello sviluppatore configurare direttamente la comunicazione con gli stessi, quanto piuttosto dell’orchestratore che – servendosi di un opportuno broker – si fa carico di offrire un’interfaccia verso tali servizi, successivamente utilizzata dallo sviluppatore.

I vantaggi di questo approccio sono principalmente legati alla “libertà di movimento” della quale gode lo sviluppatore. Con questo tipo di approccio “ibrido” è infatti possibile strutturare non soltanto le applicazioni ma anche l’ambiente all’interno del quale queste gireranno. I servizi “puri” offerti dalla piattaforma diventano “accessori” che si possono includere all’interno del proprio ambito applicativo con l’intermediazione dell’orchestratore.

Ma, come per il caso precedente, anche in questo caso ci sono luci e ombre: gli svantaggi di questo tipo di approccio sono sicuramente legati al “conto” che si deve pagare per godere della flessibilità appena descritta. È opportuno sottolineare che questo tipo di approccio porta con se gli svantaggi tipici di uno scenario che prevede la gestione di un’infrastruttura (seppur virtualizzata ed estremamente automatizzata come quella di Kubernetes), la quale va a pesare alla fine sul TCO generale della soluzione.

Per concludere…

Quelli visti sopra sono due modelli architetturali con i quali oggi le aziende si trovano a confrontarsi – o che lo faranno in futuro – soprattutto in vista del “trasloco verso il cloud” di alcune/molte delle soluzioni che oggi si trovano in casa. In quest’ultimo caso, il secondo modello è quello che offre minori barriere all’ingresso visto che l’effort richiesto per effettuare la migrazione è sicuramente più basso rispetto al dover riscrivere le logiche applicative per sfruttare i servizi offerti dalla piattaforma.

Tuttavia però questo effort richiesto, se andiamo a calarlo all’interno del TCO complessivo delle soluzioni, può ridursi drasticamente a fronte di una semplificazione della gestione del ciclo di vita dell’applicazione, comandata dall’utilizzo di “servizi avanzati” che vengono offerti dalle piattaforme. Solitamente, infatti, ci soffermiamo a pesare le componenti tecnologiche che le varie piattaforme offrono – perché, d’altronde, siamo sempre informatici … – ma il vero valore aggiunto che una piattaforma può offrire ai clienti, sta in quel set di servizi che potremmo chiamare “di Business”, il cui compito è quello di accelerare l’integrazione delle applicazioni, non soltanto dal punto di vista di flussi dati, chiamate a servizi applicativi, etc… (cioè tecnologicamente) quanto piuttosto a livello di processo gestito dai sistemi aziendali, sfruttando di conseguenza tutti gli automatismi, le regole di validazione, le notifiche, etc… che questi si portano dietro.

In quest’ultimo caso, progettare un’applicazione tenendo conto di questo tipo di vantaggio risulta vincente in una strategia di platformization di medio-lungo periodo.

Proveremo a chiarire questo (ed altri) aspetti nelle prossime puntate, per oggi basta così…vi ho già stressato a sufficienza!

Alla prossima,
Stay tuned!