Il middleware, sia come termine che come concetto, esiste da decenni. Come altri termini del mondo IT ha seguito il tipico ciclo di vita e oggi risulta forse un po’ datato. Come concetto, invece, è più attuale che mai, e anche se una nuova etichetta non ha ancora sostituito il termine tradizionale, le sue potenzialità sono ancora al centro dell’enterprise application development.
Il middleware rende sviluppatori e operatori molto più produttivi. Analogamente ai comprovati e diffusi processi di pre-assemblaggio nella produzione di beni come le auto, il middleware solleva gli sviluppatori dal dover ‘scoprire l’acqua calda’, permettendo loro di comporre e innovare a livelli di astrazione più elevati. Per i responsabili che devono gestire le applicazioni in produzione, su larga scala, assicurando affidabilità e performance, più tali applicazioni si avvalgono di componenti e servizi middleware standard, più efficiente e attendibile sarà l’operatività dell’applicazione.
E questo vale sia per le applicazioni cloud-native, sia per quelle tradizionali che girano direttamente su hardware fisico o virtuale. Una caratteristica degli ambienti cloud-native è l’uso di container come unità standard di deployment. E grazie alla rapida adozione di tecnologie come Kubernetes e Docker i container hanno causato un significativo balzo in avanti rispetto alla tradizionale virtualizzazione dei server in termini di utilizzo hardware, scaling elastico, e standardizzazione dei processi.
Il container è importante anche per lo sviluppatore e, in ultima istanza, per il business. Uno dei vantaggi offerti dai container rispetto alla server virtualization è che i primi sono molto più leggeri. Ogni istanza container dispone del livello minimo di codice per operare i workload, mentre un server virtuale include un’istanza di sistema operativo completa. Per via della loro leggerezza, un application architect può modulare una maggiore granularità, con ogni modulo nel proprio container. Un mondo di server virtuali non avrebbe senso decomporre un’applicazione in un elevato numero di moduli molto piccoli, ognuno nel suo virtual server—l’overhead legato alla ridondanza delle istanze di sistema operativo sarebbe troppo elevato. Con i container questo approccio invece è valido e offre molti vantaggi, viene denominato microservizi.
Perché tutto questo dovrebbe interessare a chi si occupa di business? Un’applicazione architettata sotto forma di microservizi può subire modifiche minime, riducendo al massimo il rischio e il cambiamento dell’applicazione nel suo complesso. Questo permette al business leader di innovare a piccoli, ma rapidi passi senza rischi, collaborando con il team di sviluppatori responsabile dell’implementazione di queste innovazioni nel software che si traducono poi in vantaggi di business.
Il che ci porta al circolo virtuoso che caratterizza le aziende moderne: quasi tutte le imprese dipendono in modo significativo dal software e, per competere in modo più efficace, devono innovare più velocemente, in modalità trial-and-error piuttosto che attraverso una pianificazione massima. Questa è la digital transformation.
Ecco quindi il percorso logico: la trasformazione digitale abilita e dipende da una rapida innovazione; quest’ultima dipende dalla capacità di cambiare velocemente in piccoli passi; questi miglioramenti incrementali sono resi possibili da un’architettura di microservizi granulari e i container sono l’abilitatore chiave di questi microservizi.
Torniamo adesso al middleware. Abbiamo detto che sviluppatori sono più efficaci e innovativi se possono pensare e progettare con componenti standard e che supportare la business innovation significa abilitare piccolo cambiamenti incrementali con un’architettura granulare di microservizi containerizzati. Ne segue che il middleware dovrebbe abilitare questo nuovo approccio basato sui microservizi, il che significa– come punto di partenza – che il middleware è lui stesso containerizzato e cloud-native.
A cura di Mike Piech, vice president and general manager Middleware, Red Hat
