Mince alors, Google, je ne voulais pas de nouveau écrire sur le blog. J'ai tant de choses à faire. Tenir un blog demande du temps, de l'énergie et de la créativité que je pourrais utiliser à bon escient : mes livres, , mon jeu, et ainsi de suite. Mais tu m'as assez irrité pour que je me sente obligé d'en parler.
Alors, mettons un terme à cela.
Je vais commencer par une petite histoire instructive de l'époque où je venais à peine de commencer à travailler chez Google. Je sais que j'ai dit beaucoup de choses négatives sur Google ces derniers temps, mais cela m'attriste quand mon entreprise natale prend régulièrement des décisions commerciales incompétentes. Cela dit, il faut reconnaître que l'infrastructure interne de Google est vraiment extraordinaire, et l'on peut affirmer sans hésiter qu'il n'y a rien de mieux aujourd'hui. Les fondateurs de Google étaient des ingénieurs bien meilleurs que je ne le serai jamais, et cette histoire ne fait que confirmer ce fait.
D'abord un peu de contexte : Google possède une technologie de stockage de données appelée . C'était une réalisation technique remarquable, l'un des premiers (si ce n'est le premier) systèmes de stockage « indéfiniment évolutif » de paires « clé-valeur » : en gros, le début du NoSQL. De nos jours, Bigtable se porte toujours bien dans un espace de stockage K/V assez encombré, mais à l'époque (2005), c'était incroyablement cool.
Un détail amusant à propos de Bigtable est qu'ils avaient des objets internes de plan de contrôle (comme partie de l'implémentation) appelés serveurs tablet, avec de grands index, et à un moment donné, ils sont devenus un goulot d'étranglement lors de la mise à l'échelle du système. Les ingénieurs de Bigtable se creusaient la tête pour mettre en œuvre la scalabilité, et tout à coup, ils ont réalisé qu'ils pouvaient remplacer les serveurs tablet par d'autres systèmes de Bigtable. Ainsi, Bigtable fait partie de l'implémentation de Bigtable. Ces systèmes sont présents à tous les niveaux.
Un autre détail intéressant est qu'à un moment donné, Bigtable était devenu populaire et omniprésent à l'intérieur de Google, chaque équipe ayant son propre stockage. Ainsi, lors d'une des réunions du vendredi, Larry Page a demandé en passant : « Pourquoi avons-nous plus d'un Bigtable ? Pourquoi ne pas en avoir qu'un seul ? » Théoriquement, un seul stockage aurait dû suffire à tous les besoins de stockage de Google. Bien sûr, ils n'ont jamais transitionné vers un seul pour des raisons pratiques de développement (par exemple, les conséquences d'une panne potentielle), mais la théorie était intéressante. Un stockage pour tout l'univers (au fait, quelqu'un sait si Amazon a fait cela avec son Sable ?)
Quoi qu'il en soit, voici mon histoire.
À l'époque, je travaillais chez Google depuis un peu plus de deux ans, et un jour, j'ai reçu un e-mail de l'équipe d'ingénierie de Bigtable qui disait à peu près ceci :
Cher Steve,
Bonjour de l'équipe Bigtable. Nous tenons à vous informer qu'au centre de données [nom du centre de données], vous utilisez un fichier binaire Bigtable très, très ancien. Cette version n'est plus prise en charge et nous souhaitons vous aider à passer à la dernière version.
Veuillez nous faire savoir si vous pouvez planifier un moment pour travailler ensemble sur ce problème.
Cordialement,
L'équipe Bigtable
Chez Google, vous recevez beaucoup de courriels, donc à première vue, j'ai lu à peu près ceci :
Cher destinataire,
Bonjour d'une certaine équipe. Nous souhaitons vous informer que blabla blabla blabla. Blabla blabla blabla blabla, et blabla blabla immédiatement.
Veuillez nous faire savoir si vous pouvez planifier une partie de votre précieux temps pour blabla blabla.
Cordialement,
Une certaine équipe
J'ai presque supprimé ce message immédiatement, mais à la frontière de ma conscience, j'ai ressenti un sentiment lourd mais lancinant que cela n'est pas tout à fait comme un courrier formel, bien que évidemment, cela semblait être une erreur à l'adresse, car je n'ai pas utilisé Bigtable.
Mais c'était étrange.
Le reste de la journée, je pensais alternativement à mon travail et à quel type de chair de requin essayer dans la micro-cuisine, dont au moins trois étaient suffisamment proches pour pouvoir les atteindre d'un lancer habile de biscuit, mais la pensée de l'email ne me quittait pas, avec un sentiment croissant de légère anxiété.
Ils ont clairement mentionné mon nom. Et la lettre a été envoyée à mon adresse e-mail, et non à celle de quelqu'un d'autre, et ce n'est pas un cc : ou bcc :. Le ton est très personnel et clair. Est-ce une erreur ?
Enfin, la curiosité a pris le dessus et je suis allé voir la console Borg dans le centre de données qu'ils ont mentionné.
Et bien sûr, je gérais un stockage BigTable. Quoi ? J'ai regardé son contenu, et – incroyable ! Il provenait de l'incubateur Codelab, où j'ai passé ma première semaine de travail chez Google en juin 2005. Codelab vous forçait à lancer Bigtable afin que vous puissiez y enregistrer certaines valeurs, et il semble que je n'ai pas fermé le stockage après cela. Il fonctionnait toujours, même après plus de deux ans.
Cette histoire a plusieurs aspects remarquables. Tout d'abord, le fonctionnement de Bigtable était si insignifiant à l'échelle de Google, qu'il a fallu deux ans avant que quelqu'un ne remarque le stockage supplémentaire, et encore, c'était seulement parce que la version du binaire était obsolète. Pour comparer, j'avais envisagé d'utiliser pour mon jeu en ligne. À l'époque, ce service coûtait environ 16 000 $ par an pour un vide Bigtable sur GCP. Je ne dis pas qu'ils vous trompent, mais à mon avis, c'est beaucoup d'argent pour une base de données vide.
Un autre aspect remarquable est que le stockage était toujours fonctionnel après deux ans. WTF ? Les centres de données vont et viennent ; ils rencontrent des interruptions, ils effectuent une maintenance planifiée, ils changent tout le temps. Le matériel est mis à jour, les commutateurs changent de place, tout s'améliore constamment. Comment diable ont-ils réussi à garder mon programme en cours d'exécution pendant deux ans compte tenu de tous ces changements ? Cela peut sembler une réalisation modeste en 2020, mais en 2005-2007, c'était assez impressionnant.
Et l'aspect le plus remarquable est qu'une équipe d'ingénieurs d'un autre État me contacte, moi, propriétaire d'un petit, quasiment vide exemplaire de Bigtable, qui a zéro trafic depuis deux ans – et propose de l'aide pour le mettre à jour.
Je les ai remerciés, j'ai supprimé le stockage, et la vie a continué. Mais treize ans plus tard, je pense encore à cette lettre. Parce que parfois, je reçois des lettres similaires de Google Cloud. Elles ressemblent à ceci :
Cher utilisateur de Google Cloud,
Nous vous rappelons que nous mettons fin au service [important service que vous utilisez] à partir d'août 2020, après quoi vous ne pourrez plus mettre à jour vos instances. Nous vous recommandons de passer à la dernière version qui est en phase bêta, sans documentation aucune, sans chemin de migration et qui a déjà été dépréciée avec notre aide bienveillante.
Nous nous efforçons de minimiser l'impact de ce changement sur tous les utilisateurs de la plateforme Google Cloud.
Meilleurs amis pour toujours,
La plateforme Cloud de Google
Mais je lis presque jamais de tels courriers, car en réalité, ils disent ceci :
Cher destinataire,
Va te faire voir. Va-t-en, va-t-en, va-t-en. Laisse tout ce que tu fais, car ce n'est pas important. Ce qui compte, c'est notre temps. Nous dépensons du temps et de l'argent à gérer notre merde, et nous en avons assez, donc nous ne le soutiendrons plus. Donc, abandonne tes fichus plans et commence à fouiller dans notre piètre documentation, en quémandant des miettes sur les forums, et d'ailleurs, notre nouveau truc est complètement différent de l'ancien, car nous avons vraiment gâché ce design, héhé, mais c'est ton problème, pas le nôtre.
Nous continuons à faire des efforts pour que toutes tes développements deviennent inutilisables dans un an.
S'il te plaît, va te faire voir,
La plateforme Cloud de Google
Et le fait est que je reçois de tels courriers environ une fois par mois. Cela se produit si souvent et de manière si constante qu'ils m'ont inévitablement repoussé de GCP vers le camp des anti-clouds. Je ne veux plus dépendre de leurs développements propriétaires, car en réalité, il est plus facile pour un devops de maintenir un système open source sur une VM nue que d'essayer de suivre Google avec sa politique de fermeture des produits « obsolètes ».
Avant de revenir à Google Cloud, parce que je n'y suis même pas proche Il n'a pas cessé de les critiquer, examinons le travail de l'entreprise dans d'autres domaines. Les ingénieurs de Google sont fiers de leur discipline en matière de développement logiciel, et c'est en réalité ce qui pose problème. La fierté est un piège pour les imprudents, elle a conduit de nombreux employés de Google à penser que leurs décisions étaient toujours correctes et que la justesse (selon une définition vague et indéfinie) était plus importante que le souci des clients.
Je vais donner quelques exemples aléatoires d'autres grands projets en dehors de Google, mais j'espère que vous reconnaîtrez ce schéma partout. Il se résume ainsi : la compatibilité ascendante maintient la vitalité et la pertinence des systèmes pendant des décennies.
La compatibilité ascendante est un objectif de conception de tous les systèmes réussis conçus pour une utilisation ouverte, c'est-à-dire réalisés avec un code source ouvert et/ou selon des normes ouvertes. Je sens que je dis quelque chose de trop évident, qu'il dérange même tout le monde, mais non. C'est une question politique, donc des exemples sont nécessaires. Le premier système que je vais choisir est le plus ancien : GNU Emacs, c'est une sorte d'hybride entre le Bloc-notes Windows, le noyau du système d'exploitation et la Station spatiale internationale. C'est un peu compliqué à expliquer, mais en bref, Emacs est une plateforme créée en 1976 (oui, presque il y a cinquante ans) pour la programmation, afin d'accroître votre productivité, mais qui se présente comme un éditeur de texte.
J'utilise Emacs tous les jours. Oui, j'utilise aussi IntelliJ tous les jours, elle s'est déjà transformée en une puissante plateforme d'outils. Mais écrire des extensions pour IntelliJ est une tâche beaucoup plus ambitieuse et compliquée que d'écrire des extensions pour Emacs. Et ce qui est encore plus important, tout ce qui est écrit pour Emacs est
éternel. J'utilise encore un logiciel que j'ai écrit pour Emacs en 1995. Et je suis sûr que quelqu'un utilise des modules écrits pour Emacs dans les années 80, si ce n'est plus tôt. De temps en temps, ils peuvent nécessiter des ajustements mineurs, mais c'est vraiment assez rare. Je ne sais rien de ce que j'ai écrit pour Emacs (et j'en ai écrit beaucoup) qui aurait nécessité de reconstruire l'architecture..
J'utilise toujours le logiciel que j'ai écrit pour Emacs en 1995. Et je suis sûr que quelqu'un utilise des modules écrits pour Emacs au milieu des années 80, si ce n'est plus tôt. De temps en temps, ils peuvent nécessiter un léger ajustement, mais c'est vraiment assez rare. Je ne sais rien de ce que j'ai écrit pour Emacs (et j'en ai écrit beaucoup) qui nécessiterait une reconstruction de l'architecture.
Emacs a une fonction appelée make-obsolete pour les entités obsolètes. La terminologie d'Emacs pour les concepts informatiques fondamentaux (par exemple, ce qu'est une « fenêtre ») diffère souvent des conventions de l'industrie, car Emacs les a introduites il y a longtemps. C'est un danger typique pour ceux qui ont devancé leur temps : tous vos termes sont incorrects. Mais dans Emacs, il existe bel et bien un concept d'obsolescence, qui dans leur jargon est appelé obsolescence.
Mais dans le monde d'Emacs, il semble y avoir une autre définition de travail. Une autre philosophie fondamentale, si vous voulez.
Dans le monde d'Emacs (et dans de nombreux autres domaines que nous examinerons ci-dessous), le statut d'API obsolète signifie principalement : « Vous ne devriez vraiment pas utiliser cette approche, car, bien qu'elle fonctionne, elle a divers inconvénients que nous énumérerons ici. Mais, en fin de compte, c'est votre choix ».
Dans le monde de Google, un produit obsolète signifie : « Nous rompions nos engagements envers vous ». C'est vraiment ça. Voici ce que cela signifie en substance. Cela signifie qu'ils vous obligeront à faire régulièrement un certain travail, peut-être un travail important, en punition d'avoir cru à leur : nous avons le meilleur logiciel. Le plus rapide ! Vous suivez toutes les instructions, lancez votre application ou service, puis — bam, dans un an ou deux, ça tombe en panne.
C'est comme vendre une voiture d'occasion qui va sûrement tomber en panne après 1500 km.
Ce sont deux définitions philosophiques complètement différentes de « l'obsolescence ». La définition de Google sent l' . Je ne crois pas que ce soit en réalité une obsolescence programmée dans le même sens que chez Apple. Mais Google prévoit sûrement de casser vos programmes, de manière détournée. Je le sais, parce que j'y ai travaillé comme ingénieur logiciel pendant plus de 12 ans. Ils ont des recommandations internes vagues sur la mesure dans laquelle ils doivent respecter la compatibilité descendante, mais en fin de compte, cela dépend de chaque équipe ou service. Il n'y a pas de recommandations au niveau corporate ou ingénierie, et la recommandation la plus audacieuse en termes de cycles d'obsolescence est « essayez de donner aux clients 6-12 mois pour mettre à jour avant de leur casser tout le système ».
Le problème est bien plus sérieux qu'ils ne le pensent, et il perdurera pendant de nombreuses années, car le service client ne fait pas partie de leur ADN. En savoir plus ci-dessous.
Pour l'heure, je vais faire une affirmation audacieuse, à savoir que Emacs est couronné de succès dans une large mesure et même principalement parce qu'ils prennent très au sérieux la compatibilité ascendante. En effet, c'est là le point central de notre article. Les systèmes open source prospères et durables doivent leur succès aux micro-communautés qui ont vécu pendant des décennies autour des extensions/plugins. C'est ça, un écosystème. J'ai déjà réfléchi à la nature des plateformes et à leur importance, et à la manière dont Google n'a jamais, dans toute son histoire d'entreprise, compris ce qui entre dans la création d'une plateforme ouverte réussie, à l'exception d'Android ou de Chrome.
En fait, je dois brièvement mentionner Android, parce que vous y avez sûrement pensé.
D'abord, Android n'est pas Google. Ils n'ont presque rien en commun. Android est une entreprise qui a été achetée par Google en juillet 2005, cette entreprise a été autorisée à fonctionner de manière plus ou moins autonome et en réalité, elle est restée largement intacte au fil des années. Android est la fameuse pile technologique et la même organisation controversée. Comme l'a dit un Googler, "on ne peut pas simplement entrer dans Android".
Dans un de mes articles précédents, j'ai déjà réfléchi à la mauvaise qualité de certaines des premières décisions de conception d'Android. Mon dieu, quand j'ai écrit cet article, ils étaient en train de déployer une m*rde appelée "applications instantanées", qui maintenant (surprise!) , et je compatis si vous avez été assez naïf pour écouter Google et déplacer votre contenu vers ces applications instantanées.
Mais il y a une différence, une différence substantielle, qui réside dans le fait que les gens d'Android comprennent vraiment à quel point les plateformes sont importantes, et ils s'efforcent de maintenir la compatibilité des anciennes applications Android. En fait, leurs efforts pour préserver la rétrocompatibilité sont si extrêmes que même moi, lors de mon bref passage au sein de l'équipe Android il y a quelques années, j'ai tenté de les convaincre d'abandonner le support de certains des appareils et API les plus anciens (j'avais tort, comme dans bien d'autres choses du passé et du présent. Désolé, les gars d'Android ! Maintenant que j'ai été en Indonésie, je comprends pourquoi ils en ont besoin).
Les gens d'Android maintiennent la rétrocompatibilité jusqu'à des extrêmes presque inimaginables, ce qui engendre une énorme quantité de dettes techniques obsolètes dans leurs systèmes et chaînes d'outils. Mon Dieu, vous auriez dû voir certaines des choses folles qu'ils doivent faire dans leur système de construction, tout cela au nom de la compatibilité.
Pour cela, j'attribue à Android le précieux prix "Tu n'es pas Google". Ils ne veulent vraiment pas devenir Google, qui n'est pas capable de créer des plateformes durables, alors qu'Android sait, comment le faire. Et donc, Google agit très sagement d'une certaine manière : il permet aux gens d'Android de faire les choses à leur manière.
Cependant, les applications instantanées pour Android étaient une idée plutôt ridicule. Et savez-vous pourquoi ? Parce qu'elles nécessitaient de réécrire et de repenser votre application! Comme si les gens allaient simplement réécrire deux millions d'applications. Je suppose que les applications instantanées étaient l'idée de quelqu'un chez Google.
Mais il y a une différence. La rétrocompatibilité implique de grands coûts. Android porte lui-même ce fardeau, tandis que Google insiste pour que ce fardeau soit supporté par vous, client payant.
Vous pouvez voir l'engagement d'Android envers la rétrocompatibilité dans ses interfaces API. Lorsque vous avez quatre ou cinq sous-systèmes différents pour réaliser littéralement la même chose, c'est un signe certain qu'il y a un engagement envers la rétrocompatibilité. Ce qui, dans le monde des plateformes, équivaut à un engagement envers vos clients et votre marché.
Le principal problème de Google ici est leur fierté en matière d'hygiène technique. Ils n'aiment pas qu'il y ait plusieurs façons de faire la même chose, surtout lorsque de vieilles méthodes moins désirables cohabitent avec de nouvelles méthodes plus originales. Cela augmente la courbe d'apprentissage pour les nouveaux utilisateurs dans le système, cela accroît le fardeau de support des API obsolètes, cela ralentit la vitesse d'introduction de nouvelles fonctionnalités, et le péché majeur — c'est que c'est inesthétique. Google est comme Lady Escott dans "Alice au pays des merveilles" de Tim Burton :
Lady Escott :
— Alice, sais-tu ce que je crains le plus ?
— La décadence de l'aristocratie ?
— J'avais peur d'avoir des petits-enfants peu esthétiques.
Pour comprendre le compromis entre le beau et le pratique, regardons la troisième plateforme réussie (après Emacs et Android) et voyons comment elle fonctionne : Java elle-même.
Java regorge d'APIs obsolètes. La dépréciation est très populaire parmi les programmeurs Java, même plus que dans la plupart des langages de programmation. Au sein de Java, le langage principal et les bibliothèques subissent constamment des dépréciations d'API.
Prenons un exemple parmi des milliers, est considérée comme obsolète. Elle est devenue obsolète depuis la sortie de Java 1.2 en décembre 1998. Cela fait 22 ans qu'elle est obsolète.
Mais mon vrai code en production ferme encore des threads chaque jour. Est-ce une bonne chose ? Absolument ! Je veux dire, bien sûr, si j'écrivais le code aujourd'hui, je le ferais différemment. Mais le code de mon jeu, qui a rendu des centaines de milliers de personnes heureuses au cours des deux dernières décennies, a été écrit avec la fonction de fermeture de threads, qui restent souvent suspendus, et je n'ai jamais eu besoin de le changer. Je connais mon système mieux que quiconque, j'ai littéralement 25 ans d'expérience en production avec, et je peux dire avec certitude : dans mon cas, la fermeture de ces threads en particulier est tout à fait inoffensive. Il n'est pas judicieux de perdre du temps et des efforts à réécrire ce code, et louons Larry Ellison (probablement) pour qu'Oracle ne m'ait pas obligé à le réécrire.
Probablement qu'Oracle s'y connaît également en plateformes. Qui sait.
Vous pouvez rencontrer des preuves dans toutes les API Java clés, qui sont traversées par des vagues de dépréciation, comme des lignes de glacier dans un canyon. Dans la bibliothèque Java Swing, il est facile de trouver cinq ou six différents gestionnaires de navigation au clavier (KeyboardFocusManager). Il est en réalité difficile de trouver une API Java qui n'est pas dépréciée. Mais elles fonctionnent toujours ! Je pense que l'équipe Java supprimera réellement une API uniquement si l'interface pose un problème de sécurité flagrant.
Voici le problème, les amis : nous, les développeurs de logiciels, sommes tous très occupés, et dans chaque domaine du logiciel, nous sommes confrontés à des alternatives concurrentes. À tout moment, les programmeurs en langage X envisagent le langage Y comme un remplacement potentiel. Oh, vous ne me croyez pas ? Vous voulez parler de Swift ? Vous savez, tout le monde migre vers Swift et personne ne le rejette, n'est-ce pas ? Wow, combien vous en savez peu. Les entreprises considèrent les coûts des équipes mobiles doubles (iOS et Android) — et elles commencent à comprendre que ces systèmes de développement multiplateformes avec des noms ridicules, comme Flutter et React Native, fonctionnent vraiment, et qu'avec eux, elles peuvent réduire la taille de leurs équipes mobiles de moitié ou, au contraire, les rendre deux fois plus productives. De l'argent réel est en jeu. Oui, il y a des compromis, mais d'un autre côté, de l'argent.
Supposons hypothétiquement qu'Apple, par stupidité, prenne exemple sur Guido van Rossum et déclare que Swift 6.0 n'est pas rétrocompatible avec Swift 5.0, tout comme Python 3 n'est pas compatible avec Python 2.
Je suppose que j'ai raconté cette histoire il y a dix ans, mais il y a environ quinze ans, je suis allé au camp Foo Camp d'O'Reilly avec Guido, j'étais dans une tente avec Paul Graham et un tas de gros bonnets. Nous étions assis sous la chaleur épuisante, en attendant que Larry Page arrive en hélicoptère privé, tandis que Guido répétait de façon monotone « Python 3000 », qu'il a nommé en référence aux années qu'il faudrait à tout le monde pour y migrer. Nous ne cessions de lui demander pourquoi il rompait la compatibilité, et il répondait : “Unicode”. Et nous lui demandions, si nous devions réécrire notre code, quels autres avantages nous verrions ? Et il répondait “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.
Si vous installez le SDK de Google Cloud Platform (“gcloud”), vous recevrez la notification suivante :
Cher destinataire,
Nous tenons à vous rappeler que le support de Python 2 est obsolète, alors allez-vous faire voir.
… et ainsi de suite. Le cycle de la vie.
Mais le fait est que chaque développeur a le choix. Et si on les force à réécrire leur code trop souvent, ils pourraient envisager d'autres options. Ils ne sont pas vos captifs, même si vous le souhaitez. Ils sont vos invités. Python reste un langage de programmation très populaire, mais, bon sang, Python 3(000) a créé un tel chaos au sein de ses communautés et chez les utilisateurs de ses communautés, que les conséquences ne peuvent pas être résolues depuis quinze ans. Combien de programmes Python ont été réécrits en Go (ou Ruby, ou quelque autre alternative) à cause de cette incompatibilité rétroactive ? Combien de nouveaux logiciels ont été écrits dans quelque chose d'autre que Python, alors qu'ils
auraient pu l'être en Python, si Guido n'avait pas brûlé le village ? Il est difficile de le dire, mais Python a clairement souffert. C'est un énorme désordre, et tout le monde perd. Alors, supposons qu'Apple prenne exemple sur Guido et enfreigne la compatibilité. Que pensez-vous qu'il arrivera ensuite ? Eh bien, peut-être que 80-90 % des développeurs réécriront leur logiciel, si c'est possible. En d'autres termes, 10-20 % de la base d'utilisateurs partent automatiquement vers un langage concurrent, comme Flutter.
Faites cela plusieurs fois - et vous perdrez la moitié de votre base d'utilisateurs. Comme dans le sport, dans le monde de la programmation, la forme actuelle compte aussi
beaucoup. Quiconque perdra la moitié de ses utilisateurs en cinq ans sera considéré comme un Grand Gros Échec. Vous devez être à la mode dans le monde des plateformes. Mais c'est justement ici que l'abandon du support des anciennes versions vous tuera avec le temps. Parce qu'à chaque fois que vous vous séparez d'une partie des développeurs, vous (a) les perdez pour toujours, car ils vous en veulent pour rupture de contrat, et (b) les cédez à vos concurrents.Ironiquement, j'ai aussi aidé Google à devenir cette diva qui ignore la compatibilité rétroactive, lorsque j'ai créé Grok, un système d'analyse et de compréhension du code source qui facilite l'automatisation et l'outillage basé sur le code lui-même - ça ressemble à un IDE, mais ici, un service cloud stocke des représentations matérialisées de tous les milliards de lignes de code source de Google dans un grand entrepôt de données.
Ironiquement, j'ai aussi aidé Google à devenir cette diva qui ignore la rétrocompatibilité, lorsque j'ai créé Grok, un système d'analyse et de compréhension du code source qui facilite l'automatisation et l'outillage basé sur le code lui-même — cela ressemble à un IDE, mais ici, le service cloud stocke les vues matérialisées de tous les milliards de lignes de code source de Google dans un grand entrepôt de données.
Grok a fourni aux développeurs de Google une base solide pour réaliser un refactoring automatisé dans l'ensemble de la base de code (littéralement dans tout Google). Le système calcule non seulement vos dépendances ascendantes (sur lesquelles vous dépendez), mais aussi les dépendances descendantes (qui dépendent de vous), donc lorsque vous changez d'API, vous connaissez tous ceux que vous cassez ! Ainsi, lorsque vous apportez des modifications, vous pouvez vérifier que chaque consommateur de votre API a été mis à jour vers la nouvelle version, et en réalité, souvent avec l'outil Rosie, qu'ils ont développé, vous pouvez entièrement automatiser le processus.
Cela permet à la base de code de Google d'être presque surnaturellement « propre » en interne, car ils ont ces serviteurs automatisés qui fourmillent dans la maison et nettoient automatiquement tout si jamais ils renomment SomeDespicablyLongFunctionName en SomeDespicablyLongMethodName, car quelqu'un a décidé que c'était un petit-enfant peu beau et qu'il fallait l'endormir.
Et, soyons honnêtes, cela fonctionne plutôt bien pour Google… en interne. Je veux dire, oui, la communauté Go chez Google se moque gentiment de la communauté Java chez Google en raison de leur tendance à un refactoring constant. Si vous relancez quelque chose N fois, cela signifie que vous l'avez non seulement cassé N-1 fois, mais qu'à un moment donné, il devient clair que vous l'avez probablement aussi cassé lors de la N-ième tentative. Mais, dans l'ensemble, ils restent au-dessus de ce tumulte et maintiennent le code « propre ».
Les problèmes commencent lorsqu'ils essaient d'imposer cette attitude à leurs clients cloud et aux utilisateurs d'autres API.
Je vous ai un peu présenté Emacs, Android et Java ; regardons la dernière plateforme réussie et pérenne : le Web lui-même. Pouvez-vous imaginer combien d'itérations HTTP a traversées depuis 1995, lorsque nous utilisions des balises clignotantes <blink> et des icônes « En développement » sur les pages Web.
Mais cela fonctionne toujours ! Et ces pages fonctionnent toujours ! Oui, les amis, les navigateurs sont des champions du monde de la rétrocompatibilité. Chrome est un autre exemple d'une plateforme rare de Google qui est bien conçue, et comme vous l'avez deviné, Chrome agit efficacement comme une entreprise isolée, séparée du reste de Google.
Je tiens également à remercier nos amis parmi les développeurs de systèmes d'exploitation : Windows, Linux, PAS APPLE TU ES APPLE, FreeBSD et ainsi de suite, pour le grand travail qu'ils ont accompli en matière de compatibilité descendante sur leurs plateformes à succès (Apple reçoit au mieux une note de trois avec un moins, car ils cassent constamment tout sans raison valable, mais d'une manière ou d'une autre, la communauté s'en sort à chaque version, et jusqu'à présent, les conteneurs avec OS X ne sont pas encore complètement obsolètes… pour l'instant).
Mais attendez, allez-vous dire. Ne comparons-nous pas des pommes et des oranges — des systèmes logiciels autonomes sur une seule machine, comme Emacs/JDK/Android/Chrome, avec des systèmes multiserveurs et des API, comme dans les services cloud ?
Eh bien, j'en ai parlé hier sur Twitter, mais dans le style de Larry Wall (le créateur du langage de programmation Perl — ndt.) avec le principe "nul/règles", j'ai cherché le mot déprécié sur les sites pour développeurs de Google et Amazon. Et bien que AWS ait des centaines de fois plus d'offres de services que GCP, la documentation pour développeurs de Google mentionne la dépréciation environ sept fois plus souvent.
Si quelqu'un de Google lit ceci, il est sûrement prêt à sortir des diagrammes comme dans le style de Donald Trump, montrant qu'ils font tout correctement, et que je ne devrais pas faire de comparaisons injustes, telles que "le nombre de mentions du mot déprécié par rapport au nombre de services".
Mais après tant d'années, Google Cloud reste toujours le service n° 3 (je n'ai toujours pas écrit d'article sur la tentative infructueuse de le faire devenir n° 2), mais si l'on en croit les initiés, il y a certaines inquiétudes qu'ils pourraient bientôt descendre au n° 4.
Je n'ai pas d'arguments convaincants pour "prouver" mon propos. Tout ce que j'ai, ce sont des exemples colorés que j'ai accumulés au cours de mes 30 années de travail en tant que développeur. J'ai déjà mentionné la nature profondément philosophique de ce problème ; d'une certaine manière, elle est politisée dans les communautés de développeurs. Certains pensent que les créateurs de plateformes doivent se soucier de la compatibilité, tandis que d'autres estiment que c'est la préoccupation des utilisateurs (les développeurs eux-mêmes). L'un ou l'autre. Et en réalité, n'est-ce pas une question politique, quand nous décidons qui doit supporter les coûts des problèmes communs ?
Donc c'est de la politique. Et il y aura sûrement des réponses indignées à ma déclaration.
Comment utilisateur En tant qu'utilisateur de la plateforme Google Cloud et d'AWS pendant deux ans (en travaillant pour Grab), je peux dire qu'il y a une grande différence entre les philosophies d'Amazon et de Google en ce qui concerne les priorités. Je ne fais pas de développement actif sur AWS, donc je ne sais pas à quelle fréquence ils retirent les anciennes API. Mais j'ai l'impression que cela ne se produit pas aussi fréquemment que chez Google. Et je crois sincèrement que cette source de disputes et de frustrations constantes dans GCP est l'un des principaux facteurs qui freinent le développement de la plateforme.
Je sais que je n'ai pas mentionné d'exemples concrets de systèmes GCP dont le support a été arrêté. Je peux dire que presque tout ce que j'ai utilisé, des réseaux (des plus anciens à VPC) aux systèmes de stockage (Cloud SQL v1-v2), Firebase (maintenant Firestore avec une API complètement différente), App Engine (ne commençons même pas) et aux points de terminaison cloud Cloud Endpoint... je ne sais pas — absolument tout cela obligeait à réécrire le code tous les 2-3 ans au maximum, et ils n'ont jamais automatisé la migration pour vous, souvent . Comme si c'était normal.
Et chaque fois que je regarde AWS, je me demande pourquoi je suis encore sur GCP. Ils n'ont clairement pas besoin de clients. Ils ont besoin de acheteurs. Comprenez la différence ? Laissez-moi expliquer.
Google Cloud a un , où les gens proposent leurs solutions logicielles, et pour éviter l'effet du restaurant vide, il fallait le remplir avec certaines offres, alors ils ont signé un contrat avec Bitnami pour créer plein de solutions qui se déploient "en un clic", ou je dois écrire moi-même des "solutions", parce que celles-ci ne résolvent rien. Elles existent simplement comme des cases à cocher, comme un remplissage marketing, et Google ne s'est jamais soucié de savoir si l'un des outils fonctionnait réellement. Je connais des chefs de produits qui étaient aux commandes et je peux vous assurer que ces personnes s'en moquent.
Prenons par exemple une solution censée se déployer "en un clic" . J'en ai assez des tours de Google Cloud SQL, alors j'ai commencé à envisager de créer mon propre cluster Percona en alternative. Et cette fois, il semble que Google ait fait un bon travail, ils allaient me faire gagner du temps et des efforts d'un simple clic !
Eh bien, allons-y. Cliquons sur le lien et appuyons sur ce bouton. Choisissons « Oui » pour accepter tous les paramètres par défaut et déployer le cluster dans notre projet Google Cloud. Haha, ça ne fonctionne pas. Rien de tout ça ne marche. L'outil n'a jamais été testé et il a commencé à pourrir dès la première minute, et je ne serais pas surpris que plus de la moitié des « solutions » de déploiement en un clic (maintenant nous comprenons pourquoi les guillemets) ne fonctionne pas. C'est une obscurité totale, bien mieux vaut ne pas y entrer.
Mais Google appelle directement à utiliser leurs services. Ils veulent que tu les achètes.Pour eux, c'est une transaction. Ils ne veulent rien soutenir.Ce n'est pas dans l'ADN de Google. Oui, les ingénieurs se soutiennent mutuellement, comme le prouve mon histoire avec Bigtable. Mais dans les produits et services destinés au grand public, ils ont toujours été impitoyables dans qui ne répond pas au niveau de rentabilité, même s'il a des millions d'utilisateurs.
Et cela pose un véritable problème pour GCP, car cet ADN est à la base de toutes leurs offres cloud. Ils ne cherchent pas à soutenir quoi que ce soit ; il est bien connu qu'ils refusent d'héberger (en tant que service géré) tout logiciel tiers jusqu'à ce qu'AWS fasse de même et construise un business autour, et lorsque les clients exigeront littéralement la même chose. Cependant, il faut fournir des efforts pour obliger Google à soutenir quelque chose.Cette absence de culture de soutien, combinée au principe « cassons pour embellir », aliène les développeurs.
Et ce n'est pas très bon si vous voulez construire une plateforme pérenne.
Google, réveille-toi, bon sang. Nous sommes en 2020. Tu es toujours à la traîne. Il est temps de se regarder dans le miroir et de répondre à la question de savoir si tu veux vraiment rester dans le secteur du cloud.
Si tu veux rester, alors
arrête de tout casser. Les gars, vous êtes riches. Nous, développeurs, ne le sommes pas. Donc, quand il s'agit de savoir qui devra assumer le fardeau de la compatibilité, vous devez le prendre en charge. Pas nous.Parce qu'il y a encore au moins trois vraiment bons clouds. Ils vous attirent.
Et maintenant, je vais continuer à réparer tous mes systèmes cassés. Ah.
À la prochaine fois !
À la prochaine fois !
P. S. Mise à jour après avoir lu certaines discussions sur cet article (les discussions sont d'ailleurs excellentes). Le support de Firebase n'a pas été arrêté, et il n'y a pas de plans à ma connaissance. Cependant, ils ont un bug de streaming désagréable qui fait que le client Java se bloque dans App Engine. L'un de leurs ingénieurs m'a aidé à gérer ce problème, quand je travaillais chez Google, mais ils n'ont jamais vraiment corrigé le bug, donc j'ai un contournement plutôt médiocre, je dois redémarrer l'application GAE chaque jour. Cela fait déjà quatre ans ! Maintenant, ils ont Firestore. Il faudra beaucoup de travail pour migrer vers cela, car c'est un système complètement différent, et le bug Firebase ne sera jamais corrigé. Quelle conclusion peut-on en tirer ? Vous pouvez obtenir de l'aide, si vous travaillez dans une entreprise. Je suis probablement le seul à utiliser Firebase sur GAE, car j'enregistre moins de 100 clés dans une application 100 % native, et elle cesse de fonctionner tous les quelques jours en raison d'un bug connu. Que dire de plus, si ce n'est l'utiliser à vos propres risques. Je passe à Redis.
J'ai aussi vu certains utilisateurs plus expérimentés d'AWS dire qu'AWS n'arrête généralement jamais le support de ses services, et SimpleDB en est un excellent exemple. Mes suppositions selon lesquelles AWS n'a pas ce problème d'arrêt de support comme Google semblent se confirmer.
De plus, j'ai remarqué qu'il y a 20 jours, l'équipe de Google App Engine a brisé l'hébergement d'une bibliothèque Go essentielle, fermant l'application GAE d'un des principaux développeurs de Go. C'était vraiment stupide.
Enfin, j'ai entendu dire que les Googlers discutaient déjà de ce sujet et étaient en général d'accord avec moi (je vous aime, les gars !). Mais il semble qu'ils considèrent le problème comme irrésolvable, car il n'y a jamais eu de véritable structure d'incitation dans la culture de Google. Je pense qu'il serait bon de prendre un peu de temps pour discuter de l'expérience absolument incroyable que j'ai eue avec les ingénieurs d'AWS lorsque j'ai travaillé chez Grab. Un de ces jours dans le futur, j'espère !
Oui, en 2005, ils avaient effectivement différents types de viande de requin sur un immense buffet dans le bâtiment 43, et j'aimais particulièrement la viande de requins à marteau. Cependant, en 2006, Larry et Sergey ont éliminé toutes les collations malsaines. Donc, pendant l'histoire de Bigtable en 2007, il n'y avait vraiment plus de requins et je vous ai menti délibérément.
Quand j'ai examiné Bigtable il y a quatre ans (plus ou moins), le coût était exactement le même. Il semble que ce soit un peu moins cher maintenant, mais cela reste vraiment très cher pour un espace de stockage de données vide, surtout sachant que ma première histoire montre à quel point une grande table vide est insignifiante à leur échelle.
Désolé d'avoir offensé la communauté Apple et de ne rien avoir dit de bon sur Microsoft, etc. Vous avez tous raison, j'apprécie beaucoup toutes les discussions suscitées par cet article ! Mais parfois, il faut un peu créer des vagues pour commencer la conversation, vous comprenez ?
Merci de votre lecture.
Mise à jour 2, 19.08.2020. Stripe !
Mise à jour 3, 31.08.2020. Un ingénieur de Google de Cloud Marketplace m'a contacté, qui s'est révélé être un vieil ami. Il voulait comprendre pourquoi C2D ne fonctionnait pas, et finalement, nous avons découvert : le problème venait du fait que j'avais créé mon réseau il y a plusieurs années, et C2D ne fonctionnait pas sur les réseaux obsolètes en raison d'un paramètre de sous-réseau manquant dans leurs modèles. Je pense que les utilisateurs potentiels de GCP devraient s'assurer d'avoir suffisamment d'ingénieurs familiers chez Google...
Source : habr.com
