Se il nuovo gioco Pokémon Go potrà diventare un nuovo strumento di ingaggio per il mondo del retail o per la promozione dei beni culturali, solo il tempo potrà dirlo.
Di certo, c’è qualcosa che il nuovo gioco di Nintendo può imparare dal tradizionale mondo ICT.
Qualcosa che, probabilmente, non è stata presa in giusta considerazione in fase di progettazione: la gestione delle capacità prestazionali.
Un problema infrastrutturale?
In questi giorni, al di là della narrazione del fenomeno, con anedottiche al limite della follia umana, è emersa chiaramente l’inadeguatezza dell’infrastruttura sulla quale poggia il sistema.
Blackout, server indisponibili, impossibilità a creare persino nuovi account sono solo alcune delle frustrazioni che gli utenti hanno vissuto in queste ore.
Tanto da spingere Werner Vogels, CTO di Amazon che www.01net.it ha avuto modo di sentire in altre occasione, a pubblicare un Tweet, indirizzato agli sviluppatori del team Niantic Labs che ha sviluppato il gioco, offrendosi a supporto dei loro problemi di capacity, magari appoggiandosi a una infrastruttura cloud più consistente.
Lavorare sul Build to Scale
Tanto da spingere anche Lori MacVittie, evangelist di F5 Networks, a pubblicare una sua riflessione che vale la pena prendere in esame.
Secondo MacVittie, al di là che si tratti di un problema di server (qualunque cosa ciò significhi) o di un non adeguato ricorso al cloud, il vero vulnus mostrato in questi giorni da Pokémon Go è legato alla scalabilità.
Il “build to scale”, secondo la sua opinione, non è stato preso in giusta considerazione.
Pur riconoscendo che gli sviluppatori di fronte al problema hanno fatto un buon lavoro, affrontando i failure con messaggi amichevoli agli utenti, la criticità resta: “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”, scrive MacVittie, ricordando come siano stati i social media i primi a sperimentare sulla propria pelle i problemi di scalabilità del database erano enormi. La risposta fu l’adozione di tecniche di frammentazione, applicabili sia ai database sia ad altri servizi.
Pensare al bilanciamento di carico
A livello infrastrutturale, non è sufficiente pensare di risolvere il problema scalando automaticamente in cloud: bisogna sì aggiungere automaticamente più risorse di computing, ma bisogna anche aumentare la capacity dell’endpoint dell’applicazione.
A sua volta, questo porta con sé la necessità di implementare anche servizi di bilanciamento del carico, “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à”.
Da qui la conclusione: “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”.
