Lori MacVittie, Evangelist di F5 ha analizzato il fenomeno Pokèmon GO sottolineando l’importanza della scalabilità nello sviluppo delle nuove app
Uno degli slogan che da tanti anni circola nel mondo dei DevOps e del cloud è “progettare pensando di poter fallire”. La premessa era che troppe aziende, a causa di problemi legati alle capacità prestazionali, erano costrette ad affrontare lunghi tempi di inattività con una conseguente riduzione delle entrate (e della produttività), quindi l’applicazione e l’infrastruttura dovevano essere progettate per poter ‘fallire’ in modo da garantire che il verificarsi di eventi di questo tipo non si ripercuotesse sullo sviluppatore.
Il recente successo di Pokémon GO per molti si è tradotto in un’esperienza frustrante. Specialmente per i genitori di bambini ipereccitati e per i super fan storici che volevano giocare subito con l’app ma non hanno potuto perché la creazione dell’account era temporaneamente sospesa e poi rigorosamente limitata a causa della domanda massiccia.
L’app Pokémon Go è stata così protagonista di un vero e proprio down. Milioni di utenti in tutto il mondo non hanno potuto accedere al gioco del momento per svariate ore, indicativamente dalle 15 del pomeriggio del 16 luglio fino a notte fonda.
Che cosa è successo effettivamente?
Forse il team Niantic Labs che ha progettato l’app dovrebbe accettare la proposta del CTO di Amazon, Werner Vogels, che si è offerto di aiutarli ad affrontare i problemi di capacity sottintendendo implicitamente che la loro strategia non avrebbe considerato adeguatamente “lo spostamento verso il cloud” e che questa fosse la vera origine del problema.
Scherzi a parte, se cerchiamo su Wikipedia il significato dello sviluppo della realtà aumentata, troveremo scritto che “implica l’elaborazione di oltre 200 milioni di azioni di gioco al giorno, perché le persone interagiscono con oggetti reali e virtuali nel mondo fisico.” Penso che chi capisce cosa tutto questo comporti in termini di interazioni di sistema e pacchetti da spingere sia disposto a concedere un’attenuante agli sviluppatori.
Nei momenti di mancanza di disponibilità, gli aggiornamenti di Pokémon GO indicavano “problemi di server”, ma sappiamo tutti che, in questo caso, “server” è un termine tecnico per indicare ” 15 diverse componenti, dall’applicazione all’infrastruttura di rete” che possono essere andate storte!
In ogni caso, non è detto che il cloud sia necessariamente la risposta giusta quando si ha a che fare con un successo inaspettato. Può esserlo, ma solo perché il cloud spesso non è solo progettato per poter fallire, ma è anche costruito in scala.
Non sono in grado di determinare il motivo per cui i Niantic Labs non sono riusciti a tenere il passo con la domanda. Forse si è trattato di una capacità insufficiente, in quel caso il cloud sarebbe stato una buona scelta, o forse le applicazioni e / o le infrastrutture non sono state progettate in scala, e in quel caso il cloud non sarebbe stato un aiuto sufficiente.
Il punto non è davvero scoprire dove si nasconde l’errore come se fosse un Pokémon da trovare. Il punto è che questo rappresenta un esempio perfetto di quello che avviene nel mondo applicativo: nel progettare, le organizzazioni dovrebbero tenere conto della possibilità di fallire allo stesso modo con cui pensano al successo e la chiave è la scalabilità. Il successo non è graduale, può essere immediato, avvenire nel corso di una singola notte come nel caso di Pokémon GO. Se questo accade, di certo non si desidera che venga ostacolato da un fallimento su Internet.
Una causa comune nei problemi di scalabilità sono le fonti dei dati. Gli utenti di Twitter più avanti con gli anni ricorderanno che nei primi giorni del social media i problemi di scalabilità del database erano enormi. PayPal è stato uno dei primi e maggiori sostenitori della “frammentazione”” come una strategia di scala per affrontare la sfida della massima scalabilità rispetto agli utenti, e questa tecnica è-stata adottata come generale, applicabile ai database, ai servizi prestazionali e a quelli simili alle applicazioni. L’aumento di fonti di dati NoSQL ha presentato maggiori vantaggi in termini di scalabilità rispetto ai tradizionali database relazionali.
Un’altra causa di problemi di scalabilità è interamente imputabile alle infrastrutture. Scalare automaticamente nel cloud non solo dipende dalla capacità di aggiungere più risorse di computing in modo automatico, ma anche dall’aumentare la capacity dell’endpoint dell’applicazione. In ogni architettura che si basa sulla scalabilità per aumentare le capacità quest’aspetto comporta dei servizi di bilanciamento del carico. Il computing, quando aumenta, deve essere registrato con il servizio di bilanciamento del carico; questo comporta l’utilizzo di API e script, automazione e orchestrazione; componenti che devono essere in pista ancora prima di diventare necessarie, o ci saranno dei ritardi nel momento in cui viene richiesto un aumento della capacità.
L’inclusione di un servizio di bilanciamento del carico in ogni singola architettura applicativa dovrebbe essere un prerequisito. Non solo un servizio di bilanciamento del carico pensato con la necessità di “progettare per fallire” grazie al supporto intrinseco per il failover tra le istanze di due applicazioni, ma anche per la necessità di “costruire in scala”, indispensabile per il successo. Ma non pensate che si tratti semplicemente di piazzare un servizio di bilanciamento del carico di fronte a un’applicazione (o micro-servizio, se vi piace il genere). Per le operation è importante mettere in atto da subito l’automazione (script) e l’orchestrazione (processo) che permetterà una scalabilità automatica per soddisfare la domanda quando si presenterà.
Scalare oggi ha a che fare con l’architettura, non con gli algoritmi ed è importante considerare quest’architettura in anticipo, prima che un debito architetturale sia così vincolante da venire ostacolati.
Onestamente, i Niantic Labs hanno fatto un buon lavoro davanti alla mancanza di disponibilità: i failure sono stati affrontati con messaggi amichevoli agli utenti, piuttosto che visualizzando una pagina di codice di stato HTTP predefinita, cosa che ancora spesso ci capita.
I messaggi erano divertenti e facili da capire anche per i bambini (lo so, perché mio figlio di otto anni ce li leggeva ogni 20 minuti). Quello che non avevano previsto era un successo così rapido, e questo è un buon esempio per tutto il mondo dello sviluppo applicativo: il “build to scale” è importante quanto il “build to fail”, perché se non si procede così alla fine vincerà il Team Rocket!
