Nel mondo del Cloud computing, è ormai chiaro che l’evoluzione va nella direzione di funzionalità per DevOps sempre più potenti, che diano insomma le capacità ad un developer di poter rilasciare le proprie funzioni di business nel più breve tempo possibile, dall’ambiente di sviluppo sul suo emulatore, all’ambiente cloud di test, fino poi alla produzione.

Già ormai da qualche anno abbiamo accesso al mondo dei Microservices, servizi web pensati e rilasciati con una granularità estremamente fine, differentemente da come accade invece per un normale rilascio di servizi web completi, dove tipicamente abbiamo due scenari possibili: per applicazione (rilascio monolitico) o per aspetto funzionale (approccio SOA).

Escludendo il caso più elementare dei servizi web classici, e cioè il super rilascio di un intero layer di web service in un unico progettone di tipo in genere web-application, approccio appunto monolitico, andiamo invece a fare un paragone con il design SOA. Qui ci troviamo a rilasciare i servizi per funzionalità di business. Ad esempio il WS (web service) della fatturazione, quello del magazzino, quello dei clienti che magari non è nostro ma è di un CRM esterno. A questi WS si aggiungono quelli ad uso e consumo dell’infrastruttura SOA stessa, e quindi servizi di aggregazione di altri, servizi di trasformazione di messaggi per magari rendere compatibili versioni diverse sello stesso WS o trasformazioni per necessità di integrazione. Poi ci sono i repository dei servizi disponibili con eventuali loro sistemi di messaggistica e trasformazione integrata che rientrano sotto la sigla degli ESB (enterprise service bus).

Da un punto di vista di progetto, questo design estremamente potente, soffre un po di integrabilità con altri mondi. Siamo nell’enterprise… in un mondo tipicamente interno, ad uso interno, chiuso, con protocolli e sistemi di autenticazione abbastanza omogenei perché abbiamo tantissimi utenti come una grossa WAN aziendale. Tipicamente nel SOA se si da accesso all’esterno in un ottica B2B (business to business) per magari ricevere gli ordini in diretta dai nostri partner, si creano degli ulteriori WS che hanno il compito di rendere accessibile dall’esterno l’infrastruttura di servizi interna, e questo prevede in genere una o due modalità di crittografia per discriminare non solo l’utente ma anche il Tenant (partner) con cui si dialoga all’esterno, trasformazioni di messaggi per parlare magari con standard pubblici o concordati fuori, e quant’altro (aggregazioni, transazioni, etc)

Nel mondo del microservices programming abbiamo invece un approccio più leggero in tutti i sensi, anche se la granularità finissima rende il tutto in teoria più verboso al momento iniziale della creazione. Andiamo quindi a creare dei WS non più orientati ad un approccio funzionale come per il SOA (il WS delle fatture), ma li andiamo a suddividere per operazione o gruppo omogeneo delle stesse, ad esempio il WS della creazione delle fatture, il WS della consultazione delle fatture, il WS della consultazione del magazzino, etc

Altro importante dettaglio è che si usa tipicamente un protocollo più leggero di comunicazione, anche perché i microservices sono pensati per essere accessibili da ovunque ed hostati in un ambiente di hosting dedicato, come ad esempio Docker, mentre nel SOA tipicamente risiedono in uno o più web-application. Usano in genere un sistema di crittografia standard ma semplice (https) mentre i WS in ambito SOA che girano in LAN o WAN corporate usano in genere Kerberos + TLS, mentre gli endpoint pubblici usano TLS+WS-Messaging con due diversi certificati X509 per discriminare il Tenant (partner) magari con la TLS e far girare poi comunque la normale crittografia per l’autenticazione username/password su WS-Messaging, o sicurezze similari.

In ogni caso, mai da un device come uno smartphone pubblico faremo una chiamata in SOAP+TLS+WS-Messaging…… mentre è facile fare una chiamata REST/HTTPS.

Le funzioni che possiamo scrivere in Azure Functions, e quindi più in generale le funzioni del FaaS (function as a service) sono invece una ulteriore derivazione del mondo microservices verso l’approccio DevOps. Con le Functions andiamo comunque a rilasciare operazioni, ma in questo caso l’operazione è proprio singola, una per una. E non andiamo più sempre a renderle disponibili in ottica WS, magari una funzione è solo di risposta ad una MQ (coda) ed un altra solo di risposta ad un Webhook, in ogni caso, abbiamo ridotto la granularità del rilascio al massimo, abbiamo travalicato il concetto di servizio (qualcosa che risponde a qualche richiesta o azione) perché possiamo eseguire funzioni come risposta ad un trigger o in loop continuo o schedulato, abbiamo travalicato la necessità di un developer, perchè in alcuni casi le Functions le possono scrivere anche i non programmatori (classici) come ad esempio i sistemisti (usando powershell) o i programmatori di script (javascript, bash, etc)

In definitiva, l’evoluzione ci porta a poter rilasciare e quindi testare sempre più piccole porzioni di codice. Questo ovviamente semplifica molto il lavoro in generale, aumenta la testabilità, aumenta la possibilità di lavorare in grandi team, ed aumenta la velocità di rilascio delle fix. Certo, virtualmente il lavoro di sviluppo per il team è maggiore ed il lavoro degli architect (se vogliono dare una impronta di omogeneità nel lavoro globale offerto da un’azienda) è anche essa maggiore, ma del resto si riduce fortemente il lavoro di fix ed in generale di release-management (gestione della produzione).

Presto pubblicherò un articolo completo sulle Azure Functions, così da poter toccare con mano l’API di programmazione di questo mondo di funzioni ormai già in GA