Bon sang Google, je ne voulais plus bloguer. J'ai tellement de choses à faire. Bloguer demande du temps, de l'énergie et de la créativité, que je pourrais mettre à profit : mes livres, , mon jeu et ainsi de suite. Mais tu m'as suffisamment énervé pour que je doive écrire ceci.
Alors finissons-en.
Permettez-moi de commencer par une histoire courte mais instructive datant de mes débuts chez Google. Je sais que j'ai dit beaucoup de mauvaises choses à propos de Google ces derniers temps, mais cela me contrarie lorsque ma propre entreprise prend régulièrement des décisions commerciales incompétentes. En même temps, il faut lui rendre justice : l'infrastructure interne de Google est vraiment extraordinaire, on peut affirmer qu'il n'y a rien de mieux aujourd'hui. Les fondateurs de Google étaient de bien meilleurs ingénieurs que je ne le serai jamais, et cette histoire ne fait que confirmer ce fait.
Tout d’abord, un peu de contexte : Google dispose d’une technologie de stockage de données appelée . Il s’agissait d’une réalisation technique remarquable, l’un des premiers (sinon le premier) magasin de valeurs-clés (K/V) « infiniment évolutif » : essentiellement le début de NoSQL. De nos jours, Bigtable se porte toujours bien dans l'espace de stockage K/V plutôt encombré, mais à l'époque (2005), c'était incroyablement cool.
Ce qui est amusant à propos de Bigtable, c'est qu'ils disposaient d'objets de plan de contrôle interne (dans le cadre de l'implémentation) appelés serveurs de tablettes, avec des index volumineux, 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 demandaient comment mettre en œuvre l'évolutivité et ont soudainement réalisé qu'ils pouvaient remplacer les serveurs de tablettes par d'autres systèmes de stockage Bigtable. Bigtable fait donc partie de l'implémentation Bigtable. Ces installations de stockage sont présentes à tous les niveaux.
Un autre détail intéressant est que pendant un certain temps, Bigtable est devenu populaire et omniprésent au sein de Google, chaque équipe disposant de son propre référentiel. Ainsi, lors de l'une des réunions du vendredi, Larry Page a demandé en passant : « Pourquoi avons-nous plus d'une Bigtable ? Pourquoi pas un seul ? » En théorie, un seul stockage devrait suffire à tous les besoins de stockage de Google. Bien sûr, ils ne se sont jamais tournés vers un seul pour des raisons pratiques de développement (comme les conséquences d’un éventuel échec), mais la théorie était intéressante. Un référentiel pour l'ensemble de l'Univers (Au fait, est-ce que quelqu'un sait si Amazon a fait ça 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 ressemblait à ceci :
Cher Steve,
Bonjour de la part de l'équipe Bigtable. Nous souhaitons vous informer que chez [nom du centre de données], vous utilisez un très, très ancien binaire Bigtable. Cette version n'est plus prise en charge et nous souhaitons vous aider à passer à la dernière version.
S'il vous plaît laissez-moi savoir si vous pouvez prévoir du temps pour travailler ensemble sur cette question.
Tous mes vœux,
Équipe Bigtable
Sur Google, vous recevez beaucoup de courrier, donc au premier coup d'œil, j'ai lu quelque chose comme ceci :
Cher destinataire,
Bonjour de la part d'une équipe. Nous voulons communiquer ce bla bla bla bla. Bla bla bla bla bla bla, et bla bla bla immédiatement.
S'il vous plaît laissez-nous savoir si vous pouvez réserver une partie de votre temps précieux pour le bla bla bla.
Tous mes vœux,
Une sorte de commande
Je l'ai presque supprimé tout de suite, mais au bord de ma conscience, j'ai ressenti un sentiment douloureux et tenace que pas tout à fait ça ressemble à une lettre officielle cependant évidemment, que le destinataire s'est trompé car je n'ai pas utilisé Bigtable.
Mais c'était étrange.
J'ai passé le reste de la journée à réfléchir alternativement au travail et au type de viande de requin à déguster dans la micro-cuisine, dont au moins trois étaient suffisamment proches pour pouvoir être frappées depuis mon siège avec un lancer de biscuit bien ciblé, mais le l’idée d’écrire ne m’a jamais laissé un sentiment croissant d’anxiété légère.
Ils ont clairement prononcé mon nom. Et l'e-mail a été envoyé à mon adresse e-mail, pas à celle de quelqu'un d'autre, et ce n'est pas cc : ou bcc :. Le ton est très personnel et clair. C'est peut-être une sorte d'erreur ?
Finalement, la curiosité a pris le dessus sur moi et je suis allé voir la console Borg dans le centre de données mentionné.
Et bien sûr, j’avais le stockage BigTable sous gestion. Je suis désolé, quoi? J'ai regardé son contenu, et wow ! Il provenait de l'incubateur Codelab dans lequel j'ai participé lors de ma première semaine chez Google en juin 2005. Codelab vous a obligé à exécuter Bigtable pour y écrire certaines valeurs, et je n'ai apparemment jamais fermé le stockage par la suite. Cela fonctionnait toujours même si plus de deux ans s'étaient écoulés.
Il y a plusieurs aspects remarquables dans cette histoire. Premièrement, le travail de Bigtable était si insignifiant à l'échelle de Google que deux ans plus tard, quelqu'un a remarqué le stockage supplémentaire, et uniquement parce que la version du binaire était obsolète. À titre de comparaison, j'ai déjà envisagé d'utiliser pour mon jeu en ligne. À l'époque, ce service coûtait environ 16 000 $ par an. vide Bigtable sur GCP. Je ne dis pas qu'ils vous arnaquent, mais à mon avis, cela représente beaucoup d'argent pour une putain de base de données vide.
Un autre aspect remarquable est que le stockage je travaille toujours après deux ans. WTF ? Les centres de données vont et viennent ; ils subissent des pannes, ils subissent une maintenance programmée, ils changent tout le temps. Le matériel est mis à jour, les commutateurs sont échangés, tout est constamment amélioré. Comment diable ont-ils pu faire fonctionner mon programme pendant deux ans avec tous ces changements ? Cela peut sembler une réalisation modeste en 2020, mais en 2005-2007, elle a été assez impressionnante.
Et le plus merveilleux, c'est qu'une équipe d'ingénieurs externes dans un autre État me contacte, le propriétaire d'une petite instance presque vide de Bigtable, qui a trafic nul depuis deux ans - et nous proposons notre aide pour le mettre à jour.
Je les ai remerciés, j'ai supprimé le stockage et la vie a continué comme d'habitude. Mais treize ans plus tard, je pense encore à cette lettre. Parce que parfois je reçois des e-mails similaires de Google Cloud. Ils ressemblent à ceci :
Cher utilisateur de Google Cloud,
Pour rappel, nous arrêterons le service [service essentiel que vous utilisez] à partir d'août 2020, après quoi vous ne pourrez plus mettre à niveau vos instances. Nous vous recommandons de passer à la dernière version, qui est en phase de test bêta, ne contient aucune documentation, aucun chemin de migration et est auparavant obsolète avec notre aimable aide.
Nous nous engageons à garantir que ce changement ait un impact minimal sur tous les utilisateurs de la plate-forme Google Cloud.
Meilleurs amis pour toujours,
Plateforme Google Cloud
Mais je ne lis presque jamais de telles lettres, car ce qu’elles disent en réalité c’est :
Cher destinataire,
Va au diable. Va te faire foutre, va te faire foutre, va te faire foutre. Abandonnez tout ce que vous faites parce que cela n'a pas d'importance. Ce qui compte, c'est notre époque. Nous perdons du temps et de l'argent à entretenir nos conneries et nous en avons marre donc nous ne les supporterons plus. Alors abandonnez vos putains de projets et commencez à fouiller dans notre documentation merdique, à mendier des restes sur les forums, et au fait, notre nouvelle merde est complètement différente de l'ancienne merde, parce que nous avons plutôt foiré ce design, hein, mais c'est votre problème, pas le nôtre.
Nous continuons à faire des efforts pour que tous vos développements deviennent inutilisables d'ici un an.
S'il te plaît, va te faire foutre
Plateforme Google Cloud
Et le fait est que je reçois de telles lettres environ une fois par mois. Cela arrive si souvent et si constamment qu'ils sont inévitablement repoussé moi de GCP au camp anti-cloud. Je n’accepte plus de dépendre de leurs développements propriétaires, car en fait il est plus facile pour les devops de maintenir un système open source sur une simple machine virtuelle que d’essayer de suivre Google avec sa politique de fermeture de produits « obsolètes ».
Avant de revenir à Google Cloud, car je même proche Nous n’avons pas fini de les critiquer, regardons les performances de l’entreprise dans d’autres domaines. Les ingénieurs de Google sont fiers de leur discipline en matière d'ingénierie logicielle, et c'est ce qui pose réellement des problèmes. La fierté est un piège pour les imprudents, et elle a conduit de nombreux employés de Google à penser que leurs décisions sont toujours les bonnes et qu'avoir raison (selon une définition vague et floue) est plus important que de se soucier des clients.
Je vais donner quelques exemples aléatoires provenant d'autres grands projets en dehors de Google, mais j'espère que vous voyez ce modèle partout. C'est le suivant : la compatibilité ascendante maintient les systèmes en vie et à jour pendant des décennies.
La rétrocompatibilité est l'objectif de conception de tous les systèmes performants conçus pour ouvert utilisation, c'est-à-dire implémentée avec du code open source et/ou des standards ouverts. J'ai l'impression de dire quelque chose de trop évident pour que tout le monde soit mal à l'aise, mais non. Il s’agit d’une question politique, des exemples sont donc nécessaires.
Le premier système que je choisirai est le plus ancien : GNU Emacs, qui 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 difficile à expliquer, mais en un mot, Emacs est une plateforme créée en 1976 (oui, il y a près d'un demi-siècle) pour programmer afin de vous rendre plus productif, mais se faisant passer pour un éditeur de texte.
J'utilise Emacs tous les jours. Oui, j'utilise aussi IntelliJ tous les jours, il est devenu une puissante plateforme d'outils à part entière. Mais écrire des extensions pour IntelliJ est une tâche beaucoup plus ambitieuse et complexe que d'écrire des extensions pour Emacs. Et plus important encore, tout ce qui est écrit pour Emacs est préservé pour toujours.
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, voire plus tôt. Ils peuvent nécessiter quelques ajustements de temps en temps, mais c'est vraiment assez rare. Je ne connais rien de ce que j'ai écrit pour Emacs (et j'en ai beaucoup écrit) qui ait nécessité une réarchitecture.
Emacs a une fonction appelée make-obsolete pour les entités obsolètes. La terminologie d'Emacs pour les concepts informatiques fondamentaux (tels que ce qu'est une « fenêtre ») diffère souvent des conventions industrielles car Emacs les a introduites il y a longtemps. C'est un danger typique pour ceux qui sont en avance sur leur temps : tous vos termes sont incorrects. Mais Emacs a un concept de dépréciation, qui dans leur jargon est appelé obsolescence.
Mais dans le monde Emacs, il semble y avoir une définition de travail différente. Une philosophie sous-jacente différente, si vous voulez.
Dans le monde d'Emacs (et dans de nombreux autres domaines, que nous aborderons ci-dessous), le statut d'API obsolète signifie essentiellement : "Vous ne devriez vraiment pas utiliser cette approche, car même si elle fonctionne, elle souffre de diverses lacunes que nous allons liste ici. Mais en fin de compte, c'est votre choix. »
Dans le monde de Google, être obsolète signifie : « Nous ne respectons pas notre engagement envers vous ». C'est vrai. C’est essentiellement ce que cela signifie. Cela signifie qu'ils vous forceront régulièrement faire du travail, peut-être beaucoup de travail, en guise de punition pour avoir cru en eux : Nous avons le meilleur logiciel. Le plus rapide! Vous faites tout selon les instructions, lancez votre application ou service, et puis paf, au bout d'un an ou deux ça casse.
C'est comme vendre une voiture d'occasion qui tombera définitivement en panne après 1500 XNUMX km.
Ce sont deux définitions philosophiques complètement différentes de « l’obsolescence ». La définition de l'odorat selon Google . je ne crois pas ça en fait l'obsolescence programmée au même sens qu'Apple. Mais Google envisage définitivement de casser vos programmes, de manière détournée. Je le sais parce que j'y ai travaillé en tant qu'ingénieur logiciel pendant plus de 12 ans. Ils ont de vagues directives internes sur le degré de compatibilité descendante à respecter, mais cela dépend en fin de compte de chaque équipe ou service individuel. Il n’existe aucune recommandation au niveau de l’entreprise ou de l’ingénierie, et la recommandation la plus audacieuse en termes de cycles d’obsolescence est « d’essayer de donner aux clients 6 à 12 mois pour effectuer la mise à niveau avant de casser l’ensemble de leur système ».
Le problème est bien plus important qu’ils ne le pensent, et il persistera pendant des années car le service client ne fait pas partie de leur ADN. Plus d’informations à ce sujet ci-dessous.
À ce stade, je vais faire une déclaration audacieuse selon laquelle Emacs réussit dans une large mesure et même fondamentalement parce qu'ils prennent la compatibilité descendante très au sérieux. En fait, c'est la thèse de notre article. Les systèmes ouverts efficaces et durables doivent leur succès aux microcommunautés qui vivent autour d'eux depuis des décennies. extensions/plugins. C'est l'écosystème. J'ai déjà parlé de la nature des plates-formes et de leur importance, ainsi que du fait que Google n'a jamais, dans toute son histoire, compris ce qui se passe dans la création d'une plate-forme ouverte réussie en dehors d'Android ou de Chrome.
En fait, je devrais mentionner brièvement Android car vous y pensez probablement.
Tout d'abord, Android n'est pas Google. Ils n’ont presque rien de commun entre eux. Android est une société rachetée par Google en juillet 2005. Elle a été autorisée à fonctionner de manière plus ou moins autonome et est en fait restée largement intacte dans les années qui ont suivi. Android est une pile technologique notoire et une organisation épineuse tout aussi notoire. Comme l’a dit un Googleur : « Vous ne pouvez pas simplement vous connecter à Android ».
Dans un article précédent, j'ai expliqué à quel point certaines des premières décisions de conception d'Android étaient mauvaises. Bon sang, quand j'ai écrit cet article, ils déployaient des conneries appelées « applications instantanées » qui sont maintenant (surprise !) , et je sympathise si vous avez été assez stupide pour écouter Google et déplacer votre contenu vers ces applications instantanées.
Mais il y a une différence ici, une différence significative, c'est que les utilisateurs d'Android comprennent vraiment l'importance des plates-formes et font de leur mieux pour que les anciennes applications Android continuent de fonctionner. En fait, leurs efforts pour maintenir la compatibilité ascendante sont si extrêmes que même moi, lors de mon bref passage dans la division Android il y a quelques années, je me suis retrouvé à essayer de les convaincre d'abandonner le support de certains des appareils et API les plus anciens (j'avais tort). , comme c'était le cas dans beaucoup d'autres choses passées et présentes. Désolé les gars Android ! Maintenant que je suis allé en Indonésie, je comprends pourquoi nous en avons besoin).
Les utilisateurs d'Android poussent la rétrocompatibilité à des extrêmes presque inimaginables, accumulant d'énormes quantités de dettes techniques héritées dans leurs systèmes et chaînes d'outils. Oh mon dieu, vous devriez 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 très convoité prix "You're Not Google". Ils ne veulent vraiment pas devenir Google, qui ne sait pas créer des plateformes durables, mais Android sait, comment faire. Google est donc très intelligent sur un point : permettre aux gens de faire les choses à leur manière sur Android.
Cependant, les applications instantanées pour Android étaient une idée assez stupide. Et savez-vous pourquoi? Parce qu'ils ont exigé réécrire et repenser votre application! C'est comme si les gens allaient simplement réécrire deux millions d'applications. Je suppose qu'Instant Apps était une idée de Googler.
Mais il y a une différence. La rétrocompatibilité a un coût élevé. Android lui-même supporte le fardeau de ces coûts, tandis que Google insiste pour que le fardeau soit supporté. vous, client payant.
Vous pouvez voir l’engagement d’Android en faveur de la compatibilité ascendante dans ses API. Lorsque quatre ou cinq sous-systèmes différents font littéralement la même chose, c'est un signe certain qu'il existe un engagement fondamental en faveur de la rétrocompatibilité. Ce qui dans le monde des plateformes est synonyme d’engagement envers vos clients et votre marché.
Le principal problème de Google ici est sa fierté quant à son hygiène technique. Ils n’aiment pas qu’il existe de nombreuses façons différentes de faire la même chose, avec les anciennes méthodes moins souhaitables à côté des nouvelles méthodes plus sophistiquées. Cela augmente la courbe d'apprentissage pour ceux qui découvrent le système, cela augmente la charge de maintenance des API existantes, cela ralentit la vitesse des nouvelles fonctionnalités et le péché capital est que ce n'est pas joli. Google - comme Lady Ascot d'Alice au pays des merveilles de Tim Burton :
Dame Ascot :
- Alice, tu sais de quoi j'ai le plus peur ?
- Le déclin de l'aristocratie ?
- J'avais peur d'avoir petits-enfants laids.
Pour comprendre le compromis entre beau et pratique, jetons un coup d'œil à la troisième plateforme à succès (après Emacs et Android) et voyons comment elle fonctionne : Java lui-même.
Java possède de nombreuses API obsolètes. La dépréciation est très populaire parmi les programmeurs Java, encore plus que dans la plupart des langages de programmation. Java lui-même, le langage de base, et les bibliothèques déprécient constamment les API.
Pour ne prendre qu'un exemple parmi des milliers, considéré comme obsolète. Il est obsolète depuis la sortie de Java 1.2 en décembre 1998. Cela fait 22 ans que cela est obsolète.
Mais mon code actuel en production tue toujours les threads quotidiennement. Tu penses vraiment que c'est bien ? Absolument! Bien sûr, si je devais réécrire le code aujourd'hui, je l'implémenterais différemment. Mais le code de mon jeu, qui a fait le bonheur de centaines de milliers de personnes au cours des deux dernières décennies, est écrit avec une fonction permettant de fermer les threads qui traînent trop longtemps, et je 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 de travail avec lui en production, et je peux le dire avec certitude : dans mon cas, fermer ces threads de travail spécifiques est complètement sans valeur. Cela ne vaut pas le temps et les efforts nécessaires pour réécrire ce code, et je remercie Larry Ellison (probablement) qu'Oracle ne m'ait pas forcé à le réécrire.
Oracle comprend probablement aussi les plates-formes. Qui sait.
Des preuves peuvent être trouvées dans les principales API Java, qui sont criblées de vagues d'obsolescence, comme les lignes d'un glacier dans un canyon. Vous pouvez facilement trouver cinq ou six gestionnaires de navigation clavier différents (KeyboardFocusManager) dans la bibliothèque Java Swing. Il est en fait difficile de trouver une API Java qui ne soit pas obsolète. Mais ils fonctionnent toujours ! Je pense que l'équipe Java ne supprimera véritablement une API que 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 tous les domaines logiciels, nous sommes confrontés à des alternatives concurrentes. À tout moment, les programmeurs du langage X envisagent le langage Y comme un remplacement possible. Oh, tu ne me crois pas ? Voulez-vous l'appeler Swift ? Par exemple, tout le monde migre vers Swift et personne ne l’abandonne, n’est-ce pas ? Wow, comme tu en sais peu. Les entreprises comptent les coûts des équipes de développement doubles mobiles (iOS et Android) - et elles commencent à se rendre compte que ces systèmes de développement multiplateformes aux noms amusants comme Flutter et React Native fonctionnent réellement et peuvent être utilisés pour réduire la taille de leur doubler les équipes mobiles ou, à l'inverse, les rendre deux fois plus productives. Il y a de l'argent réel en jeu. Oui, il y a des compromis, mais d’un autre côté, il y a de l’argent.
Supposons hypothétiquement qu'Apple se soit bêtement inspiré de Guido van Rossum et ait déclaré que Swift 6.0 est rétrocompatible avec Swift 5.0, tout comme Python 3 est incompatible avec Python 2.
J'ai probablement raconté cette histoire il y a une dizaine d'années, mais il y a une quinzaine d'années, je suis allé au Foo Camp d'O'Reilly avec Guido, je me suis assis dans une tente avec Paul Graham et un groupe de gros bonnets. Nous sommes restés assis dans une chaleur étouffante en attendant que Larry Page s'envole dans son hélicoptère personnel pendant que Guido parlait de « Python 3000 », qu'il a nommé d'après le nombre d'années qu'il faudrait à tout le monde pour y migrer. Nous n'arrêtions pas de lui demander pourquoi il rompait la compatibilité, et il a répondu : « Unicode ». Et nous avons demandé : si nous devions réécrire notre code, quels autres avantages verrions-nous ? Et il a répondu "Yoooooooooooooouuuuuuuniiiiiiicoooooooode."
Si vous installez le SDK Google Cloud Platform (« gcloud »), vous recevrez la notification suivante :
Cher destinataire,
Nous aimerions vous rappeler que le support de Python 2 est obsolète, alors allez vous faire foutre
… et ainsi de suite. Cercle de la vie.
Mais le fait est que chaque développeur a le choix. Et si vous les forcez à réécrire le code assez souvent, ils pourraient penser à autre choix. Ils ne sont pas vos otages, peu importe à quel point vous souhaiteriez qu’ils le soient. Ce sont vos invités. Python est toujours un langage de programmation très populaire, mais bon sang, Python 3(000) a créé un tel désordre en lui-même, dans ses communautés et parmi les utilisateurs de ses communautés que les conséquences n'ont pas été éclaircies depuis quinze ans.
Combien de programmes Python ont été réécrits en Go (ou Ruby, ou une autre alternative) à cause de cette incompatibilité ascendante ? Combien de nouveaux logiciels ont été écrits dans autre chose que Python, même s'il pourrait être écrit en Python, si Guido n'avait pas incendié tout le village ? C'est difficile à dire, mais Python a clairement souffert. C'est un énorme désastre et tout le monde est perdant.
Supposons donc qu'Apple s'inspire de Guido et rompe la compatibilité. Que penses tu qu'il va advenir par la suite? Eh bien, peut-être que 80 à 90 % des développeurs réécriront leur logiciel si possible. En d’autres termes, 10 à 20 % de la base d’utilisateurs se tournent automatiquement vers un langage concurrent, tel que Flutter.
Faites cela plusieurs fois et vous perdrez la moitié de votre base d'utilisateurs. Tout comme dans le sport, dans le monde de la programmation, la forme actuelle compte aussi. всё. Quiconque perd la moitié de ses utilisateurs en cinq ans sera considéré comme un Big Fat Loser. Vous devez être tendance dans le monde des plateformes. Mais c’est là que ne pas prendre en charge les anciennes versions vous ruinera au fil du temps. Parce que chaque fois que vous vous débarrassez de certains développeurs, vous (a) les perdez pour toujours parce qu'ils sont en colère contre vous pour avoir rompu le contrat, et (b) les donnez à vos concurrents.
Ironiquement, j'ai également aidé Google à devenir une telle prima donna 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'instrumentation du code lui-même - similaire à un IDE, mais ici le service cloud stocke des représentations matérialisées de tous les milliards de lignes de code source de Google dans un vaste entrepôt de données.
Grok a fourni aux Googleurs un cadre puissant pour effectuer des refactorisations automatisées sur l'ensemble de leur base de code (littéralement dans Google). Le système calcule non seulement vos dépendances en amont (dont vous dépendez), mais également en aval (ce qui dépend de vous) donc lorsque vous changez d'API, vous savez tous ceux que vous cassez ! De cette façon, lorsque vous apportez des modifications, vous pouvez vérifier que chaque consommateur de votre API a mis à jour vers la nouvelle version, et en réalité, souvent avec l'outil Rosie qu'ils ont écrit, vous pouvez complètement automatiser le processus.
Cela permet à la base de code de Google d'être interne presque surnaturellement propre, car ces serviteurs robotiques se précipitent dans la maison et nettoient automatiquement tout s'ils ont renommé SomeDespicablyLongFunctionName en SomeDespicablyLongMethodName parce que quelqu'un a décidé que c'était un vilain petit-enfant et que son besoin était de l'endormir.
Et franchement, ça marche plutôt bien pour Google… en interne. Je veux dire, oui, la communauté Go de Google rigole bien avec la communauté Java de Google en raison de son habitude de refactorisation continue. Si vous redémarrez quelque chose N fois, cela signifie non seulement que vous l'avez foiré N-1 fois, mais qu'après un certain temps, il devient assez clair que vous l'avez probablement foiré également au Nième essai. Mais, dans l’ensemble, ils restent au-dessus de tout ce tapage et gardent le code « propre ».
Le problème commence lorsqu’ils tentent d’imposer cette attitude à leurs clients cloud et aux utilisateurs d’autres API.
Je vous ai un peu présenté Emacs, Android et Java ; Examinons la dernière plateforme à succès : le Web lui-même. Pouvez-vous imaginer combien d'itérations HTTP a subi depuis 1995, lorsque nous utilisions des balises clignotantes ? et les icônes « En construction » sur les pages Web.
Mais ça marche toujours ! Et ces pages fonctionnent toujours ! Oui, les gars, les navigateurs sont les champions du monde en matière de rétrocompatibilité. Chrome est un autre exemple de la rare plate-forme Google dont la tête est correctement vissée et, comme vous l'avez peut-être deviné, Chrome fonctionne effectivement comme une entreprise en mode bac à sable, distincte du reste de Google.
Je tiens également à remercier nos amis développeurs de systèmes d'exploitation : Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, etc., pour avoir fait un si bon travail de rétrocompatibilité sur leurs plateformes à succès (Apple obtient au mieux un C avec The l'inconvénient est qu'ils cassent tout tout le temps sans raison valable, mais d'une manière ou d'une autre, la communauté contourne ce problème à chaque version, et les conteneurs OS X ne sont toujours pas complètement obsolètes... pour le moment).
Mais attendez, dites-vous. Ne comparons-nous pas des pommes avec des oranges : des systèmes logiciels autonomes sur une seule machine comme Emacs/JDK/Android/Chrome par rapport aux systèmes multi-serveurs et aux API comme les services cloud ?
Eh bien, j'ai tweeté à ce sujet hier, mais à la manière de Larry Wall (créateur du langage de programmation Perl - env. per.) sur le principe de "suce/règles", j'ai recherché le mot obsolète sur les sites des développeurs Google et Amazon. Et bien qu'AWS ait des centaines fois plus d'offres de services que GCP, la documentation destinée aux développeurs de Google mentionne la dépréciation environ sept fois plus souvent.
Si quelqu'un chez Google lit ceci, il est probablement prêt à sortir des graphiques à la Donald Trump montrant qu'ils font tout correctement, et que je ne devrais pas faire de comparaisons injustes comme "nombre de mentions du mot obsolète versus nombre de prestations" "
Mais après toutes ces années, Google Cloud est toujours le service n°3 (je n'ai jamais écrit d'article sur la tentative ratée de devenir le n°2), mais si l'on en croit les initiés, certains craignent qu'ils pourraient bientôt tomber au rang de service n°4. Numéro XNUMX.
Je n'ai aucun argument convaincant pour « prouver » ma thèse. Tout ce que j'ai, ce sont les exemples colorés que j'ai accumulés au cours de 30 ans en tant que développeur. J'ai déjà évoqué la nature profondément philosophique de ce problème ; à certains égards, il est politisé dans les communautés de développeurs. Certains croient que créateurs les plateformes devraient se soucier de la compatibilité, tandis que d'autres pensent que c'est une préoccupation utilisateurs (les développeurs eux-mêmes). Un sur deux. En effet, n'est-ce pas une question politique lorsque nous décidons qui doit supporter les coûts des problèmes communs ?
C'est donc de la politique. Et mon discours suscitera probablement des réactions de colère.
Comme utilisateur Google Cloud Platform, et en tant qu'utilisateur d'AWS depuis deux ans (tout en travaillant pour Grab), je peux dire qu'il existe une énorme différence entre les philosophies d'Amazon et de Google en matière de priorités. Je ne développe pas activement sur AWS, donc je ne sais pas très bien à quelle fréquence ils suppriment les anciennes API. Mais on soupçonne que cela n’arrive pas aussi souvent que chez Google. Et je crois sincèrement que cette source de controverse et de frustration constante au sein de GCP est l'un des principaux facteurs freinant le développement de la plateforme.
Je sais que je n'ai pas cité d'exemples spécifiques de systèmes GCP qui ne sont plus pris en charge. Je peux dire que presque tout ce que j'ai utilisé, des réseaux (du plus ancien au VPC) au stockage (Cloud SQL v1-v2), Firebase (maintenant Firestore avec une API complètement différente), App Engine (ne commençons même pas) , points de terminaison cloud Cloud Endpoint et jusqu'à... Je ne sais pas - absolument tout ça vous a obligé à réécrire le code après un maximum de 2-3 ans, et ils n'ont jamais automatisé la migration pour vous, et souvent . Comme si c'était censé être le cas.
Et chaque fois que je regarde AWS, je me demande pourquoi diable je suis toujours sur GCP. Ils n'ont clairement pas besoin de clients. Ils ont besoin покупатели. Comprenez-vous la différence ? Laisse-moi expliquer.
Google Cloud a , où les gens proposent leurs solutions logicielles, et pour éviter l'effet restaurant vide, ils avaient besoin de le remplir de propositions, ils ont donc passé un contrat avec une société appelée Bitnami pour créer un ensemble de solutions qui sont déployées en « un clic », ou devraient J’écris moi-même « solutions », parce que celles-ci ne résolvent rien. Ils existent simplement sous forme de cases à cocher, de remplissage marketing, et Google ne s'est jamais soucié de savoir si l'un de ces outils fonctionnait réellement. Je connais des chefs de produit qui ont été aux commandes et je peux vous assurer que ces personnes s'en moquent.
Prenons, par exemple, une solution de déploiement prétendument « en un clic ». . J'en avais marre des manigances de Google Cloud SQL, alors j'ai commencé à envisager de créer mon propre cluster Percona comme alternative. Et cette fois, Google semblait avoir fait du bon travail, ils allaient me faire gagner du temps et des efforts en un seul clic !
Eh bien, super, allons-y. Suivons le lien et cliquons sur ce bouton. Sélectionnez « Oui » pour accepter tous les paramètres par défaut et déployer le cluster dans votre projet Google Cloud. Haha, ça ne marche pas. Aucune de ces conneries ne fonctionne. L'outil n'a jamais été testé et il a commencé à pourrir dès la première minute, et cela ne me surprendrait pas si plus de la moitié des "solutions" étaient des déploiements en un clic (on comprend maintenant pourquoi les guillemets) à tous ne marche pas. C'est une obscurité absolument désespérée, dans laquelle il vaut mieux ne pas entrer.
Mais Google a raison pulsions à vous de les utiliser. Ils veulent que tu acheté. Pour eux, c'est une transaction. Ils ne veulent rien soutenir. Cela ne fait pas partie de l'ADN de Google. Oui, les ingénieurs se soutiennent mutuellement, comme en témoigne mon histoire avec Bigtable. Mais dans les produits et services destinés aux gens ordinaires, ils toujours étaient impitoyables dans , qui n'atteint pas la barre de rentabilité même s'il compte des millions d'utilisateurs.
Et cela représente un véritable défi pour GCP, car c'est l'ADN de toutes les offres cloud. Ils n’essaient pas de soutenir quoi que ce soit ; Il est bien connu qu’ils refusent d’héberger (en tant que service géré) tout logiciel tiers. jusque là, jusqu'à ce qu'AWS fasse de même et construise une entreprise prospère autour de lui, et lorsque les clients exigent littéralement la même chose. Cependant, il faut un certain effort pour que Google prenne en charge quelque chose.
Ce manque de culture de support, associé à la mentalité « cassons-le pour le rendre plus beau », aliène les développeurs.
Et ce n’est pas une bonne chose si vous souhaitez construire une plateforme durable.
Google, réveille-toi, bon sang. Nous sommes en 2020 maintenant. Vous êtes toujours en train de perdre. Il est temps de vous regarder dans le miroir et de déterminer si vous souhaitez vraiment rester dans le secteur du cloud.
Si tu veux rester alors arrête de tout casser. Les gars, vous êtes riches. Nous, les développeurs, ne le faisons pas. Ainsi, lorsqu’il s’agit de savoir qui assumera le fardeau de la compatibilité, vous devez le prendre sur vous. Pas pour nous.
Parce qu’il y a au moins trois autres très bons nuages. Ils font signe.
Et maintenant, je vais passer à la réparation de tous mes systèmes défectueux. Euh.
Jusqu'à la prochaine fois!
PS Mise à jour après avoir lu certaines des discussions sur cet article (les discussions sont excellentes, d'ailleurs). La prise en charge de Firebase n'a pas été interrompue et il n'y a aucun projet à ma connaissance. Cependant, ils ont un méchant bug de streaming qui provoque le blocage du client Java dans App Engine. Un de leurs ingénieurs m'a aidé à résoudre ce problème, quand je travaillais chez Google, mais ils n'ont jamais réellement corrigé le bug, j'ai donc une solution de contournement merdique consistant à devoir redémarrer l'application GAE tous les jours. Et ce depuis quatre ans ! Ils ont maintenant Firestore. La migration vers celui-ci demandera beaucoup de travail car il s'agit d'un système complètement différent et le bug de 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 deux jours en raison d'un bug connu. Que puis-je dire à part l'utiliser à vos risques et périls. Je passe à Redis.
J'ai également vu des utilisateurs AWS plus expérimentés dire qu'AWS ne cesse généralement de prendre en charge aucun service, et SimpleDB en est un excellent exemple. Mes hypothèses selon lesquelles AWS n'a pas la même maladie de fin de support que Google semblent justifiées.
De plus, j'ai remarqué qu'il y a 20 jours, l'équipe Google App Engine a interrompu l'hébergement d'une bibliothèque Go critique, fermant une application GAE de l'un des principaux développeurs Go. C'était vraiment stupide.
Enfin, j'ai déjà entendu des Googleurs discuter de ce problème et être généralement d'accord avec moi (je vous aime les gars !). Mais ils semblent penser que le problème est insoluble parce que la culture de Google n’a jamais eu la bonne structure d’incitation. J'ai pensé qu'il serait bon de prendre le temps de discuter de l'expérience absolument incroyable que j'ai eue en travaillant avec les ingénieurs AWS lorsque je travaillais chez Grab. Un jour dans le futur, j'espère !
Et oui, en 2005, ils proposaient différents types de viande de requin sur le buffet géant du bâtiment 43, et ma préférée était la viande de requin marteau. Cependant, en 2006, Larry et Sergei se sont débarrassés de toutes les collations malsaines. Ainsi, lors de l'histoire de Bigtable en 2007, il n'y avait vraiment pas de requins et je vous ai trompé.
Lorsque j'ai examiné Cloud Bigtable il y a quatre ans (plus ou moins), c'est là que se situait le coût. Cela semble avoir un peu baissé maintenant, mais cela reste énormément pour un entrepôt de données vide, d'autant plus que ma première histoire montre à quel point une grande table vide est sans conséquence à leur échelle.
Désolé d'avoir offensé la communauté Apple et de ne rien dire de gentil sur Microsoft, etc. Vous allez bien, j'apprécie vraiment toute la discussion que cet article a générée ! Mais parfois, il faut faire un peu de vagues pour lancer une discussion, vous savez ?
Merci d'avoir lu.
Mise à jour 2, 19.08.2020/XNUMX/XNUMX. Bande !
Mise à jour 3, 31.08.2020/2/2. J'ai été contacté par un ingénieur Google chez Cloud Marketplace qui s'est avéré être un vieil ami à moi. Il voulait comprendre pourquoi CXNUMXD ne fonctionnait pas, et nous avons finalement compris que c'était parce que j'avais construit mon réseau il y a des années et que CXNUMXD ne fonctionnait pas sur les réseaux existants car le paramètre de sous-réseau manquait dans leurs modèles. Je pense qu'il est préférable que les utilisateurs potentiels de GCP s'assurent qu'ils connaissent suffisamment d'ingénieurs chez Google...
Source: habr.com