Come si usa dire, prima o poi tutti i nodi vengono al pettine. E’ quello che sta succedendo anche grazie al cloud. Erogare in maniera agile necessità di eliminare un fardello che lo stack delle applicazioni enterprise si sta portando addosso. La SOA ci ha insegnato che dobbiamo partizionare la logica di business a servizi e che i servizi devono essere loro stessi coesi e resilienti. Questo presuppone, almeno da un punto di vista prettamente logico, che i servizi possano essere rilasciati in uno stack specifico e che questo stack debba essere il più leggero possibile
Gli application server sono evoluti per poter essere considerati una porzione di sistema operativo e quindi per permettere e fondare una piattaforma sulla quale poter installare in maniera standardizzata i propri servizi. Si capisce dal fatto che una delle attività dominanti nello sviluppo delle versioni degli application server sia stata l’esigenza di ridurre il tempo di boot dell’applicazione stessa oltre che le risorse che consuma. Quindi il sistema operativo deve essere più reattivo e in generale tutta l’infrastruttura di base deve essere nel più breve tempo disponibile. Le architetture sul cloud che vediamo sempre di più sono architetture che fanno provisioning e unprovisioning di servizi a caldo; sono architetture governate da logiche di Service Level Agreement direttamente sul servizio e hanno la necessità di espandersi e contrarsi rapidamente in virtù delle sollecitazioni o carichi che stanno subendo. L’architettura fisica perde un po’ di scopo dal momento in cui il dimensionamento e il capacity planning si perfeziona quando l’applicazione viene messa viva all’interno di un cloud. Proprio la capacità degli strumenti di governance allineano e dimensionano una architettura logica alla relativa implementazione fisica.
I servizi però devono poter essere governati agevolmente e il loro provisioning deve essere veloce ed efficace. NodeJS o il nuovo NodePHP stanno guadagnando strada proprio per questa caratteristica.
La loro caratteristica è il footprint basso e anche la loro velocità nel partire e rendere le applicazioni disponibili. Le applicazioni sono scritte in Javascript e in PHP e questo riusa molto dello skill. Si pensi a Javascript. Oggi è possibile e necessario sviluppare delle applicazioni lato web con Html5 e Javascript e tale competenza la si può riusare server side.
Nella pura ottica SOA NodeJS è un sistema di processing concorrente ad eventi su cui poter realizzare servizi che sanno rispondere reattivamente. JSON è l’incapsulatore del messaggio e diversi MQ che sanno fare veicolare JSON permettono l’integrazione con NodeJS.
Il cloud e il nuovo paradigma leggero identificato con node permette di costruire una sistema in grado di poter essere allocato on-demand e rapidamente. Avendo la possibilità di definire un Servizio come, potenzialmente, un singolo nodo di NodeJS si ottiene la possibilità di definire diversi livelli di granularità architetturale. A questo punto, un servizio può essere erogato come singleton sulla singola macchina oppure può essere erogato parallelamente sulla stessa o in parallelo su diverse instanze virtuali sfruttando il threading model del sistema operativo.
I nuovi sistemi di governance delle infrastrutture e delle applicazioni leggere, hanno ora la necessità di essere reattivi e hanno la possibilità di aggiustare la finezza di deployment dei singoli servizi nell’ordine di ottenere il massimo tra costi e benefici. Il cloud, con il suo paradigma nuovo del Pay Per Use, sta rendendo sempre più il capacity planning una esigenza di realtime. Fare planning realtime significa poter configurare una applicazione per un insieme di servizi e impostare la policy elastica sui singoli servizi in relazione allo SLA che il singolo servizio deve sottostare. La violazione degli SLA andrà a riconfigurare e adattare il modo con il quale i servizi sono erogati.
Quindi il cloud sta portando letteralmente i nodi al pettine. Applicazioni che hanno bisogno di molte risorse per funzionare e di molto tempo per partire non possono entrare a far parte della cultura elastica se non con una logica a pooling. Invece, applicazioni leggere come quelle basate su NodeJS o NodePHP o altri che permettono di mantenere la stessa informazione su più tiers stanno ricevendo maggior consenso.
Per la maggiore riusabilità del codice già prodotto VertX sta promettendo grandi cose oltre alla “canonicità”
di NodeJS!