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 , and garantire un funzionamento affidabile nel tempo.  

• The 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.

• The 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 

A 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 and who 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.