Rappel du lancement de Pokémon Go : pourquoi « Build to Scale » est aussi important que « Build to Fail »
L’un des slogans de DevOps et du cloud depuis de nombreuses années est « construire pour échouer ». Le principe étant que trop d’entreprises subissent des temps d’arrêt coûteux et des pertes de revenus (et de productivité) en raison de problèmes de performances liés à la capacité, vous devez donc concevoir votre application et votre infrastructure « pour qu’elles échouent » afin de garantir que de tels événements horribles ne reviennent pas vous hanter. Héhé. Tu vois ce que j'ai fait là ? Oui, je travaille à distance dans un bureau, seul. Parfois, je dois m'amuser.
Mis à part les mauvais jeux de mots, le récent succès phénoménal de Pokémon Go (vous en avez entendu parler, n'est-ce pas ?) a donné lieu à une expérience qui a également été extrêmement frustrante pour beaucoup. Surtout les parents avec des enfants hyper excités qui voulaient y aller, MAINTENANT, mais n'ont pas pu parce que la création de compte a été temporairement suspendue, puis strictement limitée en raison d'une demande écrasante.
Certains pourraient maintenant pointer du doigt l'offre du CTO d'Amazon, Werner Vogels, d'aider l'entreprise à gérer ses problèmes de capacité, comme s'il s'agissait du fait qu'ils n'étaient pas « passés au cloud » en premier lieu et que c'était là le problème sous-jacent, mais cela suppose qu'ils ne l'avaient pas fait, ce qui n'est pas tout à fait clair pour moi à ce stade. Sérieusement, selon les mises à jour de Wikipédia sur le développeur de réalité augmentée, il traite « plus de 200 millions d’actions de jeu par jour pendant que les gens interagissent avec des objets réels et virtuels dans le monde physique ». Je pense que nous pouvons leur donner un peu de répit sur celui-ci, ou du moins ceux d'entre nous qui comprennent ce que cela signifie en termes d'interactions système et d'envoi de paquets le peuvent. Les mises à jour ont fait état de « problèmes de serveur », mais bon, nous savons tous que « serveur » est le code technique pour « 15 composants différents répartis sur l’application et l’infrastructure réseau ».
Quoi qu’il en soit, la leçon sous-jacente ici n’est pas que le cloud soit nécessairement plus efficace pour gérer les succès inattendus. C'est peut-être vrai, mais pas parce que c'est un nuage. C’est parce que le cloud n’est pas seulement conçu pour échouer , mais il est également conçu pour évoluer .
Je ne suis pas en mesure de déterminer pourquoi Niantic Labs n’a pas été en mesure de répondre à la demande. Peut-être s’agissait-il d’un manque de capacité, auquel cas le cloud aurait été un bon choix, ou peut-être s’agissait-il du fait que les applications et/ou l’infrastructure n’étaient pas conçues pour évoluer, auquel cas le cloud n’aurait peut-être pas été d’une grande aide. Le but n’est pas vraiment de les taquiner (heh) pour ce qu’ils ont fait ou n’ont pas fait. Le fait est qu’ils sont un parfait exemple de la réalité selon laquelle, dans un monde d’application, les organisations devraient être aussi préoccupées par la préparation à l’échec que par la préparation au succès. Et pas seulement un succès progressif, mais un succès instantané, du jour au lendemain, comme dans Pokémon Go.
Parce que si cela arrive, vous ne voudriez pas que cet échec soit affiché sur Internet.
Les sources de données sont une source courante de problèmes d’évolutivité. Les utilisateurs chevronnés de Twitter se souviendront que les débuts des médias sociaux ont été confrontés à des problèmes d'évolutivité des bases de données. PayPal a été l'un des premiers et des plus fervents partisans du sharding comme stratégie de mise à l'échelle pour faire face au défi posé par l'échelle massive des utilisateurs, et la technique a été adoptée comme une technique générale, applicable aux bases de données, aux services de performance et aux applications . L’essor des sources de données NoSQL présente comme l’un de ses avantages une plus grande évolutivité que les bases de données relationnelles traditionnelles.
Une autre source de problèmes d’évolutivité repose uniquement sur l’infrastructure. La mise à l’échelle automatique dans le cloud repose sur la capacité non seulement d’ajouter automatiquement plus de puissance de calcul, mais également d’augmenter la capacité du « point de terminaison de l’application ». Dans toute architecture s’appuyant sur l’évolutivité pour obtenir une augmentation de capacité, cela implique un service d’équilibrage de charge d’une certaine sorte. Lorsque la capacité de calcul augmente, elle doit être enregistrée auprès du service d'équilibrage de charge. Cela signifie l’utilisation d’API et de scripts, l’automatisation et l’orchestration. Ces composants doivent être en place avant d’être nécessaires, sinon il y aura des retards si la demande nécessite une augmentation de capacité.
L’inclusion d’un service d’équilibrage de charge dans toute architecture d’application devrait être une exigence. Non seulement un service d'équilibrage de charge répond au besoin de « construire pour échouer » en raison de sa prise en charge inhérente du basculement entre deux instances d'application, mais il prend également en charge le besoin de « construire pour évoluer » nécessaire au succès. Mais ne pensez pas qu’il s’agit simplement de placer un service d’équilibrage de charge devant une application (ou un microservice, si c’est votre truc). Il est important pour les opérations de mettre en place l'automatisation (scripts) et l'orchestration (processus) qui permettront une mise à l'échelle automatique pour répondre à cette demande lorsqu'elle se présentera. Aujourd'hui, la mise à l'échelle est une question d'architecture, pas d'algorithmes , et il est important de considérer cette architecture en amont, avant que la dette architecturale ne soit si restrictive que vous soyez coincé avec ce que vous avez.
Honnêtement, Niantic Labs a fait du bon travail en construisant pour l'échec. Les échecs de capacité ont été rencontrés avec des messages conviviaux plutôt qu'avec les pages de codes d'état HTTP par défaut que je rencontre souvent. Ils étaient humoristiques et faciles à lire et à comprendre pour les enfants (je le sais, car mon enfant de 8 ans nous le lisait toutes les 20 minutes). Ce à quoi ils ne s’attendaient pas, c’était le succès peut-être inattendu qu’ils ont rencontré. C'est un bon rappel pour tout le monde que construire à grande échelle est tout aussi important que construire pour échouer.
Parce que lorsque vous ne le faites pas, la Team Rocket gagne.