La virtualizzazione e la SOA nel datacenter hanno descrittp ad allocato un numero di servizi sempre più alto e hanno determinato una sempre più frequente perdita di controllo dei servizi installati e dei rispettivi centri di costo. Un segnale per verificare lo stato dell’arte è quello di capire anche da un punto di vista tecnico che manca uniformità nel modo con il quale i servizi sono erogati e, di conseguenza, anche consumati.

Poche aziende che hanno implementato seriamente le Enterprise Architecture possono ora trovarsi ad avere uniformità di erogazione dei servizi. Sempre più poche realtà hanno un catalogo ordinato di questi servizi e hanno la capacità di governarli con una ottica moderna.

Il fenomeno del Cloud computing sta portando il paradigma dell’As A Service per l’infrastruttura, per le Piattaforme e per il Software in se stesso. E ad oggi per comprendere tali servizi, il mercato ci sta offrendo soluzioni tecniche. Le soluzioni tecniche per infrastruttura sono legate alla virtualizzazione e quindi sono legate alla possibilità di erogare istanze virtuali con una capacità di provisioning rapida.

Questo vale anche per le piattaforme. L’atteggiamento tecnico verso le piattaforme sta dimostrando come sia possibile andare a esporre un application server, un database o delle funzionalità di integrazione a consumo secondo il modello di Platform As A Service. Questo è il caso di Cloud Bees che ha portato la Continuous Integration a questo nuovo sistema. Il suo target è stato inizialmente per tecnici.

Il Platform As A Service è però un paradigma che sta pian piano crescendo e che si sta manifestando lentamente.  Potenzialmente ogni soluzione aziendale e ogni realtà dovrebbero fare dei pensieri piuttosto seri riguardo all’evoluzione della propria architettura SOA a una piattaforma PAAS. Andare verso una piattaforma significa avere la capacità di esporre la propria infrastruttura come se fosse un framework sul quale poter scrivere e installare delle nuove componenti applicative ad estensione della infrastruttura stessa.

Un esempio che si può pensare è quello di esporre i servizi sanitari come se fossero delle API del sistema sanitario ed offrire la possibilità di installare i nuovi servizi estesi ed emergenti all’interno della piattaforma sanitaria. Quindi una applicazione sanitaria di gestione di un ospedale, potrebbe diventare un trampolino di lancio per nuove applicazioni che vogliono usare quella specifica piattaforma sanitaria.

Questa è una delle evoluzioni di business che il cloud sta portando e che le applicazioni e le architetture SOA dovranno affrontare sia da un punto di vista di sicurezza, che da un punto di vista operativo e di governance. I C*O si devono chiedere come poter ri-usare tutto il knowledge che hanno maturato all’interno della loro soluzione per poterlo esporre e facilitare la nascita di nuove funzionalità estese da terzi per poter affrontare un mercato a loro ancora ignoto.

Una volta consapevolizzata questa domanda è necessario stabilire un percorso in cui si pensi a classificare i propri servizi e in cui si possano erogare e governare in futuro. La complessità di gestione aumenta ed è necessario essere cauti nel decidere quali servizi debbano essere esposti in virtù delle loro caratteristiche specifiche.

Pensare al muovere una applicazione o una architettura a Piattaforma necessità di studiare il ciclo di vita della piattaforma stessa. Come in tutte le soluzioni che richiedono la progettazione di un lifecycle si deve capire quali sono i servizi crosscut che vogliono essere esportati e la modalità di erogazione dei servizi stessi. Parallelamente bisogna costruire un catalogo che descriva i servizi che sono disponbili e racconti le loro policies di governo.

Un wiki semantico è un buon punto di partenza per andare a descrivere e censire tutti i servizi che fanno parte della piattaforma. Nella loro descrizione è fondamentale andare a specificare le diverse caratteristiche di ogni servizio. Caratteristiche che sono legate al business, al requisito e che sono più vicine a tutti gli investimenti e ai ricavi legati al servizio stesso. Di ogni servizio si devono describere i modelli, i metodi di invocazione e tutte le sue caratteristiche legate alla security, alla privacy e i suoi Livelli di Servizio espressi.

In questo modo si riesce ad avere una topologia e una definizione di tutti i servizi che sono esposti e questa topologia è leggibile da macchine per via della sua natura.

Questo lavoro si identifica anche per la qualità con la quale sono riordinati e catalogati i servizi e con il quale i servizi sono poi mantenuti durante la loro vita. La soluzione semantica di Sensiblelogic permette di raccogliere un insieme di informazioni e di mantenerle ordinate. Ogni ruolo aziendale può lavorare sulle informazioni arricchendole per il proprio contesto.

Sfruttando anche una piattaforma di governance dei singoli servizi è possibile descrivere anche come il singolo servizio si comporta in relazioni a carichi o alle situazioni in cui questo servizio si trova di fronte. Si specificano quindi le politicche con le quali si descrivono l’elasticità del servizio, la resilienza e la modalità di erogazione del servizio stesso.

Sfruttando sense™ di Sensible Cloud, siamo in grado di poter governare i servizi e la lroo modalità di erogazione considerando kpi di infrastruttura, di piattaforma e di business.

Questo ci permette di mantenere traccia di tutte le azioni che sono prese in automatico su un servizio durante il ciclo di vita del servizio stesso. Le azioni intraprese, così come le policies di SLA, vanno ad aumentare la knowledge base del servizio stesso sul wiki semantico.

Un sistema di frontend può essere utilizzato per pubblicare le API e renderle pubbliche per richieste esterne. Questo sistema può essere a sua volta un Enterprise Service bus che raccoglie l’informazione, la completa attraverso la piattaforma di governance che è in grado di analizzare il tipo di richiesta per andare a caricare il servizio corretto e misurare la spesa fatta da un utente.

Il proprio sistema in questo modo evolve e queste nuove capacità gli permettono di essere esteso esternamente. L’azienda inizia ad erogare il proprio sistema come piattaforma ed è possibile costruire nuove applicazioni che usino e estendano il sistema. Sviluppare una applicazione per iPad o per Android non richiede più lo scrivere di nuovi servizi di wrapping, ma richiede solo l’abilitazione all’uso delle singole API già dichiarate.

La necessità di muoversi a una piattaforma non richiede il fatto che la piattaforma sia per definizione pubblica. Anche il Platform As A Service può essere privato ed è auspicabile che i primi passi del PAAS inteso come offerta siano per di più privati.