Robustezza e resilienza: imperativi strategici per proteggere e far crescere il business

Avere un parco applicativo che rispetta i requisiti di robustezza e resilienza è una questione strategica cruciale, legata alla protezione e alla crescita del business. Quando parliamo di robustezza e resilienza, facciamo riferimento a due aspetti distinti che influenzano la capacità di un sistema di affrontare problemi e garantire un funzionamento affidabile nel tempo.  

• La robustezza si riferisce alla capacità di un’applicazione di funzionare correttamente anche in presenza di condizioni anomale o imprevisti interni al sistema stesso. È un fattore interno perché riguarda come il sistema è progettato e implementato: è legata alla qualità del codice, alla gestione delle eccezioni e alla capacità del sistema di autolimitare i danni derivanti da malfunzionamenti interni. In sintesi, possiamo dire che un’applicazione robusta è “forte dentro”: quindi riesce a gestire errori interni (come bug, accessi non validi alla memoria), a resistere a malfunzionamenti (ad es. fallimenti parziali di alcune componenti software) e a comportarsi in modo prevedibile in presenza di condizioni di input anomale.

• La resilienza invece si riferisce alla capacità dell’applicazione di riprendersi da eventi esterni avversi e di continuare a funzionare in modo accettabile, ripristinando le funzionalità e riducendo al minimo il down-time. Gli eventi esterni possono essere di vario tipo: guasti hardware (interruzione di corrente, server che si spengono improvvisamente), problemi di rete, attacchi informatici, overload di richieste ma anche imprevisti non prevedibili come disastri naturali o condizioni operative avverse. La resilienza è un fattore esterno, in quanto dipende dall’interazione del sistema con l’ambiente circostante. In sintesi, possiamo dire che un sistema applicativo resiliente non si limita a evitare guasti, ma è in grado di “ritornare indietro” e recuperare uno stato funzionante anche dopo che si è verificato un evento critico.  

   

Ignorare questi aspetti crea un rischio tecnologico, ma soprattutto aziendale 

Un parco applicativo che non rispetta i requisiti di robustezza e resilienza crea un ambiente fragile, in cui anche i piccoli guasti e imprevisti possono avere effetti a catena devastanti per il business. I motivi per cui si viene a creare questa situazione possono essere molteplici:  

• il fatto che nel proprio ambiente IT ci siano applicazioni datate (e quindi non progettate per gestire le esigenze moderne in termini di scalabilità, sicurezza, affidabilità) e che sia difficile garantire la loro manutenzione e il loro aggiornamento. Questo aspetto è legato a stretto giro con il budget e le risorse tecniche disponibili: spesso ci sono vincoli di tempi, costi e risorse che non permettono di imbarcarsi in progetti di rinnovo delle applicazioni 

• il fatto che le applicazioni rientrino in architetture e integrazioni complesse: l’interdipendenza dei componenti, se non gestita correttamente, crea un effetto a catena che può danneggiare l’intero ecosistema. Un approccio tradizionale, diciamo monolitico, rende più difficile isolare i problemi e scalare i singoli moduli. Questo rischio si riduce con le moderne architetture a microservizi, che permettono di suddividere le applicazioni in componenti più piccoli, indipendenti e facilmente mantenibili.

Il rischio tecnologico può diventare un rischio per l’intera azienda fino a: 

• danneggiare i flussi di entrate: interruzioni o problemi possono ridurre la capacità dell’azienda di generare reddito 

• danneggiare la reputazione aziendale: se l’azienda non viene percepita da clienti e partner come affidabile e in grado di fornire servizi continui senza intoppi c’è un danno reputazionale 

• bloccare l’operatività aziendale fino a compromettere la produzione stessa

In un contesto in cui le applicazioni devono essere sempre più affidabili e disponibili, l’IT deve essere in grado di fornire al business garanzie sul fatto che le applicazioni rimangano operative in ogni circostanza e che possano riprendersi rapidamente quando si verifica un guasto.  

Come possiamo evitare che i sistemi crollino come castelli di carta

Molte organizzazioni stanno guardando al low-code come a una soluzione per garantire resilienza e robustezza: tempi di sviluppo e iterazione più rapidi (quindi anche più possibilità di fare test), utilizzo di blocchi predefiniti e già predisposti di meccanismi integrati di monitoraggio e gestione delle eccezioni, possibilità di gestire in modo centralizzato e automatizzato gli aggiornamenti per i componenti utilizzati, visto che il codice sottostante è gestito dalla piattaforma low-code stessa.  

Quest’ultimo punto, il fatto che le applicazioni possano continuare a funzionare senza interruzioni anche dopo un aggiornamento, è un aspetto fondamentale al giorno d’oggi. Ricordiamo il caso Crowdstrike, dove un aggiornamento difettoso ha causato un’interruzione globale: questo sottolinea quanto sia cruciale avere un sistema di aggiornamenti che possa garantire la continuità operativa anche durante i processi di patching o update.