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 représentent souvent un point critique pour l’évolutivité. Les utilisateurs avertis de Twitter se rappellent que les débuts de ce réseau social ont été marqués par des difficultés à faire évoluer les bases de données. PayPal a été parmi les premiers à promouvoir activement le sharding comme stratégie pour gérer le défi que représente l’échelle massive d’utilisateurs, une technique désormais utilisée de manière générale, tant pour les bases de données, les services de performance que les applications. L’essor des sources NoSQL s’explique en partie par leur meilleure capacité d’évolutivité par rapport aux bases de données relationnelles classiques.
Une autre source de problèmes d’évolutivité repose uniquement sur l’infrastructure. L’auto-mise à l’échelle dans le cloud nécessite non seulement d’ajouter automatiquement plus de capacité de calcul, mais aussi d’augmenter la capacité du « point de terminaison applicatif ». Dans toute architecture qui s’appuie sur la montée en charge pour augmenter sa capacité, un service d’équilibrage de charge est indispensable. Lorsque vous augmentez la capacité de calcul, vous devez l’enregistrer auprès du service d’équilibrage de charge. Cela implique l’utilisation d’API, de scripts, d’automatisation et d’orchestration. Vous devez mettre en place ces composants avant d’en avoir besoin, sinon des retards surviendront lorsque la demande exigera 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.