MACH è il futuro dell'architettura IT? Ecco perché microservizi, API-first, SaaS cloud-native e headless sono i principi architetturali IT da adottare.
Una breve panoramica del movimento MACH: vantaggi principali e probabile impatto futuro sui CTO
Nell'ultimo decennio le aspettative sull'ingegneria del software sono cambiate radicalmente, grazie al movimento DevOps e all'affermarsi delle tecnologie cloud e dei loro provider, ormai onnipresenti. Il passaggio su larga scala al lavoro da remoto ha reso ancora più urgente ridurre le dipendenze tra Engineers, da sempre la causa principale dei ritardi nei progetti software.
Secondo un nuovo studio, i leader tecnologici considerano MACH (microservices-based, API-first, cloud-native SaaS e headless) il "futuro dell'architettura": l'80% prevede di aumentare gli investimenti in questa direzione nel prossimo anno e oltre. Vediamo i vantaggi dei principi architetturali IT alla base di microservizi, API-first, SaaS cloud-native e headless.
Microservizi
L'architettura a microservizi parte dal presupposto che più componenti software di piccole dimensioni possano produrre lo stesso valore di un unico, grande software monolitico. Ma il vero vantaggio del passaggio ai microservizi è il disaccoppiamento del lavoro di engineering: ogni Engineer può concentrarsi sul proprio piccolo componente, invece di dedicare enormi quantità di tempo a coordinarsi su un unico grande progetto.
DoiT International è un'azienda totalmente remota: suddividere i progetti software più grandi in parti più piccole, affidabili a team con un coordinamento minimo, porta vantaggi evidenti. Non è un'impresa semplice, ma con l'aspettativa di rilasciare valore software più velocemente che mai non esistono alternative.
API-first
L'architettura software API-first è praticamente obbligatoria quando si passa ai microservizi. Anche in questo caso permette a team di Engineers, anche piccolissimi, di realizzare componenti software che si incastrano tra loro per formare un insieme più ampio, consentendo ai colleghi di utilizzare il lavoro altrui in modalità disaccoppiata. Per chi non si occupa di sviluppo software, si può spiegare con l'analogia del tubo: il motore di un'auto ha un foro in cui deve arrivare il carburante e non importa di che tipo sia il serbatoio, purché il diametro del tubo tra serbatoio e motore combaci con entrambi. È un modo semplice per spiegare le API: il serbatoio è prodotto da una fabbrica, il motore da un'altra, e l'unico coordinamento richiesto è documentare il diametro del tubo.
Software-as-a-Service cloud-native
Il Software-as-a-Service (SaaS) cloud-native è un altro pilastro fondamentale del nuovo mondo dell'ingegneria del software completamente da remoto. Il passaggio all'engineering remoto ha costretto le aziende a ripensare i data center "a gabbia chiusa", accessibili solo dall'ufficio, per permettere agli Engineers di lavorare da qualunque luogo. Superata questa soglia, sempre più aziende che sviluppano software hanno capito di non aver più bisogno di gestire i propri data center e di potersi affidare a un cloud provider per la manutenzione dell'infrastruttura fisica.
Allo stesso modo, una fabbrica non ha bisogno di produrre la propria elettricità e di norma la acquista da una società elettrica. L'accelerazione verso il cloud ha permesso ai cloud provider di assumere più persone e di realizzare più servizi in tempi brevissimi. E poiché oggi sempre più tecnologie IT hanno una versione -as-a-service nel cloud, gli Engineers possono sperimentarle in modo molto più rapido ed economico rispetto al passato.
Un tempo, un Engineer che voleva provare un nuovo database doveva chiedere a una persona di acquistare l'hardware, a un'altra di installarlo nel data center e a un'altra ancora di installare sistema operativo e database. Solo dopo aver ricevuto le istruzioni di accesso poteva finalmente mettere alla prova il nuovo database. Oggi basta un clic. Il cloud si è evoluto dalla fornitura di infrastruttura alla fornitura di qualsiasi tecnologia con un clic, offrendo una flessibilità sempre maggiore nella scelta degli strumenti più adatti ai requisiti di engineering.
Headless
L'approccio headless si sposa alla perfezione con microservizi e API-first. Molte proposte software moderne sono "multi-head" proprio grazie ai backend API-first. Mentre la logica di business più complessa può girare nel cloud, i dati che consuma o genera sono disponibili tramite API. Questo permette a team di Engineers disaccoppiati di creare esperienze per il web, il mobile o il desktop in modo indipendente, con un coordinamento minimo tra team frontend e backend.
L'ampia disponibilità di offerte SaaS cloud-native, o "technologies-as-a-service", permette di arricchire queste esperienze frontend con tecnologie pronte all'uso gestite dai cloud provider.
Il futuro di MACH
DoiT è un'azienda cloud-first e completamente da remoto. Tutta la nostra infrastruttura è nel cloud e l'unica infrastruttura fisica che possediamo sono i laptop con cui i nostri Engineers sfruttano le tecnologie cloud per realizzare piccoli componenti software che si integrano nel grande prodotto aziendale.
Diversi anni fa, quando il nostro prodotto era molto più piccolo, ci appoggiavamo fortemente alle tecnologie SaaS dei cloud provider, che ci permettevano di offrire un valore enorme ai clienti con un team di Engineers ridottissimo e in tempi brevissimi. Con la crescita dell'azienda e del team di engineering, è diventato logico realizzare nuovi servizi come piccoli microservizi integrati nel prodotto più ampio, invece di fondere tutto in un unico, enorme groviglio monolitico.
Mentre continuiamo a costruire esperienze sempre più preziose per i nostri clienti, ha senso puntare ancora di più su MACH e ricordare costantemente agli Engineers perché è così cruciale per il nostro business. Ci sarà sempre qualcuno che proporrà di fare uno o due passi indietro, adottando l'ennesima tecnologia da gestire internamente o creando l'ennesimo servizio con forte accoppiamento tra frontend e backend e privo di API. Sono mosse che possono solo rallentarci: preferiamo mantenere le release piccole, frequenti e ricche di valore, evitando di impantanarci in idee e concetti non-MACH.
Al momento la nostra azienda non fa parte della MACH Alliance, ma ne accogliamo positivamente l'iniziativa. Rendere questi concetti più diffusi e accettati nel settore non può che portare a un'esperienza software molto migliore per tutti.