Verdammtes Google, ich wollte nicht noch einmal bloggen. Ich habe so viel zu tun. Bloggen braucht Zeit, Energie und Kreativität, die ich gut gebrauchen könnte: meine Bücher, , mein Spiel und so weiter. Aber du hast mich so sauer gemacht, dass ich das schreiben muss.
Also lasst uns das hinter uns bringen.
Lassen Sie mich mit einer kurzen, aber lehrreichen Geschichte beginnen, als ich anfing, bei Google zu arbeiten. Ich weiß, dass ich in letzter Zeit viel Schlechtes über Google gesagt habe, aber es ärgert mich, wenn mein eigenes Unternehmen regelmäßig inkompetente Geschäftsentscheidungen trifft. Gleichzeitig müssen wir ihm gerecht werden: Die interne Infrastruktur von Google ist wirklich außergewöhnlich, man kann mit Sicherheit sagen, dass es heute nichts Besseres gibt. Die Gründer von Google waren viel bessere Ingenieure als ich jemals sein werde, und diese Geschichte bestätigt diese Tatsache nur.
Zunächst ein kleiner Hintergrund: Google verfügt über eine Datenspeichertechnologie namens . Es war eine bemerkenswerte technische Errungenschaft, einer der ersten (wenn nicht der erste) „unendlich skalierbare“ Schlüsselwertspeicher (K/V): im Wesentlichen der Beginn von NoSQL. Heutzutage macht sich Bigtable immer noch gut im ziemlich überfüllten K/V-Speicherplatz, aber damals (2005) war es erstaunlich cool.
Eine lustige Sache an Bigtable ist, dass sie (als Teil der Implementierung) interne Steuerungsebenenobjekte hatten, sogenannte Tablet-Server, mit großen Indizes, und irgendwann wurden sie zu einem Engpass bei der Skalierung des Systems. Die Bigtable-Ingenieure rätselten, wie sie Skalierbarkeit implementieren könnten, und erkannten plötzlich, dass sie Tablet-Server durch andere Bigtable-Speicher ersetzen könnten. Bigtable ist also Teil der Bigtable-Implementierung. Diese Lagermöglichkeiten gibt es auf allen Ebenen.
Ein weiteres interessantes Detail ist, dass Bigtable eine Zeit lang bei Google populär und allgegenwärtig wurde und jedes Team über ein eigenes Repository verfügte. Bei einem der Freitagstreffen fragte Larry Page beiläufig: „Warum haben wir mehr als einen Bigtable?“ Warum nicht nur einer?“ Theoretisch sollte ein Speicher für den gesamten Speicherbedarf von Google ausreichen. Natürlich haben sie sich aus praktischen Entwicklungsgründen (etwa wegen der Folgen eines möglichen Scheiterns) nie nur für eines entschieden, aber die Theorie war interessant. Ein Repository für das gesamte Universum (Weiß übrigens jemand, ob Amazon das bei seinem Sable gemacht hat?)
Wie auch immer, hier ist meine Geschichte.
Damals arbeitete ich seit etwas mehr als zwei Jahren bei Google und eines Tages erhielt ich eine E-Mail vom Bigtable-Engineering-Team, die ungefähr so lautete:
Lieber steve,
Hallo vom Bigtable-Team. Wir möchten Sie darüber informieren, dass Sie bei [Name des Rechenzentrums] eine sehr, sehr alte Bigtable-Binärdatei verwenden. Diese Version wird nicht mehr unterstützt und wir möchten Ihnen beim Upgrade auf die neueste Version helfen.
Bitte lassen Sie mich wissen, ob Sie etwas Zeit für die Zusammenarbeit zu diesem Thema einplanen können.
Alles Gute,
Bigtable-Team
Bei Google bekommt man sehr viele Mails, daher habe ich auf den ersten Blick etwa Folgendes gelesen:
Sehr geehrter Empfänger,
Hallo von einem Team. Wir wollen das bla bla bla bla bla kommunizieren. Bla bla bla bla bla, und bla bla bla sofort.
Bitte lassen Sie uns wissen, ob Sie etwas von Ihrer kostbaren Zeit für bla bla bla einplanen können.
Alles Gute,
Eine Art Befehl
Ich hätte es fast sofort gelöscht, aber am Rande meines Bewusstseins verspürte ich ein schmerzhaftes, quälendes Gefühl nicht wirklich sieht allerdings wie ein formeller Brief aus offensichtlich, dass der Empfänger sich geirrt hat, weil ich Bigtable nicht verwendet habe.
Aber es war seltsam.
Den Rest des Tages verbrachte ich damit, abwechselnd über die Arbeit nachzudenken und darüber nachzudenken, welche Art von Haifischfleisch ich in der Mikroküche probieren sollte, von denen mindestens drei nahe genug waren, um sie mit einem gezielten Kekswurf von meinem Platz aus zu treffen, aber das Der Gedanke an das Schreiben löste bei mir nie ein wachsendes Gefühl leichter Angst aus.
Sie sagten deutlich meinen Namen. Und die E-Mail wurde an meine E-Mail-Adresse gesendet, nicht an die einer anderen Person, und sie lautet nicht cc: oder bcc:. Der Ton ist sehr persönlich und klar. Vielleicht ist das ein Fehler?
Schließlich überwältigte mich die Neugier und ich schaute mir die Borg-Konsole im erwähnten Rechenzentrum an.
Und natürlich verwaltete ich den BigTable-Speicher. Was was? Ich habe mir den Inhalt angeschaut und wow! Es stammte aus dem Codelab-Inkubator, in dem ich während meiner ersten Woche bei Google im Juni 2005 saß. Codelab hat Sie gezwungen, Bigtable auszuführen, um dort einige Werte zu schreiben, und ich habe den Speicher danach anscheinend nie mehr geschlossen. Es funktionierte immer noch, obwohl mehr als zwei Jahre vergangen waren.
Es gibt mehrere bemerkenswerte Aspekte dieser Geschichte. Erstens war die Arbeit von Bigtable im Vergleich zu Google so unbedeutend, dass erst zwei Jahre später jemand den zusätzlichen Speicher bemerkte, und zwar nur, weil die Version der Binärdatei veraltet war. Zum Vergleich habe ich einmal darüber nachgedacht, zu verwenden für mein Online-Spiel. Damals kostete dieser Service etwa 16 US-Dollar pro Jahr. leer Bigtable auf GCP. Ich sage nicht, dass sie dich betrügen, aber meiner persönlichen Meinung nach ist das eine Menge Geld für eine verdammt leere Datenbank.
Ein weiterer bemerkenswerter Aspekt ist die Lagerung Funktioniert nach zwei Jahren immer noch. WTF? Rechenzentren kommen und gehen; Es kommt zu Ausfällen, es werden planmäßige Wartungsarbeiten durchgeführt und sie ändern sich ständig. Hardware wird aktualisiert, Schalter getauscht, alles wird ständig verbessert. Wie zum Teufel konnten sie mein Programm trotz all dieser Änderungen zwei Jahre lang am Laufen halten? Im Jahr 2020 mag dies wie eine bescheidene Leistung erscheinen, in den Jahren 2005–2007 war sie jedoch recht beeindruckend.
Und das Schönste ist, dass ein externes Ingenieurteam in einem anderen Bundesstaat auf mich zukommt, der Besitzer einer winzigen, fast leeren Instanz von Bigtable, der es getan hat Null Verkehr seit zwei Jahren - und bieten Hilfe bei der Aktualisierung an.
Ich bedankte mich, löschte den Speicher und das Leben ging wie gewohnt weiter. Aber dreizehn Jahre später denke ich immer noch an diesen Brief. Denn manchmal erhalte ich ähnliche E-Mails von Google Cloud. Sie sehen so aus:
Lieber Google Cloud-Nutzer,
Zur Erinnerung: Wir werden den Dienst [wesentlicher Dienst, den Sie nutzen] ab August 2020 einstellen. Danach können Sie Ihre Instanzen nicht mehr aktualisieren. Wir empfehlen mit unserer freundlichen Hilfe ein Upgrade auf die neueste Version, die sich im Betatest befindet, keine Dokumentation hat, keinen Migrationspfad hat und vorab veraltet ist.
Wir setzen uns dafür ein, dass diese Änderung minimale Auswirkungen auf alle Nutzer der Google Cloud-Plattform hat.
Beste Freunde für immer,
Google Cloud-Plattform
Aber ich lese solche Briefe fast nie, denn eigentlich heißt es darin:
Sehr geehrter Empfänger,
Fahr zur Hölle. Fick dich, fick dich, fick dich. Lass alles fallen, was du tust, weil es keine Rolle spielt. Was zählt, ist unsere Zeit. Wir verschwenden Zeit und Geld damit, unseren Mist aufrechtzuerhalten, und weil wir ihn satt haben, unterstützen wir ihn nicht mehr. Also geben Sie Ihre verdammten Pläne auf und fangen Sie an, unsere beschissene Dokumentation durchzuwühlen und in den Foren um Fetzen zu betteln, und übrigens, unser neuer Scheiß ist völlig anders als der alte, weil wir dieses Design ziemlich vermasselt haben, heh, aber das ist Ihr Problem, nicht unser.
Wir bemühen uns weiterhin, sicherzustellen, dass alle Ihre Entwicklungen innerhalb eines Jahres unbrauchbar werden.
Bitte verpiss dich
Google Cloud-Plattform
Und Tatsache ist, dass ich solche Briefe etwa einmal im Monat erhalte. Das passiert so oft und so ständig, dass sie unweigerlich passieren weggestoßen mich von GCP ins Anti-Cloud-Lager. Ich bin nicht länger damit einverstanden, mich auf ihre proprietären Entwicklungen zu verlassen, denn tatsächlich ist es für Entwickler einfacher, ein Open-Source-System auf einer bloßen virtuellen Maschine zu warten, als zu versuchen, mit Google mit seiner Politik der Schließung „veralteter“ Produkte Schritt zu halten.
Bevor ich zu Google Cloud zurückkehre, weil ich ganz knapp Da wir mit der Kritik noch nicht fertig sind, werfen wir einen Blick auf die Leistung des Unternehmens in einigen anderen Bereichen. Google-Ingenieure sind stolz auf ihre Disziplin im Software-Engineering, und das ist es, was tatsächlich Probleme verursacht. Stolz ist eine Falle für Unvorsichtige und hat viele Google-Mitarbeiter zu der Annahme verleitet, dass ihre Entscheidungen immer richtig sind und dass es wichtiger ist, Recht zu haben (nach einer vagen undeutlichen Definition) als sich um die Kunden zu kümmern.
Ich werde einige zufällige Beispiele aus anderen großen Projekten außerhalb von Google nennen, aber ich hoffe, dass Sie dieses Muster überall sehen. Es ist wie folgt: Durch die Abwärtskompatibilität bleiben Systeme jahrzehntelang am Leben und auf dem neuesten Stand.
Abwärtskompatibilität ist das Designziel aller erfolgreichen Systeme, für die entwickelt wurde öffnen Nutzung, d. h. implementiert mit Open-Source-Code und/oder offenen Standards. Ich habe das Gefühl, dass ich etwas zu Offensichtliches sage, als dass es allen unangenehm wäre, aber nein. Da es sich hierbei um eine politische Angelegenheit handelt, sind Beispiele erforderlich.
Das erste System, das ich wählen werde, ist das älteste: GNU Emacs, eine Art Hybrid zwischen Windows Notepad, dem Betriebssystemkernel und der Internationalen Raumstation. Es ist ein wenig schwer zu erklären, aber kurz gesagt: Emacs ist eine Plattform, die 1976 (ja, vor fast einem halben Jahrhundert) für die Programmierung geschaffen wurde, um Sie produktiver zu machen, sich aber als Texteditor tarnt.
Ich benutze Emacs jeden Tag. Ja, ich verwende IntelliJ auch jeden Tag, es hat sich zu einer eigenständigen leistungsstarken Tooling-Plattform entwickelt. Das Schreiben von Erweiterungen für IntelliJ ist jedoch eine viel ehrgeizigere und komplexere Aufgabe als das Schreiben von Erweiterungen für Emacs. Und was noch wichtiger ist: Alles, was für Emacs geschrieben wurde, bleibt erhalten für immer.
Ich verwende immer noch die Software, die ich 1995 für Emacs geschrieben habe. Und ich bin sicher, dass jemand Module verwendet, die Mitte der 80er Jahre, wenn nicht sogar früher, für Emacs geschrieben wurden. Von Zeit zu Zeit müssen sie möglicherweise ein wenig angepasst werden, aber das kommt wirklich eher selten vor. Ich kenne nichts, was ich jemals für Emacs geschrieben habe (und ich habe viel geschrieben), was eine Neuarchitektur erforderte.
Emacs verfügt über eine Funktion namens make-obsolete für veraltete Entitäten. Die Emacs-Terminologie für grundlegende Computerkonzepte (z. B. was ein „Fenster“ ist) weicht häufig von Branchenkonventionen ab, da Emacs sie vor langer Zeit eingeführt hat. Das ist eine typische Gefahr für diejenigen, die ihrer Zeit voraus sind: Alle Ihre Begriffe sind falsch. Aber Emacs hat ein Konzept der Abwertung, das im Fachjargon so genannt wird Veralten.
Aber in der Emacs-Welt scheint es eine andere Arbeitsdefinition zu geben. Wenn Sie so wollen, eine andere Grundphilosophie.
В мире Emacs (и во многих других областях, которые мы рассмотрим ниже) статус устаревших API в основном означает: «Вы действительно не должны использовать этот подход, потому что, хотя он и работает, он страдает от различных недостатков, которые мы перечислим здесь. Но, в конце концов, это ваш выбор».
In der Welt von Google bedeutet veraltet zu sein: „Wir verstoßen gegen unsere Verpflichtung Ihnen gegenüber.“ Das ist tatsächlich so. Das ist es im Wesentlichen. Das bedeutet, dass sie dich zwingen werden regelmäßig Arbeit leisten, vielleicht sogar viel, als Strafe dafür, dass man an sie glaubt : Wir haben die beste Software. Das schnellste! Sie machen alles gemäß den Anweisungen, starten Ihre Anwendung oder Ihren Dienst und dann, bums, geht es nach ein oder zwei Jahren kaputt.
Es ist, als würde man einen Gebrauchtwagen verkaufen, der nach 1500 km definitiv eine Panne hat.
Dies sind zwei völlig unterschiedliche philosophische Definitionen von „Obsoleszenz“. Googles Definition von Geruch . Ich glaube das nicht tatsächlich geplante Obsoleszenz im gleichen Sinne wie Apple. Aber Google plant definitiv, Ihre Programme auf Umwegen zu zerstören. Ich weiß das, weil ich dort über 12 Jahre als Softwareentwickler gearbeitet habe. Sie haben vage interne Richtlinien dazu, wie viel Abwärtskompatibilität eingehalten werden sollte, aber letztendlich liegt es an jedem einzelnen Team oder Dienst. Es gibt keine Empfehlungen auf Unternehmens- oder Technikebene, und die kühnste Empfehlung in Bezug auf Obsoleszenzzyklen lautet: „Versuchen Sie, den Kunden 6 bis 12 Monate Zeit für ein Upgrade zu geben, bevor ihr gesamtes System kaputt geht.“
Das Problem ist viel größer, als sie denken, und es wird noch viele Jahre bestehen bleiben, weil Kundenbetreuung nicht in ihrer DNA liegt. Mehr dazu weiter unten.
An dieser Stelle werde ich die kühne Aussage treffen, dass Emacs weitgehend und sogar erfolgreich ist meistens weil sie die Abwärtskompatibilität so ernst nehmen. Eigentlich ist das die These unseres Artikels. Erfolgreiche, langlebige offene Systeme verdanken ihren Erfolg den Mikrogemeinschaften, die seit Jahrzehnten um sie herum leben Erweiterungen/Plugins. Das ist das Ökosystem. Ich habe bereits über die Natur von Plattformen und ihre Bedeutung gesprochen und darüber, dass Google in seiner gesamten Unternehmensgeschichte nie verstanden hat, was zur Schaffung einer erfolgreichen offenen Plattform außerhalb von Android oder Chrome gehört.
Eigentlich sollte ich Android kurz erwähnen, weil Sie wahrscheinlich darüber nachdenken.
Erstens, Android ist nicht Google. Sie haben fast nichts miteinander gemeinsam. Android ist ein Unternehmen, das im Juli 2005 von Google gekauft wurde. Das Unternehmen durfte mehr oder weniger autonom agieren und ist in der Tat in den vergangenen Jahren weitgehend unangetastet geblieben. Android ist ein berüchtigter Tech-Stack und eine ebenso berüchtigte heikle Organisation. Wie ein Google-Mitarbeiter es ausdrückte: „Man kann sich nicht einfach bei Android anmelden.“
In einem früheren Artikel habe ich darüber gesprochen, wie schlecht einige der frühen Designentscheidungen von Android waren. Verdammt, als ich diesen Artikel schrieb, brachten sie Mist namens „Instant-Apps“ auf den Markt, die jetzt (Überraschung!) , und ich verstehe es, wenn Sie dumm genug wären, auf Google zu hören und Ihre Inhalte in diese Instant-Apps zu verschieben.
Aber hier gibt es einen Unterschied, einen signifikanten Unterschied, nämlich dass die Android-Leute wirklich verstehen, wie wichtig Plattformen sind, und ihr Bestes geben, um alte Android-Apps am Laufen zu halten. Tatsächlich sind ihre Bemühungen, die Abwärtskompatibilität aufrechtzuerhalten, so extrem, dass sogar ich während meiner kurzen Tätigkeit in der Android-Abteilung vor ein paar Jahren versuchte, sie davon zu überzeugen, die Unterstützung für einige der ältesten Geräte und APIs einzustellen (ich habe mich geirrt). , wie es in vielen anderen Dingen der Vergangenheit und Gegenwart der Fall war. Tut mir leid, Android-Leute! Jetzt, wo ich in Indonesien war, verstehe ich, warum wir sie brauchen.
Die Android-Leute treiben die Abwärtskompatibilität auf fast unvorstellbare Extreme und häufen riesige Mengen an veralteten technischen Schulden in ihren Systemen und Toolchains an. Oh mein Gott, Sie sollten einige der verrückten Dinge sehen, die sie in ihrem Build-System tun müssen, alles im Namen der Kompatibilität.
Dafür vergebe ich Android die begehrte „You’re Not Google“-Auszeichnung. Sie wollen wirklich nicht zu Google werden, das nicht weiß, wie man dauerhafte Plattformen schafft, sondern zu Android weiß, wie es geht. Und so ist Google in einer Hinsicht sehr schlau: Es ermöglicht den Menschen, auf Android Dinge auf ihre eigene Art und Weise zu erledigen.
Allerdings waren Instant-Apps für Android eine ziemlich dumme Idee. Und wissen Sie warum? Weil sie es verlangten Schreiben und gestalten Sie Ihre Anwendung neu! Es ist, als ob die Leute einfach zwei Millionen Bewerbungen umschreiben würden. Ich vermute, Instant Apps war die Idee eines Google-Mitarbeiters.
Aber es gibt einen Unterschied. Die Abwärtskompatibilität ist mit hohen Kosten verbunden. Android selbst trägt die Last dieser Kosten, während Google darauf besteht, dass die Last getragen wird Sie, zahlender Kunde.
Sie können das Engagement von Android für Abwärtskompatibilität in seinen APIs erkennen. Wenn vier oder fünf verschiedene Subsysteme buchstäblich dasselbe tun, ist das ein sicheres Zeichen dafür, dass im Kern eine Verpflichtung zur Abwärtskompatibilität besteht. Was in der Welt der Plattformen ein Synonym für Engagement für Ihre Kunden und Ihren Markt ist.
Das Hauptproblem von Google ist hier der Stolz auf die technische Hygiene. Sie mögen es nicht, wenn es viele verschiedene Möglichkeiten gibt, dasselbe zu tun, und die alten, weniger wünschenswerten Wege neben den neuen, ausgefalleneren stehen. Es erhöht die Lernkurve für diejenigen, die neu im System sind, es erhöht den Aufwand für die Pflege älterer APIs, es verlangsamt die Geschwindigkeit neuer Funktionen und die Hauptsünde ist, dass es nicht schön ist. Google – wie Lady Ascot aus Tim Burtons Alice im Wunderland:
Lady Ascot:
- Alice, weißt du, wovor ich am meisten Angst habe?
- Der Niedergang der Aristokratie?
- Ich hatte Angst davor hässliche Enkelkinder.
Um den Kompromiss zwischen schön und praktisch zu verstehen, werfen wir einen Blick auf die dritte erfolgreiche Plattform (nach Emacs und Android) und sehen, wie sie funktioniert: Java selbst.
Java hat viele veraltete APIs. Die Ablehnung ist bei Java-Programmierern sehr beliebt, sogar noch beliebter als in den meisten Programmiersprachen. Java selbst, die Kernsprache und die Bibliotheken verwerfen APIs ständig.
Um nur eines von Tausenden Beispielen zu nennen: als veraltet angesehen. Es ist seit der Veröffentlichung von Java 1.2 im Dezember 1998 veraltet. Es ist 22 Jahre her, seit dies veraltet ist.
Aber mein eigentlicher Code in der Produktion beendet immer noch Threads täglich. Findest du das wirklich gut? Absolut! Ich meine, wenn ich den Code heute neu schreiben würde, würde ich ihn natürlich anders implementieren. Aber der Code für mein Spiel, das in den letzten zwei Jahrzehnten Hunderttausende Menschen glücklich gemacht hat, ist mit einer Funktion geschrieben, um Threads zu schließen, die zu lange hängen, und ich musste es nie ändern. Ich kenne mein System besser als jeder andere, ich habe buchstäblich 25 Jahre Erfahrung damit in der Produktion und kann mit Sicherheit sagen: In meinem Fall ist das Schließen dieser spezifischen Arbeitsthreads vollständig wertlos. Es ist die Zeit und Mühe nicht wert, diesen Code neu zu schreiben, und ich danke Larry Ellison (wahrscheinlich), dass Oracle mich nicht gezwungen hat, ihn neu zu schreiben.
Oracle versteht wahrscheinlich auch Plattformen. Wer weiß.
Beweise finden sich überall in den Kern-Java-APIs, die von Wellen der Veralterung durchzogen sind, wie die Linien eines Gletschers in einer Schlucht. In der Java Swing-Bibliothek finden Sie problemlos fünf oder sechs verschiedene Tastaturnavigationsmanager (KeyboardFocusManager). Es ist tatsächlich schwierig, eine Java-API zu finden, die nicht veraltet ist. Aber sie funktionieren immer noch! Ich denke, dass das Java-Team eine API nur dann wirklich entfernen wird, wenn die Schnittstelle ein eklatantes Sicherheitsproblem darstellt.
Hier ist die Sache, Leute: Wir Softwareentwickler sind alle sehr beschäftigt und in jedem Bereich der Software stehen wir vor konkurrierenden Alternativen. Programmierer in der Sprache X erwägen jederzeit die Sprache Y als möglichen Ersatz. Oh, du glaubst mir nicht? Möchten Sie es Swift nennen? Jeder migriert zu Swift und niemand gibt es auf, oder? Wow, wie wenig du weißt. Unternehmen zählen die Kosten für zwei mobile Entwicklungsteams (iOS und Android) – und beginnen zu erkennen, dass diese plattformübergreifenden Entwicklungssysteme mit lustigen Namen wie Flutter und React Native tatsächlich funktionieren und zur Reduzierung der Größe ihrer Teams verwendet werden können So können Sie mobile Teams verdoppeln oder umgekehrt doppelt so produktiv machen. Es steht echtes Geld auf dem Spiel. Ja, es gibt Kompromisse, aber andererseits auch Geld.
Nehmen wir hypothetisch an, dass Apple sich törichterweise an Guido van Rossum orientiert und erklärt hat, dass Swift 6.0 rückwärtsinkompatibel mit Swift 5.0 ist, ähnlich wie Python 3 mit Python 2 inkompatibel ist.
Ich habe diese Geschichte wahrscheinlich vor etwa zehn Jahren erzählt, aber vor etwa fünfzehn Jahren ging ich mit Guido zu O'Reilly's Foo Camp, saß mit Paul Graham und ein paar ganz Großen in einem Zelt. Wir saßen in der drückenden Hitze und warteten darauf, dass Larry Page mit seinem Privathelikopter abflog, während Guido über „Python 3000“ redete, das er nach der Anzahl der Jahre benannte, die es dauern würde, bis alle dorthin migrierten. Wir fragten ihn immer wieder, warum er die Kompatibilität verletzte, und er antwortete: „Unicode.“ Und wir fragten: Welche weiteren Vorteile würden wir sehen, wenn wir unseren Code neu schreiben müssten? Und er antwortete: „Yoooooooooooooouuuuuuuuuniiiiiiicoooooooode.“
Wenn Sie das Google Cloud Platform SDK („gcloud“) installieren, erhalten Sie die folgende Benachrichtigung:
Sehr geehrter Empfänger,
Wir möchten Sie daran erinnern, dass die Unterstützung für Python 2 eingestellt wurde, also ficken Sie
… usw. Kreis des Lebens.
Aber der Punkt ist, dass jeder Entwickler die Wahl hat. Und wenn man sie oft genug dazu zwingt, Code neu zu schreiben, denken sie vielleicht darüber nach andere Optionen. Sie sind nicht deine Geiseln, egal wie sehr du sie auch haben möchtest. Sie sind Ihre Gäste. Python ist immer noch eine sehr beliebte Programmiersprache, aber verdammt, Python 3(000) hat in sich selbst, in seinen Communities und unter den Benutzern seiner Communities ein solches Chaos angerichtet, dass die Folgen seit fünfzehn Jahren nicht geklärt werden konnten.
Wie viele Python-Programme wurden aufgrund dieser Abwärtsinkompatibilität in Go (oder Ruby oder einer anderen Alternative) neu geschrieben? Wie viel neue Software wurde in etwas anderem als Python geschrieben, obwohl es könnte sein in Python geschrieben, wenn Guido nicht das ganze Dorf niedergebrannt hätte? Das ist schwer zu sagen, aber Python hat eindeutig gelitten. Es ist ein riesiges Durcheinander und jeder verliert.
Nehmen wir also an, Apple orientiert sich an Guido und unterbricht die Kompatibilität. Was glaubst du wird als nächstes passieren? Nun, vielleicht werden 80–90 % der Entwickler ihre Software neu schreiben, wenn möglich. Mit anderen Worten, 10–20 % der Benutzerbasis wechseln automatisch zu einer konkurrierenden Sprache, wie z. B. Flutter.
Wenn Sie dies mehrmals tun, verlieren Sie die Hälfte Ihrer Benutzerbasis. Genau wie im Sport kommt es auch in der Welt des Programmierens auf die aktuelle Form an. alle. Jeder, der in fünf Jahren die Hälfte seiner Nutzer verliert, gilt als Big Fat Loser. Sie müssen in der Welt der Plattformen im Trend liegen. Aber hier wird es Sie mit der Zeit ruinieren, wenn Sie ältere Versionen nicht unterstützen. Denn jedes Mal, wenn Sie einige Entwickler loswerden, verlieren Sie sie (a) für immer, weil sie wütend auf Sie sind, weil Sie den Vertrag gebrochen haben, und (b) geben Sie sie an Ihre Konkurrenten ab.
Ironischerweise habe ich Google auch dabei geholfen, zu einer solchen Primadonna zu werden, die Abwärtskompatibilität ignoriert, als ich Grok erstellt habe, ein System zur Analyse und zum Verständnis von Quellcode, das es einfach macht, den Code selbst zu automatisieren und zu instrumentieren – ähnlich einer IDE, aber hier speichert der Cloud-Dienst materialisierte Darstellungen aller Milliarden Zeilen des Google-Quellcodes in einem großen Data Warehouse.
Grok stellte Google-Mitarbeitern ein leistungsstarkes Framework für die Durchführung automatisierter Refactorings in ihrer gesamten Codebasis (im wahrsten Sinne des Wortes Google) zur Verfügung. Das System berechnet nicht nur Ihre Upstream-Abhängigkeiten (von denen Sie abhängig sind), sondern auch absteigend (was Ihnen überlassen bleibt) Wenn Sie also APIs ändern, wissen Sie, wer Sie kaputt machen! Auf diese Weise können Sie bei Änderungen überprüfen, ob jeder Verbraucher Ihrer API auf die neue Version aktualisiert hat, und in der Realität können Sie den Prozess oft mit dem von ihnen geschriebenen Rosie-Tool vollständig automatisieren.
Dadurch kann die Codebasis von Google intern fast übernatürlich sauber sein, da diese Roboterdiener durch das Haus huschen und automatisch alles aufräumen, wenn sie „SomeDespicablyLongFunctionName“ in „SomeDespicablyLongMethodName“ umbenennen, weil jemand zu dem Schluss kommt, dass es sich um ein hässliches Enkelkind handelt und es eingeschläfert werden muss.
Und ehrlich gesagt funktioniert es für Google ziemlich gut ... intern. Ich meine, ja, die Go-Community bei Google hat viel Spaß mit der Java-Community bei Google, weil sie die Angewohnheit hat, kontinuierlich umzugestalten. Wenn Sie etwas N-mal neu starten, bedeutet das, dass Sie es nicht nur N-1 Mal vermasselt haben, sondern nach einer Weile wird ziemlich klar, dass Sie es wahrscheinlich auch beim N-ten Versuch vermasselt haben. Aber im Großen und Ganzen bleiben sie über all diese Aufregung erhaben und halten den Code „sauber“.
Das Problem beginnt, wenn sie versuchen, ihren Cloud-Clients und Benutzern anderer APIs diese Einstellung aufzuzwingen.
Ich habe Ihnen Emacs, Android und Java ein wenig vorgestellt; Schauen wir uns die neueste erfolgreiche und langlebige Plattform an: das Web selbst. Können Sie sich vorstellen, wie viele Iterationen HTTP seit 1995 durchlaufen hat, als wir blinkende Tags verwendeten? und „Im Aufbau“-Symbole auf Webseiten.
Aber es funktioniert immer noch! Und diese Seiten funktionieren immer noch! Ja, Leute, Browser sind die Weltmeister in Sachen Abwärtskompatibilität. Chrome ist ein weiteres Beispiel für die seltene Google-Plattform, deren Köpfe richtig verschraubt sind, und wie Sie vielleicht schon erraten haben, agiert Chrome praktisch als ein vom Rest von Google getrenntes Sandbox-Unternehmen.
Ich möchte auch unseren Freunden bei den Betriebssystementwicklern danken: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD usw., die auf ihren erfolgreichen Plattformen eine so großartige Arbeit in Bezug auf die Abwärtskompatibilität geleistet haben (Apple erhält bestenfalls ein C mit dem Der Nachteil ist, dass sie ständig alles ohne guten Grund kaputt machen, aber irgendwie kommt die Community mit jeder Veröffentlichung darum herum und OS
Aber warte, sagst du. Vergleichen wir nicht Äpfel mit Birnen – eigenständige Softwaresysteme auf einem einzigen Computer wie Emacs/JDK/Android/Chrome im Vergleich zu Systemen mit mehreren Servern und APIs wie Cloud-Diensten?
Nun, ich habe gestern darüber getwittert, aber im Stil von Larry Wall (Schöpfer der Programmiersprache Perl – ca. per.) nach dem Prinzip „sucks/rules“ habe ich das Wort nachgeschlagen veraltet auf den Entwicklerseiten von Google und Amazon. Und obwohl AWS es getan hat geh runter Obwohl es zwar mehr Serviceangebote gibt als bei GCP, wird in der Entwicklerdokumentation von Google etwa siebenmal häufiger von einer veralteten Funktion gesprochen.
Wenn jemand bei Google dies liest, ist er wahrscheinlich bereit, Diagramme im Stil von Donald Trump herauszuholen, die zeigen, dass er tatsächlich alles richtig macht und dass ich keine unfairen Vergleiche anstellen sollte wie „Anzahl der Erwähnungen des Wortes „veraltet“ im Vergleich zu „ Anzahl der Dienste" "
Aber nach all den Jahren ist Google Cloud immer noch der Dienst Nr. 3 (ich habe nie einen Artikel über den gescheiterten Versuch geschrieben, Nr. 2 zu werden), aber wenn man Insidern Glauben schenken darf, gibt es einige Bedenken, denen sie bald nachgeben könnten Nummer 4.
Ich habe keine zwingenden Argumente, um meine These zu „beweisen“. Alles, was ich habe, sind die farbenfrohen Beispiele, die ich in 30 Jahren als Entwickler gesammelt habe. Ich habe bereits die zutiefst philosophische Natur dieses Problems erwähnt; In gewisser Weise wird es in Entwicklergemeinschaften politisiert. Manche glauben das Schöpfer Plattformen sollten sich um die Kompatibilität kümmern, während andere denken, dass dies ein Problem darstellt Benutzer (die Entwickler selbst). Einer von zweien. Ist es nicht eine politische Frage, wenn wir darüber entscheiden, wer die Kosten gemeinsamer Probleme tragen soll?
Das ist also Politik. Und es wird wahrscheinlich verärgerte Reaktionen auf meine Rede geben.
Как Benutzer Google Cloud Platform und als AWS-Benutzer seit zwei Jahren (während meiner Arbeit für Grab) kann ich sagen, dass es einen großen Unterschied zwischen den Philosophien von Amazon und Google gibt, wenn es um Prioritäten geht. Ich entwickle nicht aktiv auf AWS, daher weiß ich nicht genau, wie oft alte APIs entfernt werden. Es besteht jedoch der Verdacht, dass dies bei weitem nicht so häufig vorkommt wie bei Google. Und ich bin fest davon überzeugt, dass diese Quelle ständiger Kontroversen und Frustration bei GCP einer der größten Faktoren ist, die die Entwicklung der Plattform behindern.
Ich weiß, dass ich keine konkreten Beispiele für GCP-Systeme genannt habe, die nicht mehr unterstützt werden. Ich kann sagen, dass fast alles, was ich verwendet habe, von Netzwerken (von den ältesten bis zu VPC) über Speicher (Cloud SQL v1-v2), Firebase (jetzt Firestore mit einer völlig anderen API), App Engine (fangen wir gar nicht erst an) , Cloud-Endpunkte Cloud Endpoint und bis zu ... Ich weiß nicht - absolut alles davon hat Sie gezwungen, den Code nach maximal 2-3 Jahren neu zu schreiben, und sie haben die Migration nie und oft für Sie automatisiert . Als ob es so sein sollte.
Und jedes Mal, wenn ich mir AWS ansehe, frage ich mich, warum zum Teufel ich immer noch auf GCP bin. Sie brauchen offensichtlich keine Kunden. Sie brauchen Käufer. Verstehen Sie den Unterschied? Lassen Sie mich erklären.
Google Cloud hat , wo Leute ihre Softwarelösungen vorschlagen, und um den leeren Restauranteffekt zu vermeiden, mussten sie es mit einigen Vorschlägen füllen, also schlossen sie einen Vertrag mit einem Unternehmen namens Bitnami ab, um eine Reihe von Lösungen zu entwickeln, die mit „einem Klick“ bereitgestellt werden oder sollten Ich schreibe es selbst als „Lösungen“, weil diese überhaupt nichts lösen. Sie existieren lediglich als Kontrollkästchen, als Marketingfüller, und Google hat sich nie darum gekümmert, ob eines der Tools tatsächlich funktioniert. Ich kenne Produktmanager, die das Sagen hatten, und ich kann Ihnen versichern, dass es diesen Leuten egal ist.
Nehmen Sie zum Beispiel eine vermeintliche „One-Click“-Bereitstellungslösung. . Ich hatte die Nase voll von Google Cloud SQL-Spielereien und begann, als Alternative über den Aufbau meines eigenen Percona-Clusters nachzudenken. Und dieses Mal schien Google gute Arbeit geleistet zu haben, sie würden mir mit einem Klick Zeit und Mühe ersparen!
Na toll, lass uns gehen. Folgen wir dem Link und klicken Sie auf diese Schaltfläche. Wählen Sie „Ja“, um allen Standardeinstellungen zuzustimmen und den Cluster in Ihrem Google Cloud-Projekt bereitzustellen. Haha, es funktioniert nicht. Nichts von diesem Mist funktioniert. Das Tool wurde nie getestet und begann von der ersten Minute an zu verrotten, und es würde mich nicht überraschen, wenn mehr als die Hälfte der „Lösungen“ Ein-Klick-Bereitstellungen wären (jetzt verstehen wir, warum die Zitate) im Allgemeinen arbeiten nicht. Das ist absolut hoffnungslose Dunkelheit, in die man besser nicht eintreten sollte.
Aber Google hat Recht Trieben Sie, sie zu benutzen. Sie wollen, dass du es tust gekauft. Für sie ist es eine Transaktion. Sie wollen nichts zu unterstützen. Es ist nicht Teil der DNA von Google. Ja, Ingenieure unterstützen sich gegenseitig, wie meine Geschichte mit Bigtable zeigt. Aber in Produkten und Dienstleistungen für normale Menschen immer waren rücksichtslos , das die Rentabilitätsanforderungen nicht erfüllt, selbst wenn es Millionen von Benutzern hat.
Und das stellt eine echte Herausforderung für GCP dar, denn das ist die DNA hinter allen Cloud-Angeboten. Sie versuchen nicht, irgendetwas zu unterstützen; Es ist bekannt, dass sie sich weigern, Software von Drittanbietern zu hosten (als Managed Service). bis dahin, bis AWS dasselbe tut und darauf aufbauend ein erfolgreiches Geschäft aufbaut, und wenn Kunden buchstäblich dasselbe verlangen. Allerdings ist es mit einigem Aufwand verbunden, Google dazu zu bringen, etwas zu unterstützen.
Dieser Mangel an Supportkultur, gepaart mit der „Lasst es uns kaputt machen, um es schöner zu machen“-Mentalität entfremdet Entwickler.
Und das ist keine gute Sache, wenn Sie eine langlebige Plattform aufbauen möchten.
Google, wach auf, verdammt. Es ist jetzt 2020. Du verlierst immer noch. Es ist Zeit, einen genauen Blick in den Spiegel zu werfen und zu beantworten, ob Sie wirklich im Cloud-Geschäft bleiben wollen.
Wenn du bleiben willst, dann Hör auf, alles kaputt zu machen. Leute, ihr seid reich. Wir Entwickler nicht. Wenn es also darum geht, wer die Last der Kompatibilität trägt, müssen Sie die Verantwortung dafür übernehmen. Nicht für uns.
Denn es gibt noch mindestens drei weitere richtig gute Wolken. Sie winken.
Und jetzt werde ich damit fortfahren, alle meine kaputten Systeme zu reparieren. Äh.
Bis zum nächsten Mal!
PS Update, nachdem ich einige Diskussionen zu diesem Artikel gelesen habe (die Diskussionen sind übrigens großartig). Der Firebase-Support wurde nicht eingestellt und es gibt keine Pläne, die mir bekannt sind. Sie haben jedoch einen schlimmen Streaming-Fehler, der dazu führt, dass der Java-Client in App Engine blockiert. Einer ihrer Ingenieure hat mir geholfen, dieses Problem zu lösen. als ich bei Google arbeitete, aber sie haben den Fehler nie wirklich behoben, daher habe ich eine beschissene Problemumgehung, indem ich die GAE-App jeden Tag neu starten muss. Und das schon seit vier Jahren! Sie haben jetzt Firestore. Die Migration darauf wird viel Arbeit erfordern, da es sich um ein völlig anderes System handelt und der Firebase-Fehler nie behoben wird. Welche Schlussfolgerung lässt sich ziehen? Sie können Hilfe bekommen wenn Sie in einem Unternehmen arbeiten. Ich bin wahrscheinlich der Einzige, der Firebase auf GAE verwendet, weil ich weniger als 100 Schlüssel in einer 100 % nativen App protokolliere und sie aufgrund eines bekannten Fehlers alle paar Tage nicht mehr funktioniert. Was kann ich anderes sagen, als es auf eigene Gefahr zu verwenden? Ich wechsle zu Redis.
Ich habe auch einige erfahrenere AWS-Benutzer sagen sehen, dass AWS normalerweise nie aufhört, Dienste zu unterstützen, und SimpleDB ist ein großartiges Beispiel. Meine Annahmen, dass AWS nicht die gleiche End-of-Support-Krankheit hat wie Google, scheinen berechtigt zu sein.
Außerdem ist mir aufgefallen, dass das Google App Engine-Team vor 20 Tagen das Hosting einer kritischen Go-Bibliothek unterbrochen hat, indem es eine GAE-Anwendung von einem der wichtigsten Go-Entwickler heruntergefahren hat. Es war wirklich dumm.
Schließlich habe ich gehört, dass Google-Mitarbeiter dieses Thema bereits diskutiert haben und mir im Allgemeinen zustimmen (ich liebe euch!). Aber sie scheinen zu glauben, dass das Problem unlösbar ist, weil die Kultur von Google nie über die richtige Anreizstruktur verfügte. Ich dachte, es wäre gut, sich etwas Zeit zu nehmen, um über die absolut erstaunliche Erfahrung zu sprechen, die ich während meiner Zeit bei Grab bei der Zusammenarbeit mit AWS-Ingenieuren gemacht habe. Irgendwann in der Zukunft, hoffe ich!
Und ja, 2005 gab es auf dem riesigen Buffet im Gebäude 43 tatsächlich verschiedene Arten von Haifleisch, und mein Favorit war das Hammerhaifleisch. Bis 2006 haben Larry und Sergei jedoch alle ungesunden Snacks abgeschafft. Während der Bigtable-Geschichte im Jahr 2007 gab es also wirklich keine Haie und ich habe Sie getäuscht.
Als ich mir vor vier Jahren Cloud Bigtable ansah (mehr oder weniger), waren hier die Kosten. Mittlerweile scheint es etwas gesunken zu sein, aber das ist immer noch sehr viel für ein leeres Data Warehouse, zumal meine erste Geschichte zeigt, wie belanglos eine leere große Tabelle in ihrem Maßstab ist.
Tut mir leid, dass ich die Apple-Community beleidigt habe und nichts Nettes über Microsoft usw. gesagt habe. Alles in Ordnung, ich schätze die Diskussion, die dieser Artikel ausgelöst hat, wirklich! Aber manchmal muss man ein wenig Aufsehen erregen, um eine Diskussion anzustoßen, verstehen Sie?
Danke fürs Lesen.
Update 2, 19.08.2020. Streifen !
Update 3, 31.08.2020. Ich wurde von einem Google-Ingenieur bei Cloud Marketplace kontaktiert, der sich als alter Freund von mir herausstellte. Er wollte herausfinden, warum C2D nicht funktionierte, und schließlich fanden wir heraus, dass es daran lag, dass ich mein Netzwerk vor Jahren aufgebaut hatte und C2D in älteren Netzwerken nicht funktionierte, weil der Subnetzparameter in deren Vorlagen fehlte. Ich denke, dass es für potenzielle GCP-Nutzer am besten ist, sicherzustellen, dass sie genügend Ingenieure bei Google kennen ...
Source: habr.com