Come fare se si rende necessario passare ai microservizi laddove venga utilizzato il modello di sviluppo SOA (Service Oriented Architecture?) Gli sviluppatori SOA dovrebbero comprendere bene le differenze tra le due architetture in modo da rendere quanto più possibile indolore il cambio di passo.
Service Oriented Architecture e microservizi: che cosa sono
Le SOA hanno una doppia natura. A livello concettuale, la Service Oriented Architecture è un modello che consente di progettare applicazioni assemblando componenti che possono essere condivisi tra le applicazioni e ospitati in modo indipendente. A livello di implementazione, la SOA ha sviluppato una serie di standard che definiscono le caratteristiche e le interfacce dell’applicazione, l’accesso e la sicurezza del broker, tra cui sono inclusi il protocollo Simple Object Access e il linguaggio Web Services Description.
I microservizi sfruttano la componentizzazione delle applicazioni in applet più piccoli (detti appunto microservice), che possono essere distribuiti lungo una vasta gamma di risorse del data center come nei cloud pubblici o in quelli privati.
La prima differenza sostanziale è Internet
Tra le Service Oriented Architecture e le Microservice Architecture sussistono delle analogie in quanto molti dei concetti chiave della SOA sono anche concetti fondamentali nei microservizi. Tuttavia, i microservizi applicano questi concetti attraverso la mediazione di Internet, ovvero dell’universo web e delle interfacce REST.
Quasi tutti i team di sviluppo hanno familiarità con REST e le applicazioni di programmazione basate sul Web, quindi hanno già le conoscenze di base per far fronte allo sviluppo di microservizi. Il focus dell’implementazione deve solo spostarsi sul web, il che comporterà la necessità di imparare ad utilizzare delle nuove procedure.
Il termine microservizi può essere fonte di confusione per alcuni ex sviluppatori SOA, in quanto può evocare l’immagine di centinaia o migliaia di servizi che consistono in un paio di righe di codice, richiamate in base alla necessità. Una tale struttura di microservizi genererebbe quasi certamente enormi ritardi a causa della latenza del trasferimento dei messaggi. Gli ex professionisti delle Service Oriented Architecture dovrebbero tenere presente come i principi di progettazione della componentizzazione della SOA siano ugualmente efficaci per i microservizi.
Dove microservizi e architettura SOA differiscono
La differenza tra comportamento stateless e stateful è probabilmente il problema più complesso da comprendere per gli sviluppatori SOA. Una semplice regola è che non si dovrebbero mai archiviare dati all’interno di un microservizio. Questa pratica, infatti, limita la capacità di poter scalare un servizio sotto carico o di sostituire un servizio fallato. Se è necessario mantenere i dati o il contesto su più istanze in un’architettura di microservizi, è possibile archiviare i dati e inviarli al microservizio quando questo viene chiamato, oppure ottenerli da un database di back-end. La progettazione di un microservizio presuppone che nel chiamarli con lo stesso input si genererà sempre lo stesso output.
C’è anche una differenza fondamentale nel modo in cui i servizi SOA e i microservizi vengono utilizzati da un’applicazione. I servizi SOA vengono in genere visualizzati come procedure o funzioni, nel senso che sono progettati per emulare componenti software scritti localmente. Ad esempio, quando è necessario un servizio SOA, basta richiamarlo. Al contrario, i microservizi non vengono chiamati ma sono una risorsa da cui attingere. Quando vengono utilizzati nell’elaborazione di eventi, ad esempio, vengono attivati da un evento piuttosto che chiamati esplicitamente. I microservizi , infine, sono in genere senza stato, mentre la maggior parte dei componenti SOA sono con stato.
Anche la risoluzione dei problemi di sicurezza e di governance nei microservizi è più sfumata. Molte organizzazioni hanno sviluppato metodi standardizzati per la sicurezza, la gestione delle identità e la governance della SOA. Tuttavia, la maggior parte delle aziende non ha metodi standardizzati per affrontare i problemi di sicurezza e governance nei microservizi. Gli architetti che migrano alle microservice architecture devono escogitare dei metodi utili a rispondere a queste esigenze, assicurandosi che siano standardizzati rispetto all’intero ecosistema IT. In caso contrario, le differenze che sussistono nelle procedure di sicurezza e nella gestione degli accessi e delle identità bloccano la distribuzione. Significa anche che quando vengono identificate opportunità per nuove applicazioni, si rischia di scoprire incompatibilità nascoste. Per fortuna, esistono molti sistemi basati su token comprovati per la gestione delle identità e la sicurezza dei microservizi che aiuta a non compromettere la sicurezza e la governance.
Se il cloud è il futuro, lo sono anche i microservizi
Un’altra area in cui i microservizi e le SOA differiscono è l’organizzazione dei flussi di lavoro. Le applicazioni SOA sono spesso collegate a un Enterprise Service Bus (ESB), in cui l’esecuzione è guidata dal linguaggio BPM (Business Process Management). I microservizi vengono chiamati esplicitamente dalle applicazioni, quindi il sequenziamento delle fasi del processo viene eseguito a livello applicativo. Un’altra cosa importante da tenere a ente è che i microservizi sono tutti componenti riutilizzabili. Non sono righe di codice consisistenti come possono essere quelle supportate dai linguaggi ESB e BPM. Tuttavia, ci sono modelli di progettazione che forniscono un processo di orchestrazione simile utilizzando i microservizi.
Le interfacce di qualsiasi tipo richiedono una sorta di meccanismo di scambio di dati. Con le Service Oriented Architecture, il meccanismo tradizionale è l’XML che, pur essendo flessibile, alcuni sviluppatori trovano troppo dettagliato e complicato. Con i microservizi, è possibile continuare a utilizzare l’XML, anche se molti sviluppatori gravitano verso JSON perché lo trovano più facile. Se un team ha maggiore familiarità con l’XML rispetto a Java, è possibile continuare a usare l’XML. Come fanno notare gli esperti, JSON è comunque la scelta migliore nella maggior parte dei casi. Il cambio di passo non dovrebbe essere difficile per la maggior parte dei programmatori SOA.
Perché passare dalle Service Oriented Architecture ai microservizi
L’unica domanda che rimane è se gli sviluppatori SOA debbano davvero adottare la componentizzazione e i microservizi. Lo sviluppo della SOA è ancora in corso e molte applicazioni importanti e di rilievo si basano ancora su questo approccio sia dal punto di vista concettuale che dell’implementazione.
È vero però che il cloud sta favorendo una visione dinamica e resiliente dei componenti applicativi. Questo significa che la scalabilità e la resilienza sono più preziose della sola componibilità. I modelli cloud si sposano meglio con componenti leggeri, in grado di essere modellati in maniera agile fin dalla fase di esecuzione.
Insomma: se il cloud è il futuro, lo sono anche i microservizi. La SOA non scomparirà, ma è anche improbabile che sia capace di adattarsi a questi nuovi requisiti. Le pratiche software si stanno spostando verso i microservizi, quindi i professionisti delle Service Oriented Architecture dovrebbero prepararsi per tempo.
