Alors finissons-en.
Je vais commencer par une petite mais instructive histoire de mon premier travail chez Google. Je sais que j'ai dit beaucoup de mauvaises choses à propos de Google ces derniers temps, mais cela me dérange lorsque mon entreprise d'origine prend régulièrement des décisions commerciales incompétentes. Cela dit, nous devons rendre hommage: l'infrastructure interne de Google est vraiment extraordinaire et nous pouvons affirmer avec certitude 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 appelée Bigtable . C'était une réalisation technique remarquable, l'une des premières (sinon la première) magasin de valeurs-clés (K / V) «infiniment évolutif»: essentiellement le début de NoSQL. Bigtable se sent toujours bien dans l'espace de stockage K / V plutôt encombré de nos jours, mais à l'époque (2005), c'était incroyablement cool.
Une chose amusante à propos de Bigtable est qu'ils avaient des objets de plan de contrôle interne (dans le cadre de l'implémentation) appelés serveurs de tablettes, 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 sont demandé comment mettre en œuvre l'évolutivité et ont soudainement réalisé qu'ils pouvaient remplacer les serveurs de tablettes par d'autres stockages Bigtable. Bigtable fait donc partie de l'implémentation Bigtable. Ces installations de stockage sont là à tous les niveaux.
Un autre détail intéressant est que pendant un certain temps, Bigtable est devenu populaire et omniprésent dans Google, et chaque équipe avait son propre référentiel. Ainsi, lors d'une des réunions de vendredi, Larry Page a demandé en passant: «Pourquoi avons-nous plus d'un Bigtable? Pourquoi pas un seul? En théorie, un stockage aurait dû être suffisant pour tous les besoins de stockage de Google. Bien sûr, ils ne sont jamais passés à un seul pour des raisons de développement pratique (comme les conséquences d'un échec potentiel), mais la théorie était intéressante. Un référentiel pour tout l'univers (au fait, est-ce que quelqu'un sait si Amazon a fait ça avec son sable? )
Bref, voici mon histoire
À l'époque, je travaillais chez Google pendant un peu plus de deux ans et un jour, j'ai reçu un e-mail de l'équipe d'ingénierie de Bigtable quelque chose comme ceci:
Cher Steve,
Salutations de l'équipe Bigtable. Nous tenons à vous informer que vous utilisez un très très ancien binaire Bigtable dans le centre de données de [nom du centre de données]. Cette version n'est plus prise en charge et nous souhaitons vous aider à passer à la dernière version.
Veuillez me faire savoir si vous pouvez prévoir du temps pour travailler ensemble sur ce problème.
Tous les meilleurs, l'
équipe BigTable
Vous recevez beaucoup de courrier sur Google, donc à première vue, j'ai lu quelque chose comme ceci:
,
- . , ----. -----, -- .
, , --.
,
-
Je l'ai presque effacée tout de suite, mais au bord de ma conscience, j'ai ressenti une sensation douloureuse et douloureuse que cela ne ressemble pas tout à fait à une lettre formelle, même s'il est évident que le destinataire s'est trompé parce que je n'ai pas utilisé Bigtable.
Mais c'était bizarre.
Le reste de la journée, j'ai alternativement pensé au travail et au type de viande de requin à essayer dans une micro-cuisine, dont au moins trois étaient assez proches pour sortir de ma place avec un biscuit bien ciblé, mais l'idée d'écrire ne m'a pas laissé grandir. légère anxiété.
Ils ont clairement appelé mon nom. Et l'e-mail est envoyé à mon adresse e-mail, pas à quelqu'un d'autre, et ce n'est pas cc: ou cci:. Le ton est très personnel et clair. C'est peut-être une sorte d'erreur?
Finalement, la curiosité a pris le dessus et je suis allé jeter un œil à la console Borg dans le centre de données dont ils parlaient.
Et bien sûr, j'avais le stockage BigTable sous mon contrôle. Je suis désolé, quoi? J'ai regardé son contenu, et - wow! C'était de l'incubateur Codelab où j'ai passé ma première semaine chez Google en juin 2005. Codelab vous a obligé à démarrer Bigtable pour y écrire des valeurs, et je n'ai probablement jamais fermé le référentiel après cela. Cela fonctionnait toujours, bien que plus de deux ans se soient écoulés.
Il y a plusieurs aspects notables à cette histoire. Premièrement, le travail de Bigtable était si insignifiant à l'échelle de Google que seulement deux ans plus tard, quelqu'un a remarqué le stockage supplémentaire, et même alors seulement parce que la version du binaire était obsolète. À titre de comparaison, j'ai déjà envisagé d'utiliserBigtable sur Google Cloud pour mon jeu en ligne. À l'époque, ce service coûtait environ 16 000 USD par an pour une Bigtable vide sur GCP. Je ne dis pas qu'ils vous trompent, mais à mon avis personnel, c'est beaucoup d'argent pour une putain de base de données vide.
Un autre aspect notable est que le stockage fonctionnait toujours après deux ans... WTF? Les centres de données vont et viennent; ils subissent des interruptions, ils subissent un entretien courant, 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 fait fonctionner mon programme pendant deux ans avec tous ces changements? Cela peut sembler une réalisation modeste en 2020, mais c'était assez impressionnant en 2005-2007.
Et l'aspect le plus merveilleux est qu'une équipe d'ingénierie extérieure dans un autre État me contacte, le propriétaire d'une petite instance presque vide de Bigtable, qui n'a eu aucun trafic au cours des deux dernières années - et offre de l'aide pour la mettre à jour. ...
Je les ai remerciés, j'ai enlevé le coffre-fort et la vie a continué comme d'habitude. Mais treize ans plus tard, je pense toujours à cette lettre. Parce que parfois, je reçois des e-mails comme celui-ci de Google Cloud. Ils ressemblent à ceci:
Cher utilisateur de Google Cloud, Nous
vous rappelons que nous interrompons le service [un service important que vous utilisez] à partir d'août 2020, après quoi vous ne pourrez plus mettre à jour vos instances. Nous vous recommandons de mettre à niveau vers la dernière version, qui est en test bêta, n'a pas de documentation, pas de chemin de migration et est obsolète à l'avance avec notre aimable aide.
Nous nous engageons à minimiser l'impact de ce changement sur tous les utilisateurs de la plateforme Google Cloud.
Meilleurs amis pour toujours,
Google Cloud Platform
Mais je lis à peine de telles lettres, car en fait elles disent ce qui suit:
Cher destinataire, va
te faire foutre. Va te faire foutre, baise toi, baise toi. Jetez tout ce que vous faites parce que cela n'a pas d'importance. Ce qui compte, c'est notre temps. Nous dépensons du temps et de l'argent pour soutenir notre merde et nous en avons assez, donc nous ne le soutiendrons plus. Alors abandonnez vos putains de plans et commencez à fouiller dans notre documentation de merde, en demandant des notes sur les forums, et au fait, notre nouvelle merde est complètement différente de la vieille merde parce que nous avons assez mal foiré cette conception, hein, mais c'est votre problème, non notre.
Nous continuons à travailler dur pour rendre toutes vos créations inutilisables en un an.
Allez non,
Google Cloud Platform
Et le fait est que je reçois de telles lettres environ une fois par mois. Cela se produit si souvent et si constamment qu'ils m'ont inévitablement poussé loin du GCP et dans le camp du cloud opposé. Je n'accepte plus de dépendre de leur développement propriétaire, car en fait, il est plus facile pour un devops de maintenir un système open source sur une machine virtuelle nue que d'essayer de suivre Google avec sa politique de fermeture des produits "obsolètes".
Avant de revenir à Google Cloud car je suis même prochepas 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 génie logiciel et c'est ce qui cause réellement des problèmes. La fierté est un piège pour les imprudents; elle a conduit de nombreux employés de Google à penser que leurs décisions sont toujours bonnes et qu'être juste (selon une définition vague et floue) est plus important que le service client.
Voici quelques exemples arbitraires d'autres grands projets en dehors de Google, mais j'espère que vous verrez ce modèle partout. C'est comme suit: la rétrocompatibilité 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 pourutilisation ouverte , c'est-à-dire mise en œuvre avec des normes open source et / ou ouvertes. J'ai l'impression de dire quelque chose de trop évident que tout le monde est même mal à l'aise, mais non. C'est une question politique, il faut donc des exemples.
Le premier système que j'ai choisi 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 plate-forme créée en 1976 (oui, il y a presque un demi-siècle) pour programmer pour augmenter votre productivité, mais se déguise en éditeur de texte.
J'utilise Emacs tous les jours. Oui, j'utilise aussi IntelliJ tous les jours, c'est devenu une puissante plateforme d'outillage en soi. Mais écrire des extensions pour IntelliJ est beaucoup plus ambitieux et difficile que d'écrire des extensions pour Emacs. Et plus important encore, tout ce qui est écrit pour Emacs durera 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, sinon avant. Ils peuvent nécessiter des ajustements mineurs de temps en temps, mais c'est vraiment assez rare. Je ne sais rien de ce que j’ai jamais écrit pour Emacs (et j’ai beaucoup écrit) qui aurait à repenser l’architecture.
Emacs a une fonction appelée rendre obsolète pour les entités héritées. La terminologie Emacs pour les concepts informatiques fondamentaux (comme ce qu'est une «fenêtre») diffère souvent des conventions de l'industrie parce qu'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 d'obsolescence, qui dans leur jargon est appelé obsolescence .
Mais dans le monde Emacs, il semble y avoir une définition de travail différente. Une autre philosophie sous-jacente, si vous voulez.
Dans le monde Emacs (et dans de nombreux autres domaines que nous aborderons ci-dessous), le statut de dépréciation des API signifie essentiellement: «Vous ne devriez vraiment pas utiliser cette approche, car même si cela fonctionne, elle souffre de divers inconvénients que nous énumérerons ici. Mais en fin de compte, c'est votre choix. "
Dans le monde Google, le statut de l'ancien produit signifie "Nous ne respectons pas nos obligations envers vous". Ça l'est vraiment. C'est ce que cela signifie essentiellement. Cela signifie qu'ils vous forceront à faire du travail régulièrement , peut-être beaucoup de travail, comme punition pour avoir cru en leurs publicités colorées : nous avons le meilleur logiciel. Le plus rapide! Vous faites tout selon les instructions, lancez votre application ou service, puis bam, après un an ou deux ça casse.
C'est comme vendre une voiture d'occasion qui tombera définitivement 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' obsolescence planifiée . Je ne crois pas que ce soit vraimentobsolescence prévue dans le même sens qu'Apple. Mais Google envisage définitivement de casser vos programmes de manière détournée. Je le sais car j'y ai travaillé en tant qu'ingénieur logiciel pendant plus de 12 ans. Ils ont des directives internes vagues sur le niveau de compatibilité ascendante, mais en fin de compte, cela dépend de chaque équipe ou service individuel. Il n'y a pas de recommandation de niveau entreprise ou d'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 à niveau avant de casser l'ensemble du système.
Le problème est beaucoup plus grave 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 ci-dessous.
Pour l'instant, je vais faire la déclaration audacieuse qu'Emacs réussit en grande partie, et même surtout , parce qu'ils prennent la compatibilité descendante si au sérieux. En fait, c'est la thèse de notre article. Les systèmes open source à longue durée de vie qui réussissent doivent leur succès aux microcommunautés qui vivent autour d' extensions / plugins depuis des décennies . C'est ça l'écosystème. J'ai déjà parlé de l'essence des plates-formes et de leur importance, et comment Google n'a jamais, dans toute son histoire d'entreprise, 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 dois mentionner brièvement Android, car vous y avez probablement pensé.
Premièrement, Android n'est pas Google... Ils n'ont presque rien à voir les uns avec les autres. Android est une société rachetée par Google en juillet 2005, cette société a été autorisée à fonctionner de manière plus ou moins autonome et est en fait restée en grande partie intacte au fil des ans. Android est une pile technologique infâme et une organisation épineuse tout aussi infâme. Comme l'a dit un googleur, "Vous ne pouvez pas simplement accéder à Android".
Dans l'un de mes articles précédents, j'ai expliqué à quel point certaines des premières décisions de conception d'Android étaient mauvaises. Heck, quand j'ai écrit cet article, ils déployaient une merde appelée "Instant Apps" qui sont maintenant (surprise!) Obsolèteset compatissez si vous étiez assez stupide pour écouter Google et apporter votre contenu à ces applications instantanées.
Mais il y a une différence, 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 fonctionnent. En fait, leurs efforts pour maintenir la compatibilité descendante sont si extrêmes que même moi, au cours de mon bref passage dans la division Android il y a quelques années, je me suis retrouvé à essayer de les convaincre d'abandonner la prise en charge de certains des appareils et API les plus anciens 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 gens d'Android maintiennent la compatibilité descendante à des extrêmes presque inimaginables, accumulant une énorme dette technologique obsolète dans leurs systèmes et leurs chaînes d'outils. Oh mon dieu, vous auriez dû voir des choses folles qu'ils doivent faire dans leur système de construction, tout cela au nom de la compatibilité.
Pour cela, je décerne à Android le très convoité prix You Are Not Google. Ils ne veulent vraiment pas devenir Google, qui ne sait pas comment créer des plates-formes durables, mais Android sait comment le faire. Et donc Google est très sage sur un point: il permet aux utilisateurs d'Android de faire les choses à leur manière.
Cependant, les applications Android instantanées étaient une idée assez stupide. Est-ce que tu sais pourquoi? Parce qu'ils ont exigéréécrivez et redessinez votre application ! Comme si les gens prenaient et réécrivaient simplement deux millions d'applications. Je suppose que les applications instantanées étaient l'idée d'un googler.
Mais il y a une différence ici. La rétrocompatibilité coûte cher. Android lui-même supporte le fardeau de ces coûts, tandis que Google insiste pour que vous , le client payant, en supportiez le fardeau .
Vous pouvez voir l'engagement d'Android en matière de compatibilité descendante dans ses API. Lorsque vous avez quatre ou cinq sous-systèmes différents pour faire littéralement la même chose, c'est un signe certain qu'un engagement de compatibilité descendante est au cœur. 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 leur fierté pour leur hygiène technique. Ils n'aiment pas quand il existe de nombreuses façons différentes de faire la même chose, avec des moyens plus anciens et moins souhaitables à côté de moyens plus récents et plus bizarres. Cela augmente la courbe d'apprentissage pour les nouveaux arrivants dans le système, cela augmente le fardeau de la maintenance des API héritées, cela ralentit la vitesse des nouvelles fonctionnalités et le principal péché est laid. Google - comme Lady Ascot de "Alice au pays des merveilles" de Tim Burton:
Lady Ascot:
- Alice, tu sais de quoi j'ai le plus peur?
- Le déclin de l'aristocratie?
- J'avais peur d'avoir des petits-enfants laids .
Pour comprendre le compromis entre beau et pratique, jetons un coup d'œil à la troisième plate-forme à succès (après Emacs et Android) et voyons comment cela fonctionne: Java lui-même.
Java possède une tonne d'API héritées. La dépréciation est très populaire auprès des programmeurs Java, encore plus populaire que la plupart des langages de programmation. Dans Java lui-même, le langage principal et les bibliothèques, les dépréciations d'API se produisent constamment.
Si vous ne prenez qu'un exemple parmi des milliers, la fermeture des flux est obsolète. Il est obsolète depuis la sortie de Java 1.2 en décembre 1998. Cela fait 22 ans que cela a été abandonné.
Mais mon vrai code de production tue toujours les threads tous les jours... Est-ce bien? Absolument! Je veux dire, 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 pour fermer les threads qui bloquent trop longtemps, et je n'ai jamais eu à le changer . Je connais le mieux mon système, 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, la fermeture de ces flux de travail spécifiques est totalement inoffensive . Vous ne devriez pas perdre de temps et d'efforts à réécrire ce code, et féliciter Larry Ellison (probablement) qu'Oracle ne m'a pas forcé à le réécrire.
Il est probable qu'Oracle connaisse également les plates-formes. Qui sait.
Des preuves peuvent être trouvées pour toutes les API Java de base 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 au 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 vraiment l'API que si l'interface cause un problème de sécurité flagrant.
Voici la chose les gars: 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 X considèrent Y comme un remplacement possible. Oh tu ne me crois pas? Voulez-vous être appelé Swift? Comme, tout le monde migre vers Swift et personne n'abandonne, non? Wow, combien vous en savez peu. Les entreprises comptabilisent les coûts de deux équipes de développement mobile (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 et peuvent réduire la taille de leurs équipes mobiles. deux fois ou, au contraire, les rendre deux fois plus productives. L'argent réel est en jeu. Oui, il y a des compromis, mais, d'autre part, de-l'argent électronique.
Supposons, hypothétiquement, qu'Apple prenne bêtement l'exemple de Guido van Rossum et annonce 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 dix ans, mais il y a quinze ans je est allé au Foo Camp d'O'Reilly avec Guido, s'est assis dans une tente avec Paul Graham et un tas de grosses bosses. Nous nous sommes assis dans la chaleur étouffante et avons attendu que Larry Page décolle dans son hélicoptère personnel, tandis que Guido marmonnait monotone à propos du Python 3000, qu'il a nommé d'après le nombre d'années qu'il faudrait à tout le monde pour y migrer. Nous lui avons demandé tout le temps pourquoi cela rompt la compatibilité, et il a répondu: «Unicode». Et nous avons demandé, si nous devons réécrire notre code, quels autres avantages verrons-nous? Et il a répondu «Yoooooooooooooouuuuuuuniiiiiiicoooooooode».
Si vous installez le SDK Google Cloud Platform («gcloud»), vous recevrez la notification suivante:
Cher destinataire,
Nous souhaitons vous rappeler que la prise en charge de Python 2 est obsolète, vous aussi?
… etc. Le cercle de la vie.
Mais le fait est que chaque développeur a le choix. Et si vous leur demandez de réécrire le code assez souvent, ils peuvent penser à d' autres options. Ce ne sont pas vos otages, peu importe combien vous voulez qu'ils soient. Ce sont vos invités. Python est toujours un langage de programmation très populaire, mais diable, Python 3 (000) a créé un tel désordre à lui seul, dans ses communautés et parmi les utilisateurs de ses communautés, que les conséquences n'ont pas été élucidées depuis quinze ans.
Combien de programmes Python ont été réécrits dans Go (ou Ruby, ou une autre alternative) en raison de cette incompatibilité descendante? Combien de nouveaux logiciels ont été écrits dans autre chose que Python, même si cela aurait pu ê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 gâchis et tout le monde est un perdant.
Disons donc qu'Apple suit l'exemple de Guido et rompt 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 s'ils le peuvent. En d'autres termes, 10 à 20% de la base d'utilisateurs se tournent automatiquement vers une langue concurrente 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 signifie aussi tout.... Quiconque perd la moitié de ses utilisateurs en cinq ans sera considéré comme un Big Fat Loser. Vous devriez être à la mode dans le monde des plateformes. Mais c'est là que refuser de prendre en charge les anciennes versions vous tuera au fil du temps. Parce qu'à chaque fois que vous vous débarrassez d'une partie des 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 aussi contribué à faire de Google le genre de prima donna rétrocompatible 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és sur le code - similaire à un IDE, mais ici, les magasins de services cloud se sont matérialisés. représentations de tous les milliards de lignes de code source Google dans un grand entrepôt de données.
Grok a fourni aux googleurs un cadre puissant pour la refactorisation automatisée sur l'ensemble de la base de code (littéralement partout sur Google). Le système calcule non seulement vos dépendances en amont (dont vous dépendez), mais aussi les dépendances en aval (qui dépendent de vous), donc lorsque vous changez l'API, vous connaissez tout le monde que vous cassez! De cette façon, lorsque vous apportez des modifications, vous pouvez vérifier que chaque consommateur de votre API est 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 presque surnaturellement «propre» en interne, 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 pensait que c'était un petit-fils moche, et doivent être endormis.
Et pour être honnête, cela fonctionne plutôt bien pour Google ... en interne. Je veux dire, oui, la communauté Go de Google se moque vraiment bien de la communauté Java de Google en raison de son habitude de refactorisation continue. Si vous redémarrez quelque chose N fois, cela signifie que non seulement vous l'avez gâché N-1 fois, mais après un certain temps, il devient tout à fait clair que vous l'avez probablement gâché au Nième essai. Mais dans l'ensemble, ils restent au-dessus de l'agitation et gardent 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 présenté un peu Emacs, Android et Java; Jetons un coup d'œil à la dernière plate-forme à succès: le Web lui-même. Vous pouvez imaginer combien d'itérations HTTP a traversé depuis 1995, lorsque nous avons utilisé des balises clignotantes <blink> et des icônes de construction sur les pages Web.
Mais ça marche toujours! Et ces pages fonctionnent toujours! Oui, les navigateurs sont les champions mondiaux de la rétrocompatibilité. Chrome est un autre exemple de plate-forme Google rare dont la tête est correctement vissée et, vous l'avez deviné, Chrome agit effectivement comme une entreprise isolée distincte du reste de Google.
Je tiens également à remercier nos amis parmi les développeurs de systèmes d'exploitation: Windows, Linux, PAS APPLE FOLLOW YOU APPLE, FreeBSD et ainsi de suite, pour avoir fait autant de travail de rétrocompatibilité sur leurs plates-formes à succès (Apple obtient au mieux un triple moins, car ils cassent constamment tout sans raison, mais d'une manière ou d'une autre, la communauté gère cela dans chaque version, et jusqu'à présent, les conteneurs OS X ne sont pas encore complètement obsolètes ...).
Mais attendez, dites-vous. Ne comparons-nous pas des pommes à des oranges - des systèmes logiciels autonomes sur une seule machine comme Emacs / JDK / Android / Chrome, avec des systèmes multi-serveurs et des API comme les services cloud?
Eh bien, j'ai tweeté à ce sujet hier, mais dans le style de succion / règle de Larry Wall, j'ai recherché le mot obsolète sur les sites de développement Google et Amazon. Bien qu'AWS propose des centaines de fois plus d'offres de services que GCP, la documentation pour les développeurs de Google mentionne la dépréciation environ sept fois plus souvent.
Si quelqu'un de Google lit ceci, alors il est probablement prêt à sortir des diagrammes montrant le style de Donald Trump qu'en fait, il fait tout correctement, et que je ne devrais pas faire de comparaisons injustes, telles que «le nombre de mentions du mot obsolète en fonction du nombre de services ".
Mais après tant d'années, Google Cloud est toujours n ° 3 (je n'ai jamais écrit d'article sur la tentative ratée de devenir n ° 2), mais si vous en croyez les initiés, il y a des inquiétudes qu'ils pourraient bientôt tomber au n ° 4.
Je n'ai rien de bon arguments pour «prouver» votre thèse. Tout ce que j'ai, ce sont des exemples colorés que j'ai accumulés en 30 ans en tant que développeur. J'ai déjà mentionné la nature profondément philosophique de ce problème; en un sens, il est politisé dans les communautés de développeurs. Certaines personnes pensent que les créateurs de plates - formes devraient se soucier de la compatibilité, tandis que d'autres pensent que c'est la préoccupation des 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 il y aura certainement des réponses de colère à mon discours.
En tant qu'utilisateur de la plate-forme cloud Google, ainsi qu'en tant qu'utilisateur AWS depuis deux ans (chez 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 ne se produit pas aussi souvent que dans Google. Et je crois vraiment que cette source de controverse et de frustration constante dans GCP est l'une des plus grandes contraintes sur 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 pratiquement tout ce que j'ai utilisé, de la mise en réseau (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), Cloud endpoints et avant ... Je ne sais pas - absolument toute cette réécriture forcée du code dans un maximum de 2-3 ans, et ils n'ont jamais automatisé la migration pour vous, et souvent il n'y avait aucun chemin de migration documenté . Comme si ça devait être.
Et chaque fois que je regarde AWS, je me demande pourquoi diable suis-je toujours assis sur GCP. Ils n'ont clairement pas besoin de clients. Ils veulent des acheteurs . Comprenez-vous la différence? Laisse-moi expliquer.
Google Cloud a un marché où les gens proposent leurs solutions logicielles, et pour éviter l'effet d'un restaurant vide, ils ont dû le remplir avec quelques suggestions, ils ont donc passé un contrat avec Bitnami pour créer un ensemble de solutions qui sont déployées "en un clic", ou Je dois écrire moi-même les «solutions», car elles ne résolvent rien. Ils n'existent que sous forme de drapeaux, de remplissage marketing, et Google ne s'est jamais soucié de savoir si l'un des outils fonctionnait réellement. Je connais des chefs de produit qui ont conduit, et je peux vous assurer que ces gens s'en moquent.
Prenons, par exemple, la solution de déploiement «en un clic» Percona... Je m'ennuyais à mort par les singeries de Google Cloud SQL, alors j'ai commencé à envisager de créer mon propre cluster Percona comme alternative. Et cette fois, Google semblait faire du bon travail, ils allaient me faire gagner du temps et des efforts d'un simple clic!
Eh bien, super, allons-y. Suivons le lien et appuyez sur ce bouton. Sélectionnez "Oui" pour accepter toutes les valeurs par défaut et déployer le cluster dans votre projet cloud Google. Haha, ça ne marche 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 cela ne me surprendrait pas si plus de la moitié des «solutions» pour les déploiements en un clic (maintenant nous comprenons pourquoi les citations) ne fonctionnent pas du tout. C'est une obscurité absolument désespérée, où il vaut mieux ne pas entrer.
Mais Google vous encourage explicitement à les utiliser. Ils veulent que vous les achetiez . 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 ont toujours été impitoyables en fermant tout service qui ne répond 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 cet ADN est derrière toutes les offres cloud. Ils ne cherchent à rien soutenir; il est bien connu qu'ils refusent d'héberger (en tant que service géré) tout logiciel tierstant qu'AWS ne fait pas la même chose et ne créera pas une entreprise prospère, et lorsque les clients en ont besoin. Cependant, il faut quelques efforts pour que Google prenne en charge quelque chose.
Ce manque de culture du support, couplé au principe «cassons-le pour le rendre beau», en éloigne les développeurs.
Et ce n'est pas bon si vous souhaitez créer une plate-forme durable.
Google se réveille, bon sang. C'est 2020. Vous êtes toujours en train de perdre. Il est temps de regarder de près dans le miroir et de répondre si vous voulez vraiment rester dans le cloud.
Si tu veux rester alors arrête de tout casser... Vous êtes riches. Nous, les développeurs, ne le sommes pas. Donc, quand 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 leur font signe.
Et maintenant je vais continuer à réparer tous mes systèmes cassés. Eh.
Jusqu'à la prochaine fois!
PS Update après avoir lu certaines des discussions de cet article (les discussions sont excellentes d'ailleurs). Firebase n'a pas été interrompu et il n'y a aucun plan à ma connaissance. Cependant, ils ont une erreur de streaming désagréable qui entraîne l'arrêt du client Java dans App Engine. Un de leurs ingénieurs m'a aidé à résoudre ce problème lorsque je travaillais chez Google, , , GAE. ! Firestore. , , , Firebase . ? , . , , Firebase GAE, 100 100% , - . , . Redis.
, AWS , AWS , SimpleDB — . , AWS , Google, , .
, , 20 Google App Engine Go, GAE Go. , .
, , ( , !). , , Google . , , AWS, Grab. - , !
, 2005 43, . 2006 . Bigtable 2007 .
Bigtable (-), . , , , , , .
, Apple Microsoft . . , , ! , , ?
.
2, 19.08.2020. Stripe API!
Mise à jour 3, 31/08/2020. J'ai été contacté par un ingénieur Google de Cloud Marketplace qui s'est avéré être un vieil ami à moi. Il voulait savoir pourquoi C2D ne fonctionne pas, et à la fin nous avons compris: la raison en est que j'ai créé mon réseau il y a plusieurs années, et C2D ne fonctionne pas sur les réseaux hérités en raison du paramètre de sous-réseau manquant dans leurs modèles. Je pense que les utilisateurs potentiels de GCP feraient mieux de s'assurer qu'ils disposent de suffisamment d'ingénieurs familiers chez Google ...