La resilienza(reliability) delle infrastrutture IT è un requisito indispensabile e necessario per le applicazioni business critical. Con gli attacchi cyber, con variabili che non possiamo controllare totalmente come l’eventuale picco ed aumento della domanda dei servizi( non solo per classici attacchi DDoS ma anche per campagne di successo), costruire la resilienza della nostra infrastruttura è un must have.
Cosa vuol dire reliability
La reliability si ottiene quando si completano gli obiettivi di disponibilità e di resistenza ai fallimenti dell’applicazione. La disponibilità sembra un concetto semplice in quanto fa riferimento alla possibiità di utilizzare l’applicazione; pertanto una disponiblità del 99,99% vuol dire che su 24 ore l’applicazione non è disponibile per un massimo di circa 9 secondi.
La realtà è molto diversa, perchè come ci insegnava ITIL, la libreria di IT Service Management, più di 10 anni fa, la disponibilità è legata non in senso generale al fatto che riusciamo a raggiungere per esempio il link di un’applicazione ma che siano disponibili le sue funzionalità. Un’applicazione è concretamente disponibile, per esempio, quando:
- riesce a rispondere a tutte le richieste di contenuti. Se alcune di queste falliscono la disponibilità diminuisce;
- i database dispongono di dati coerenti, corretti e completi e li servono nei corretti tempi senza latenze che rendono inutilizzabile la loro funzionalità;
- i dati di un processo di analisi sono aggiornati nel tempo che ci aspettiamo, dati “vecchi” rendono indisponibile l’applicazione.
In buona sostanza la disponibilità fa anche riferimento all’utilizzabilità dell’applicazione: se alcune delle funzioni applicative non sono disponibili anche per gravi problemi di performance, allora la disponibilità nel suo senso generale degrada.
Mentre la resistenza ai fallimenti vuol dire che se qualcosa va storto( un server va giù, c’è un grave problema elettrico, accade una qualsiasi tipologia di disastro) l’applicazione continua a funzionare. Costruire la resistenza è un aspetto complicatissimo ed aziende come Netflix hanno creato progetti come Chaos Monkey proprio per testare la propria resilienza applicativa. Seguendo la stessa traccia sono nati processi come il Site Reliability Engineering(SRE) ed hanno preso sempre più campo attività per realizzare il Disaster Recovery(DR).
I 5 fattori principali che impattono sulla reliability
Ottenere la resilienza applicativa pertanto è un aspetto complesso da raggiungere ma possibile se progetti la tua applicazione tenendo in debita considerazione questi 5 fattori:
- Design dell’architettura e dell’applicazione: la progettazione di un’applicazione business critical è essa stessa un progetto, occorre definire un’archiettura che sia resistente ,magari distribuita geograficamente e con meccanismi di High Availability(HA) e Load Balancing e ridistribuzione dei workload in caso di disastri. Anche la progettazione interna deve evitare Single Point of Failure e prevedere scalabilità applicativa e backup.
- Componenti applicative esterne: una tematica a parte ed estremamente rilevante è quella di tutte le componenti esterne che tipicamente un’applicazione moderna utilizza, ebbene lock-in e vincoli applicativi (per es. per librerie servite in real-time) devono essere evitati e valutati. Un esempio è quello dei bonus governativi che utilizzano SPID, se quest’ultimo fornito da provider esterni non funziona correttamente ( fatto realmente accaduto nel 2020 “Il bonus bici manda in tilt anche Spid di Poste“) allora anche il portale ministeriale non funziona.
- Risorse IT: è chiaramente impensabile costruire la resilienza senza le necessarie risorse computazionali(es. potenza di calcolo), di networking(es. banda), di storage( es. archiviazione di file), database( es. archiviazione di dati) e sicurezza( es. Web Application Firewall).
- Scalabilità delle risorse IT: oltre ad avere a disposizione le necessarie risorse IT le stesse devono essere scalabili, vale a dire che si devono adattare alla domanda ed al numero delle richieste ricevute in modo da evitare crolli e down applicativi.
- Processi di DevOps: le applicazioni cambiano e vanno aggiornate in maniera repentina e continua spessissimo per i più vari motivi, come anche il semplice aggiornamento di una libreria critica. Per questo devono essere messi in campo processi di building, deployment e maintain efficienti e sicuri.
Glue Labs e la Reliability
Grazie alla partnership con Google e Vonage, all’esperienza maturata in tantissimi settori, con numerosi Clienti e con un solido gruppo aziendale ti supportiamo nella costruzione della reliability delle tue applicazioni business critical. Contattaci subito e senza impegno per diventare resiliente a disastri ed attacchi cyber.
