Verdammtes Google, ich wollte nicht schon wieder einen Blogbeitrag schreiben. Ich habe so viel zu erledigen. Bloggen erfordert Zeit, Energie und Kreativität, die ich sinnvoll nutzen könnte: meine Bücher, , mein Spiel und so weiter. Aber du hast mich genug verärgert, und ich muss das jetzt schreiben.
Also lass uns damit aufhören.
Ich beginne mit einer kleinen, aber lehrreichen Geschichte aus der Zeit, als ich bei Google anfing zu arbeiten. Ich weiß, dass ich in letzter Zeit viel Schlechtes über Google gesagt habe, aber es frustriert mich, wenn mein eigenes Unternehmen regelmäßig inkompetente Geschäftsentscheidungen trifft. Dabei muss man anerkennen: Die interne Infrastruktur von Google ist wirklich außergewöhnlich, man kann mit Fug und Recht behaupten, 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 nur diese Tatsache.
Zunächst ein wenig Hintergrund: Google hat eine Datenspeichertechnologie namens . Das war ein bemerkenswerter technischer Fortschritt, eines der ersten (wenn nicht das erste) "unendlich skalierbare" Key-Value-Store: im Grunde der Beginn von NoSQL. Heutzutage ist Bigtable immer noch gut im recht überfüllten K/V-Speicherbereich platziert, aber damals (im Jahr 2005) war es einfach unglaublich cool.
Ein lustiges Detail über Bigtable ist, dass sie interne Objekte der Steuerungsebene (als Teil der Implementierung) hatten, die tablet-Server genannt wurden, mit großen Indizes, und irgendwann wurden sie zum Engpass bei der Skalierung des Systems. Die Ingenieure von Bigtable überlegten, wie sie Skalierbarkeit umsetzen können, und plötzlich erkannten sie, dass sie die tablet-Server durch andere Bigtable-Speicher ersetzen könnten. Also ist Bigtable ein Teil der Implementierung von Bigtable. Diese Speicher sind auf allen Ebenen vorhanden.
Ein weiteres interessantes Detail ist, dass Bigtable für eine Zeit innerhalb von Google sehr populär und allgegenwärtig wurde, und jedes Team sein eigenes Speicher hatte. Daher fragte Larry Page während eines der Freitagstreffen beiläufig: „Warum haben wir mehr als ein Bigtable? Warum nicht nur eines?“ Theoretisch hätte ein Speicher ausreichen sollen, um alle Speicheranforderungen von Google zu erfüllen. Natürlich wechselten sie niemals nur zu einem aus praktischen Entwicklungsgründen (zum Beispiel aufgrund der möglichen Folgen eines Ausfalls), aber die Theorie war interessant. Ein Speicher für das gesamte Universum (übrigens, weiß jemand, ob Amazon so etwas mit seinem Sable gemacht hat?)
Wie dem auch sei, hier ist meine Geschichte.
Zu diesem Zeitpunkt arbeitete ich seit etwas mehr als zwei Jahren bei Google, und eines Tages erhielt ich eine E-Mail von dem Ingenieurteam von Bigtable mit folgendem Inhalt:
Sehr geehrter Steve,
Grüße vom Bigtable-Team. Wir möchten Ihnen mitteilen, dass Sie im Rechenzentrum [название дата-центра] eine sehr, sehr alte Binärdatei von Bigtable verwenden. Diese Version wird nicht mehr unterstützt, und wir möchten Ihnen helfen, auf die neueste Version zu wechseln.
Bitte lassen Sie uns wissen, ob Sie etwas Zeit für die gemeinsame Arbeit an diesem Thema einplanen können.
Alles Gute,
Das Bigtable-Team
Bei Google erhält man viele E-Mails, daher las ich beim ersten Blick etwa Folgendes:
Sehr geehrter Empfänger,
Grüße von einem Team. Wir möchten Ihnen mitteilen, dass blablabla. Blablabla, und blablabla sofort.
Bitte lassen Sie uns wissen, ob Sie bereit sind, etwas Ihrer kostbaren Zeit für blablabla einzuplanen.
Alles Gute,
Irgendein Team
Ich war kurz davor, es sofort zu löschen, aber am Rande meines Bewusstseins verspürte ich ein drängendes, nagendes Gefühl, dass dies nicht ganz wie ein formeller Brief anmutete, obwohl offensichtlichdie Adresse falsch war, da ich Bigtable nicht benutzt habe.
Aber es war seltsam.
Den Rest des Tages dachte ich abwechselnd an die Arbeit und daran, welches Haifischfleisch ich in der Mikroküche probieren sollte, von denen mindestens drei nah genug waren, um sie mit einem gezielten Wurf eines Kekses von meinem Platz aus zu erreichen, aber der Gedanke an die E-Mail ließ mich mit einem wachsenden Gefühl leichter Besorgnis nicht los.
Sie haben offensichtlich meinen Namen genannt. Und der Brief wurde an meine E-Mail-Adresse gesendet, nicht an jemand anderen, und es ist kein 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 ging, um die Borg-Konsole im Rechenzentrum zu sehen, das sie erwähnt hatten.
Und natürlich hatte ich ein BigTable-Repository in meiner Verwaltung. Was? Ich sah mir seinen Inhalt an und – wow! Es war aus dem Codelab-Inkubator, in dem ich die erste Woche meiner Arbeit bei Google im Juni 2005 verbracht hatte. Codelab zwang dich, Bigtable zu starten, damit du einige Werte dorthin schreibst, und anscheinend habe ich das Repository danach nicht geschlossen. Es lief immer noch, obwohl mehr als zwei Jahre vergangen waren.
In dieser Geschichte gibt es einige bemerkenswerte Aspekte. Erstens war die Arbeit mit Bigtable im Maßstab von Google so unbedeutend, dass nur zwei Jahre später jemand das überflüssige Repository bemerkte, und das nur, weil die Binärversion veraltet war. Zum Vergleich: Ich hatte einmal in Erwägung gezogen, für mein Online-Spiel zu nutzen. Zu dieser Zeit kostete dieser Dienst etwa 16.000 $ pro Jahr für leeres Bigtable auf GCP. Ich sage nicht, dass sie Sie betrügen, aber meiner persönlichen Meinung nach ist das eine große Menge Geld für eine leere verdammte Datenbank.
Ein weiterer bemerkenswerter Aspekt ist, dass das Repository nach zwei Jahren immer noch lief.. WTF? Rechenzentren kommen und gehen; sie haben Ausfälle, sie durchlaufen geplante Wartungsarbeiten, sie ändern sich ständig. Die Hardware wird aktualisiert, die Switches werden ersetzt, alles wird kontinuierlich verbessert. Wie zur Hölle haben sie es geschafft, mein Programm zwei Jahre lang am Laufen zu halten, angesichts all dieser Veränderungen? Das mag 2020 wie eine bescheidene Leistung erscheinen, aber von 2005 bis 2007 war es ziemlich beeindruckend.
Und der bemerkenswerteste Aspekt ist, dass ein externes Ingenieurteam aus einem anderen Bundesstaat sich an mich wendet, den Besitzer eines winzigen, praktisch leeren Bigtable-Exemplars mit null Verkehr in den letzten zwei Jahren – und Hilfe anbietet, um es zu aktualisieren.
Ich habe ihnen gedankt, das Repository gelöscht, und das Leben ging weiter. Aber dreizehn Jahre später denke ich immer noch an diesen Brief. Denn manchmal bekomme ich ähnliche Briefe von Google Cloud. Sie sehen so aus:
Sehr geehrter Google Cloud-Nutzer,
Wir möchten Sie daran erinnern, dass wir den Service [wichtiger Service, den Sie verwenden] ab August 2020 einstellen werden, wonach Sie Ihre Instanzen nicht mehr aktualisieren können. Wir empfehlen, auf die neueste Version umzusteigen, die sich in der Beta-Phase befindet, keine Dokumentation hat, keinen Migrationspfad und die im Voraus veraltet ist, mit unserer freundlichen Unterstützung.
Wir sind bestrebt, sicherzustellen, dass diese Änderung minimale Auswirkungen auf alle Nutzer der Google Cloud-Plattform hat.
Freunde für immer,
Google Cloud-Plattform
Aber ich lese solche E-Mails fast nie, weil sie in Wirklichkeit Folgendes sagen:
Sehr geehrter Empfänger,
Geh zur Hölle. Geh, geh, geh. Lass alles, was du tust, los, denn es ist nicht wichtig. Was wichtig ist, ist unsere Zeit. Wir verbringen Zeit und Geld, um unseren Mist zu unterstützen, und wir sind es leid, also werden wir ihn nicht mehr unterstützen. Also lass deine verdammten Pläne hinter dir und fang an, in unserer beschissenen Dokumentation zu stöbern und in Foren um Reste zu betteln, und übrigens, unser neuer Mist sieht völlig anders aus als der alte Mist, weil wir dieses Design ziemlich ruiniert haben, hehe, aber das ist dein Problem, nicht unseres.
Wir bemühen uns weiterhin, dass all deine Entwicklungen innerhalb eines Jahres unbrauchbar werden.
Bitte geh weg,
Google Cloud-Plattform
Und das Ding ist, dass ich solche E-Mails etwa einmal im Monat erhalte. Das passiert so häufig und so konstant, dass sie unvermeidlich mich entfremdet haben von GCP in das Lager der Cloud-Gegner. Ich stimme nicht länger zu, von ihren proprietären Entwicklungen abhängig zu sein, denn es ist für DevOps in der Tat einfacher, ein Open-Source-System auf einer nackten virtuellen Maschine zu warten, als zu versuchen, mit Google und seiner Politik, "veraltete" Produkte abzulehnen, Schritt zu halten.
Bevor ich zu Google Cloud zurückkehre, weil ich es nicht einmal in der Nähe habe Ich habe nicht damit aufgehört, sie zu kritisieren, sehen wir uns die Arbeit des Unternehmens in anderen Bereichen an. Die Ingenieure von Google sind stolz auf ihre Disziplin bei der Softwareentwicklung, und genau das ist tatsächlich problematisch. Stolz ist eine Falle für die Unvorsichtigen; er hat viele Mitarbeiter von Google dazu gebracht, zu glauben, dass ihre Entscheidungen immer richtig sind und dass Richtigkeit (nach einer vagen, undefinierten Definition) wichtiger ist als die Sorge um die Kunden.
Ich werde einige willkürliche Beispiele aus anderen großen Projekten außerhalb von Google anführen, aber ich hoffe, Sie erkennen dieses Muster überall. Es besteht in Folgendem: Die Rückwärtskompatibilität sichert die Lebensdauer und Relevanz von Systemen über Jahrzehnte..
Rückwärtskompatibilität ist das Ziel beim Design aller erfolgreichen Systeme, die vorgesehen sind für öffentliche Nutzung, das heißt, sie sind mit Open-Source-Software und/oder offenen Standards realisiert. Ich habe das Gefühl, dass ich etwas sage, das zu offensichtlich ist, dass es jedem unangenehm ist, aber das ist es nicht. Es ist eine politische Frage, daher sind Beispiele erforderlich.
Das erste System, das ich wählen werde, ist das älteste: GNU Emacs, eine Art Hybrid zwischen dem Windows-Notizblock, dem Betriebssystem-Kernel und der Internationalen Raumstation. Es ist etwas kompliziert zu erklären, aber kurz gesagt, Emacs ist eine Plattform, die 1976 (ja, vor fast einem halben Jahrhundert) zum Programmieren entwickelt wurde, um Ihre Produktivität zu steigern, sich jedoch als Texteditor maskiert.
Ich benutze Emacs jeden Tag. Ja, ich benutze auch IntelliJ jeden Tag; es hat sich bereits zu einer leistungsstarken Werkzeugplattform verwandelt. Aber Erweiterungen für IntelliJ zu schreiben, ist eine viel ambitioniertere und kompliziertere Aufgabe als das Schreiben von Erweiterungen für Emacs. Und was noch wichtiger ist, alles, was für Emacs geschrieben wurde, bleibt ewig..
Ich benutze immer noch Software, die ich 1995 für Emacs geschrieben habe. Und ich bin mir sicher, dass es Leute gibt, die Module verwenden, die in den 80er Jahren für Emacs geschrieben wurden, wenn nicht sogar früher. Gelegentlich benötigen sie möglicherweise kleine Anpassungen, aber das passiert wirklich sehr selten. Ich kenne nichts, was ich jemals für Emacs geschrieben habe (und ich habe viel geschrieben), bei dem die Architektur neu aufgebaut werden müsste.
In Emacs gibt es eine Funktion namens make-obsolete für veraltete Entitäten. Die Terminologie von Emacs für grundlegende Computer-Konzepte (wie z.B. was ein „Fenster“ ist) weicht oft von branchenspezifischen Konventionen ab, da Emacs sie schon sehr lange eingeführt hat. Das ist eine typische Gefahr für diejenigen, die ihrer Zeit voraus sind: Alle Ihre Begriffe sind nicht korrekt. Aber in Emacs gibt es tatsächlich das Konzept der Veralterung, das in ihrer Fachsprache genannt wird obsolescence.
Aber in der Welt von Emacs scheint es eine andere Arbeitsdefinition zu geben. Eine andere grundlegende Philosophie, wenn Sie so wollen.
In der Welt von Emacs (und in vielen anderen Bereichen, die wir gleich betrachten werden) bedeutet der Status veralteter APIs im Wesentlichen: „Sie sollten diese Methode wirklich nicht verwenden, denn obwohl sie funktioniert, leidet sie unter verschiedenen Nachteilen, die wir hier auflisten werden. Aber letztendlich liegt es an Ihnen.“
In der Welt von Google bedeutet der Status eines veralteten Produkts: „Wir brechen unsere Verpflichtungen Ihnen gegenüber.“ Das ist wirklich so. Das ist die Essenz dessen, was es bedeutet. Es bedeutet, dass sie Sie regelmäßig eine Menge Arbeit machen lassen, vielleicht große Arbeit, als Strafe dafür, dass Sie an ihre : Wir haben die beste Software. Die schnellste! Sie folgen den Anweisungen, starten Ihre Anwendung oder Ihren Dienst, und dann – bumm, nach einem Jahr oder zwei bricht es zusammen.
Das ist so, als würde man ein gebrauchtes Auto verkaufen, das sicher innerhalb von 1500 km kaputt geht.
Das sind zwei ganz unterschiedliche philosophische Definitionen von „Veralterung“. Die Definition von Google riecht nach . Ich glaube nicht, dass das wirklich geplante Obsoleszenz im gleichen Sinne ist wie bei Apple. Aber Google plant definitiv, Ihre Programme auf indirekte Weise kaputt zu machen. Ich weiß das, weil ich dort über 12 Jahre als Software-Ingenieur gearbeitet habe. Sie haben vage interne Richtlinien, wie weit man mit der Rückwärtskompatibilität gehen sollte, aber letztendlich liegt es an jedem einzelnen Team oder Dienst. Es gibt keine Empfehlungen auf Unternehmens- oder Ingenieurebene, und die kühne Empfehlung aus Sicht der Veralterungszyklen ist: „Versuchen Sie, den Kunden 6-12 Monate Zeit zu geben, um ein Update durchzuführen, bevor Sie ihr gesamtes System kaputt machen.“
Das Problem ist viel ernster, als sie denken, und es wird noch viele Jahre bestehen bleiben, da die Kundenpflege nicht in ihrer DNA verankert ist. Mehr dazu siehe unten.
Im Moment wage ich die kühne Behauptung, dass Emacs in hohem Maße und sogar hauptsächlich erfolgreich ist, weil sie die Abwärtskompatibilität so ernst nehmen. Das ist im Grunde die These unseres Artikels. Erfolgreiche, langlebige offene Systeme verdanken ihren Erfolg den Mikro-Communities, die jahrzehntelang rund um Erweiterungen/Pluginsexistieren. Das ist das Ökosystem. Ich habe bereits über die Natur von Plattformen und deren Bedeutung nachgedacht und darüber, dass Google in seiner gesamten Unternehmensgeschichte nie verstanden hat, was notwendig ist, um eine erfolgreiche offene Plattform zu schaffen, abgesehen von Android oder Chrome.
Ich sollte Android eigentlich kurz erwähnen, denn Sie haben wahrscheinlich an es gedacht.
Erstens, Android ist nicht Google. Sie haben fast nichts gemeinsam. Android ist ein Unternehmen, das Google im Juli 2005 übernommen hat; diesem Unternehmen wurde gestattet, mehr oder weniger autonom zu arbeiten, und es blieb in den vergangenen Jahren weitgehend unberührt. Android ist bekannt für seinen technischen Stack und ebenso berüchtigt für seine komplexe Organisation. Wie ein Googler sagte: „Man kann nicht einfach so in Android einsteigen.“
In einem meiner früheren Artikel habe ich bereits darüber nachgedacht, wie schlecht einige der frühen Designentscheidungen von Android waren. Verdammtes, als ich diesen Artikel schrieb, waren sie dabei, Mist namens „Sofort-Apps“ einzuführen, die jetzt (Überraschung!) , und ich bedauere, wenn Sie so naiv waren, Google zu folgen und Ihren Inhalt in diese Sofort-Apps zu übertragen.
Aber hier gibt es einen Unterschied, einen wesentlichen Unterschied, der darin besteht, dass die Leute von Android wirklich verstehen, wie wichtig Plattformen sind. Sie bemühen sich sehr, die Funktionalität älterer Android-Anwendungen aufrechtzuerhalten. Tatsächlich sind ihre Bemühungen, die Abwärtskompatibilität zu wahren, so extrem, dass ich während meines kurzen Aufenthalts in der Android-Abteilung vor einigen Jahren versucht habe, sie zu überzeugen, die Unterstützung für einige der ältesten Geräte und APIs aufzugeben (ich habe mich geirrt, wie bei vielen anderen Dingen aus der Vergangenheit und der Gegenwart. Es tut mir leid, Android-Teams! Jetzt, wo ich in Indonesien war, verstehe ich, warum sie für uns wichtig sind).
Die Leute von Android unterstützen die Abwärtskompatibilität bis zu fast unvorstellbaren Extremen, was zu einer enormen Menge an technologischem Schulden in ihren Systemen und Werkzeugketten führt. Oh mein Gott, Sie würden einige der verrückten Dinge sehen, die sie in ihrem Build-System tun müssen, und das alles im Namen der Kompatibilität.
Dafür verleihe ich Android den begehrten Preis „Du bist nicht Google“. Sie wollen wirklich nicht Google werden, das keine langlebigen Plattformen schaffen kann, im Gegensatz zu Android weiß, wie man das macht. Und deshalb verhält sich Google in einer Hinsicht sehr weise: Es lässt die Leute in Android alles auf ihre Weise tun.
Allerdings waren Android Instant Apps eine ziemlich dumme Idee. Und wissen Sie, warum? Weil sie erforderten die Neuaufsetzung und Neugestaltung Ihrer App! Als ob die Leute einfach so zwei Millionen Apps neu schreiben würden. Ich vermute, die Instant Apps waren die Idee eines Googler.
Aber hier gibt es einen Unterschied. Abwärtskompatibilität geht mit großen Kosten einher. Android trägt die Last dieser Kosten selbst, während Google darauf besteht, dass diese Last getragen wird von von euch, dem zahlenden Kunden.
Sie können das Engagement von Android für Abwärtskompatibilität in seinen APIs sehen. Wenn Sie vier oder fünf verschiedene Teilsysteme haben, um buchstäblich dasselbe zu tun, ist das ein sicheres Zeichen dafür, dass das Engagement für Abwärtskompatibilität zugrunde liegt. Was in der Welt der Plattformen Synonym für das Engagement gegenüber Ihren Kunden und Ihrem Markt ist.
Das Hauptproblem von Google hier ist ihr Stolz auf ihre Ingenieurg hygiene. Sie mögen es nicht, wenn es viele verschiedene Wege gibt, dasselbe zu tun, wobei alte, weniger wünschenswerte Methoden neben neuen, ausgefalleneren Methoden stehen. Das erhöht die Lernkurve für Neueinsteiger im System, es erhöht die Belastung durch die Unterstützung veralteter APIs, es verlangsamt die Geschwindigkeit neuer Funktionen und die größte Sünde - es sieht unschön aus. Google ist wie die Lady Escott aus Tim Burtons "Alice im Wunderland":
Lady Escott:
— Alice, weißt du, wovor ich am meisten Angst habe?
— Vor dem Verfall der Aristokratie?
— Ich hatte Angst, dass ich hässliche Enkelkinder haben würde..
Um den Kompromiss zwischen schön und praktisch zu verstehen, lassen Sie uns die dritte erfolgreiche Plattform (nach Emacs und Android) betrachten und sehen, wie sie funktioniert: Java selbst.
In Java gibt es eine Menge veralteter APIs. Veralterung ist unter Java-Programmierern sehr beliebt, sogar beliebter als in den meisten Programmiersprachen. In Java selbst, der Hauptsprache und den Bibliotheken, finden ständig Veralterungen von APIs statt.
Wenn man nur ein Beispiel von Tausenden nimmt, als veraltet angesehen. Es ist seit der Veröffentlichung von Java 1.2 im Dezember 1998 veraltet. Es sind 22 Jahre vergangen, seitdem es veraltet ist.
Aber mein echter Produktivcode schließt immer noch Threads jeden Tag.Ist das gut? Absolut! Ich meine, klar, wenn ich den Code heute neu schreiben würde, würde ich es anders umsetzen. Aber der Code meines Spiels, das in den letzten zwei Jahrzehnten Hunderttausende von Menschen glücklich gemacht hat, wurde mit einer Funktion zum Schließen von Threads geschrieben, die zu lange hängen bleiben, und ich musste es nie ändern.Ich kenne mein System besser als jeder andere, ich habe buchstäblich 25 Jahre Erfahrung in der Produktion mit ihm, und ich kann mit Sicherheit sagen: In meinem Fall ist das Schließen dieser bestimmten Arbeits-Threads völlig harmlos.Es lohnt sich nicht, Zeit und Mühe für das Umschreiben dieses Codes aufzuwenden, und Lob sei Larry Ellison (wahrscheinlich), dass Oracle mich nicht gezwungen hat, ihn neu zu schreiben.
Wahrscheinlich versteht Oracle auch etwas von Plattformen. Wer weiß.
Beweise finden Sie in allen wichtigen Java-APIs, die von Wellen der Veralterung durchzogen sind, ähnlich den Gletscherrillen in einer Schlucht. In der Java-Swing-Bibliothek findet man leicht fünf oder sechs verschiedene Tastatur-Navigationsmanager (KeyboardFocusManager). Tatsächlich ist es schwer, eine Java-API zu finden, die nicht veraltet ist. Aber sie funktionieren immer noch! Ich denke, das Java-Team wird eine API wirklich nur dann entfernen, wenn die Schnittstelle ein offenkundiges Sicherheitsproblem verursacht.
Hier ist der Punkt, Leute: Wir, die Softwareentwickler, sind alle sehr beschäftigt, und in jedem Bereich der Softwareentwicklung stehen wir vor konkurrierenden Alternativen. Zu jedem Zeitpunkt betrachten Programmierer in Sprache X Sprache Y als mögliche Alternative. Oh, glauben Sie mir nicht? Möchten Sie Swift nennen? Sozusagen, alle migrieren zu Swift und niemand weist es zurück, richtig? Wow, wie wenig Sie wissen. Unternehmen betrachten die Kosten für doppelte mobile Entwicklungsteams (iOS und Android) – und sie beginnen zu verstehen, dass diese plattformübergreifenden Entwicklungssysteme mit lustigen Namen wie Flutter und React Native tatsächlich funktionieren und damit die Größe ihrer mobilen Teams halbieren oder ihre Produktivität verdoppeln können. Es geht um echtes Geld. Ja, es gibt Kompromisse, aber auf der anderen Seite gibt es Geld.
Nehmen wir hypothetisch an, dass Apple törichterweise ein Beispiel an Guido van Rossum genommen hat und erklärt hat, dass Swift 6.0 nicht rückwärtskompatibel mit Swift 5.0 ist, ähnlich wie Python 3 nicht mit Python 2 kompatibel ist.
Vielleicht habe ich diese Geschichte vor zehn Jahren erzählt, aber vor fünfzehn Jahren war ich mit Guido im O’Reilly’s Foo Camp, saß in einem Zelt mit Paul Graham und einer ganzen Reihe von großen Namen. Wir saßen in der drückenden Hitze und warteten darauf, dass Larry Page mit seinem privaten Hubschrauber einflog, während Guido monoton über „Python 3000“ sprach, das er so nannte, weil es so lange dauern würde, bis alle migriert sind. Wir fragten ihn die ganze Zeit, warum er die Kompatibilität verletzt, und er antwortete: „Unicode“. Und wir fragten, wenn wir unseren Code neu schreiben müssten, welche anderen Vorteile würden wir sehen? Und er antwortete „Yoooooooooooooouuuuuuuniiiiiiicoooooooode“.
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 veraltet ist, also schau dich um.
… und so weiter. Der Kreislauf des Lebens.
Aber das Wichtigste ist, dass jeder Entwickler eine Wahl hat. Und wenn du sie oft dazu zwingst, ihren Code neu zu schreiben, könnten sie auch über andere Alternativen nachdenken. Sie sind keine Gefangenen deiner, so sehr du dir das auch wünschst. Sie sind deine Gäste. Python bleibt eine sehr beliebte Programmiersprache, aber verdammtes Python 3(000) hat so ein Chaos in seiner eigenen Gemeinschaft und bei seinen Benutzern verursacht, dass die Folgen seit fünfzehn Jahren nicht beseitigt werden können.
Wie viele Python-Programme wurden aufgrund dieser Rückwärtskompatibilitätsprobleme in Go (oder Ruby oder eine andere Alternative) umgeschrieben? Wie viel neue Software wurde in etwas anderem als Python geschrieben, obwohl sie geschrieben werden könnte sein könnte, wenn Guido das ganze Dorf nicht niedergebrannt hätte? Schwer zu sagen, aber Python hat eindeutig gelitten. Es ist ein enormes Chaos, und alle verlieren.
Angenommen, Apple folgt Guídos Beispiel und bricht die Kompatibilität. Was glaubt ihr, was dann passieren wird? Nun, vielleicht werden 80-90 % der Entwickler ihre Software neu schreiben, wenn möglich. Mit anderen Worten, 10-20 % der Benutzerbasis wandern automatisch zu einer konkurrierenden Sprache, wie z.B. Flutter.
Macht das ein paar Mal – und ihr verliert die Hälfte eurer Benutzerbasis. Wie im Sport bedeutet auch in der Welt des Programmierens die aktuelle Form alles. Jeder, der in fünf Jahren die Hälfte seiner Nutzer verliert, gilt als großer dicker Verlierer. Ihr müsst im Trend der Plattformen bleiben. Aber genau hier wird euch der Verzicht auf die Unterstützung älterer Versionen letztlich zum Verhängnis. Denn jedes Mal, wenn ihr einen Teil der Entwickler verliert, verliert ihr (a) sie für immer, weil sie wütend auf euch sind wegen Vertragsbruchs, und (b) gebt sie euren Konkurrenten.Ironischerweise habe ich auch Google dabei geholfen, zu so einem Diva zu werden, die die Rückwärtskompatibilität ignoriert, als ich Grok entwickelte, ein System zur Analyse und zum Verständnis von Quellcode, das die Automatisierung und die Bereitstellung von Werkzeugen auf Basis des Codes erleichtert – es ähnelt einer IDE, aber hier speichert ein Cloud-Service materialisierte Ansichten aller Milliarden Zeilen Quellcode von Google in einem großen Datenspeicher.
Ironischerweise habe ich Google auch geholfen, zu einem solchen Primadonna zu werden, die die Rückwärtskompatibilität ignoriert, als ich Grok, ein System zur Analyse und zum Verständnis von Quellcode, das die Automatisierung und Bereitstellung von Werkzeugen auf Basis des Codes erleichtert – ähnlich wie eine IDE, aber hier speichert ein Cloud-Service die materialisierten Ansichten aller Milliarden Zeilen Quellcode von Google in einem großen Datenspeicher.
Grok hat Googlern eine leistungsstarke Grundlage für automatisches Refactoring über die gesamte Code-Basis (buchstäblich über ganz Google) bereitgestellt. Das System berechnet nicht nur Ihre aufsteigenden Abhängigkeiten (von denen Sie abhängen), sondern auch absteigende (die von Ihnen abhängen), sodass Sie bei einer API-Änderung wissen, wen Sie brechen! So können Sie bei Änderungen überprüfen, ob jeder Verbraucher Ihrer API auf die neue Version aktualisiert wurde, und tatsächlich können Sie oft mit dem Werkzeug Rosie, das sie erstellt haben, den Prozess vollständig automatisieren.
Das ermöglicht es der Google-Codebasis, intern fast übernatürlich „sauber“ zu sein, da diese robotergestützten Diener im ganzen Haus herumwuseln und automatisch alles aufräumen, wenn sie SomeDespicablyLongFunctionName in SomeDespicablyLongMethodName umbenennen, weil jemand entschieden hat, dass das ein unansehnlicher Enkel ist, der eingeschläfert werden muss.
Und um ehrlich zu sein, das funktioniert für Google… intern ziemlich gut. Ich meine, ja, die Go-Community bei Google macht sich wirklich freundlich über die Java-Community bei Google lustig, wegen ihrer Neigung zur kontinuierlichen Refaktorisierung. Wenn Sie etwas N Mal neu starten, bedeutet das, dass Sie es nicht nur N-1 Mal ruiniert haben, sondern nach einer gewissen Zeit wird ganz klar, dass Sie wahrscheinlich auch bei dem N-ten Versuch gescheitert sind. Aber unterm Strich bleiben sie über diesem ganzen Trubel und halten den Code „sauber“.
Die Probleme beginnen, wenn sie versuchen, diese Einstellung ihren Cloud-Kunden und Nutzern anderer APIs aufzuzwingen.
Ich habe Sie ein wenig mit Emacs, Android und Java bekannt gemacht; schauen wir uns die letzte erfolgreiche langlebige Plattform an: das Web selbst. Können Sie sich vorstellen, durch wie viele Iterationen HTTP seit 1995 gegangen ist, als wir blinkende Tags und „In Entwicklung“-Symbole auf Webseiten verwendet haben?
Aber es funktioniert immer noch! Und diese Seiten funktionieren immer noch! Ja, Leute, Browser sind die Weltmeister der Abwärtskompatibilität. Chrome ist ein weiteres Beispiel für eine seltene Google-Plattform, die richtig zusammengesetzt ist, und, wie Sie bereits erraten haben, agiert Chrome effektiv als isoliertes Unternehmen getrennt vom Rest von Google.
Ich möchte auch unseren Freunden unter den Betriebssystementwicklern danken: Windows, Linux, NICHT APPLE, FreeBSD und so weiter, für die großartige Arbeit, die sie in Bezug auf die Abwärtskompatibilität auf ihren erfolgreichen Plattformen geleistet haben (Apple erhält bestenfalls eine Drei minus, da sie ständig alles ohne triftigen Grund kaputt machen, aber irgendwie meistert die Community dies bei jeder Veröffentlichung, und bis jetzt sind die Container mit OS X noch nicht völlig veraltet... vorerst).
Aber warten Sie, werden Sie sagen. Vergleichen wir nicht Äpfel mit Birnen – autonome Softwaresysteme auf einem einzigen Gerät, wie Emacs/JDK/Android/Chrome, mit Mehrserver-Systemen und APIs wie in Cloud-Diensten?
Nun, ich habe gestern darüber auf Twitter geschrieben, aber in Larry Walls Stil (dem Schöpfer der Programmiersprache Perl – Anm. d. Übers.) nach dem Prinzip "Mist/Regel" habe ich nach dem Wort deprecated auf den Entwicklerseiten von Google und Amazon gesucht. Und obwohl AWS über hunderte von Angeboten mehr Dienstleistungen hat als GCP, erwähnt die Entwicklerdokumentation von Google den Begriff Abwärtskompatibilität etwa siebenmal häufiger.
Wenn jemand von Google das liest, dann sind sie sicher bereit, Diagramme im Donald Trump-Stil zu präsentieren, die zeigen, dass sie tatsächlich alles richtig machen, und dass ich keine unfairen Vergleiche anstellen sollte, wie "die Anzahl der Erwähnungen des Wortes deprecated im Verhältnis zur Anzahl der Dienstleistungen".
Aber nach all diesen Jahren bleibt Google Cloud immer noch der Service Nr. 3 (ich habe den Artikel über den gescheiterten Versuch, Nr. 2 zu werden, noch nicht geschrieben), aber wenn man Insidern glauben darf, gibt es einige Bedenken, dass sie bald auf Nr. 4 fallen könnten.
Ich habe keine schlüssigen Argumente, um meine These "zu beweisen". Alles, was ich habe, sind bunte Beispiele, die ich über 30 Jahre als Entwickler gesammelt habe. Ich habe bereits auf die tiefphilosophische Natur dieses Problems hingewiesen; in gewisser Weise ist es politisiert in den Entwicklergemeinschaften. Einige glauben, dass Plattformschöpfer sich um die Kompatibilität kümmern sollten, während andere der Meinung sind, dass dies die Verantwortung Benutzer (der Entwickler selbst) ist. Eins von beidem. Und ist es nicht wirklich eine politische Frage, wenn wir entscheiden, wer die Kosten für gemeinsame Probleme tragen sollte?
Also ist das Politik. Und sicherlich wird es wütende Antworten auf meine Aussage geben.
Wie Nutzer Von der Google-Cloud-Plattform und als AWS-Nutzer über zwei Jahre (während meiner Zeit bei Grab) kann ich sagen, dass es einen gewaltigen Unterschied zwischen den Philosophien von Amazon und Google gibt, wenn es um Prioritäten geht. Ich bin nicht aktiv in der Entwicklung bei AWS tätig, deshalb weiß ich nicht genau, wie oft sie alte APIs entfernen. Aber ich habe den Verdacht, dass das längst nicht so häufig vorkommt wie bei Google. Und ich glaube aufrichtig, dass diese Quelle ständiger Streitigkeiten und Enttäuschungen in GCP einer der größten Faktoren ist, der die Entwicklung der Plattform hemmt.
Ich weiß, dass ich keine konkreten Beispiele für GCP-Systeme genannt habe, deren Unterstützung eingestellt wurde. Ich kann sagen, dass nahezu alles, was ich verwendet habe, von Netzwerken (von den ältesten bis zu VPC) über Speicher (Cloud SQL v1-v2), Firebase (jetzt Firestore mit einem völlig anderen API), App Engine (lassen wir das mal lieber), die Cloud-Endpoints und bis zu... ich weiß nicht... absolut alles davon mich dazu gezwungen hat, den Code maximal alle 2-3 Jahre neu zu schreiben, und sie haben niemals die Migration für euch automatisiert, und oft Also, als wäre das so vorgesehen.
Jedes Mal, wenn ich mir AWS anschaue, frage ich mich, was zur Hölle ich immer noch auf GCP mache. Sie brauchen offensichtlich keine Kunden. Sie brauchen Käufer.Verstehst du den Unterschied? Lass es mich erklären.
Google Cloud hat einen auf dem Leute ihre Softwarelösungen anbieten. Und um den Effekt eines leeren Restaurants zu vermeiden, mussten sie ihn mit einigen Angeboten füllen, weshalb sie einen Vertrag mit der Firma Bitnami abgeschlossen haben, um eine Menge Lösungen zu schaffen, die "mit einem Klick" bereitgestellt werden können. Oder ich muss selbst "Lösungen" schreiben, weil diese keinen Deut lösen. Sie existieren einfach als Häkchen, als Marketingfüllmaterial, und Google hat sich nie darum gekümmert, ob eines der Tools tatsächlich funktioniert. Ich kenne Produktmanager, die am Steuer sitzen, und ich kann euch versichern, dass diesen Leuten das völlig egal ist.
Nehmen wir zum Beispiel eine Lösung, die angeblich "mit einem Klick" bereitgestellt wird. Ich bin Google Cloud SQL überdrüssig geworden, sodass ich anfangen musste, die Erstellung meines eigenen Percona-Clusters als Alternative zu betrachten. Und dieses Mal scheint Google es gut gemacht zu haben, denn sie wollten mir mit einem Klick etwas Zeit und Mühe sparen!
Nun gut, los geht's. Lass uns dem Link folgen und diesen Button klicken. Wählen wir "Ja", um allen Standardparametern zuzustimmen und einen Cluster in unserem Google Cloud-Projekt bereitzustellen. Haha, es funktioniert nicht. Nichts von diesem Mist funktioniert. Das Tool wurde nie getestet und begann vom ersten Moment an zu verwesen, und es würde mich nicht wundern, wenn mehr als die Hälfte der "Ein-Klick-Bereitstellungslösungen" (jetzt verstehen wir, warum die Anführungszeichen) nicht funktionieren. überhaupt funktioniert nicht. Es ist eine absolut trostlose Dunkelheit, in die man besser nicht eintaucht.
Aber Google fordert dich direkt auf, es zu nutzen. Sie möchten, dass du es kaufst.Für sie ist das eine Transaktion. Sie möchten nichts unterstützen.Das ist nicht Teil der DNA von Google. Ja, Ingenieure unterstützen sich gegenseitig, wie meine Geschichte mit Bigtable zeigt. Aber bei Produkten und Dienstleistungen für gewöhnliche Menschen immer rücksichtslos beim der nicht profitabel ist, selbst wenn er Millionen von Nutzern hat.
Und das stellt ein echtes Problem für GCP dar, denn diese DNA steht hinter allen Cloud-Angeboten. Sie streben nicht danach, irgendetwas zu unterstützen; es ist weithin bekannt, dass sie (als verwalteten Dienst) jede Drittanbieter-Software ablehnen, solange, bis AWS das Gleiche tut und ein erfolgreiches Geschäft drumherum aufbaut, und wenn Kunden buchstäblich dasselbe verlangen. Es ist jedoch notwendig, gewisse Anstrengungen zu unternehmen, um Google dazu zu bringen, etwas zu unterstützen.
Fehlende Unterstützungskultur, kombiniert mit dem Prinzip "Lasst uns brechen, um es schöner zu machen", entfremdet die Entwickler von ihnen.
Und das ist nicht gut, wenn du eine langlebige Plattform aufbauen willst.
Google, wach auf, verdammtes. Es ist jetzt 2020. Du verlierst immer noch. Es ist an der Zeit, in den Spiegel zu schauen und zu beantworten, ob du wirklich im Cloud-Geschäft bleiben willst.
Wenn du bleiben willst, dann hör auf, alles zu brechen.Leute, ihr seid reich. Wir, die Entwickler, sind es nicht. Daher, wenn es darum geht, wer die Last der Kompatibilität trägt, müsst ihr das übernehmen. Nicht wir.
Denn es gibt noch mindestens drei wirklich gute Clouds. Sie ziehen an.
Und jetzt werde ich weiter alle meine kaputten Systeme reparieren. Seufz.
Bis zum nächsten Mal!
P. S. Aktualisierung nach dem Lesen einiger Diskussionen zu diesem Artikel (die Diskussionen sind übrigens großartig). Die Unterstützung von Firebase wurde nicht eingestellt, und ich kenne keine entsprechenden Pläne. Allerdings gibt es einen unangenehmen Streaming-Fehler, der dazu führt, dass der Java-Client im App Engine stoppt. Einer ihrer Ingenieure hat mir geholfen, mit diesem Problem umzugehen, als ich bei Google gearbeitet habe, aber sie haben den Bug nie wirklich behoben, also habe ich einen miesen Workaround, ich muss die GAE-Anwendung jeden Tag neu starten. Das ist jetzt schon seit vier Jahren so! Jetzt haben sie Firestore. Es wird viel Arbeit erfordern, um darauf umzusteigen, da es ein ganz anderes System ist, und der Fehler von Firebase wird niemals behoben. Was kann man daraus schließen? Sie können Hilfe erhalten, wenn Sie in einem Unternehmen arbeiten. Wahrscheinlich bin ich der Einzige, der Firebase auf GAE verwendet, denn ich schreibe weniger als 100 Schlüssel in einer 100% nativen Anwendung, und sie hört alle paar Tage wegen eines bekannten Fehlers auf zu funktionieren. Was kann man dazu sagen, außer es auf eigene Gefahr zu verwenden? Ich wechsle zu Redis.
Ich habe auch gesehen, wie einige erfahrenere AWS-Nutzer gesagt haben, dass AWS normalerweise keine Dienstleistungen abbricht, und SimpleDB ist ein hervorragendes Beispiel dafür. Meine Annahmen, dass AWS nicht mit einem Support-Abbruch wie bei Google zu kämpfen hat, scheinen sich zu bestätigen.
Außerdem habe ich bemerkt, dass das Google App Engine-Team vor 20 Tagen das Hosting einer kritischen Go-Bibliothek kaputt gemacht hat, indem es die GAE-Anwendung von einem der Hauptentwickler von Go abgekoppelt hat. Es ist wirklich dumm gelaufen.
Schließlich habe ich gehört, dass die Googler dieses Problem bereits diskutieren und im Großen und Ganzen mit mir einverstanden sind (ich liebe euch, Leute!). Aber es scheint, dass sie das Problem als unlösbar betrachten, weil es in der Kultur von Google nie eine richtige Anreizstruktur gegeben hat. Ich denke, es wäre gut, etwas Zeit zu finden, um die absolut erstaunliche Erfahrung zu besprechen, die ich mit den Ingenieuren von AWS gemacht habe, als ich bei Grab gearbeitet habe. Irgendwann in der Zukunft, hoffentlich!
Ja, im Jahr 2005 gab es tatsächlich verschiedene Arten von Haifischfleisch auf dem riesigen Buffet im Gebäude 43, und mir hat das Fleisch der Hammerhaie am besten geschmeckt. Allerdings hatten Larry und Sergey bis 2006 alle ungesunden Snacks eliminiert. Während der Bigtable-Geschichte im Jahr 2007 gab es also tatsächlich keine Haie, und ich habe Sie bewusst getäuscht.
Als ich vor vier Jahren (plus/minus) auf die cloudbasierte Bigtable schaute, war der Preis genau so. Es scheint, dass er jetzt etwas gesunken ist, aber es ist immer noch sehr viel für einen leeren Datenspeicher, insbesondere wenn man bedenkt, dass meine erste Geschichte zeigt, wie unwesentlich eine leere große Tabelle in ihrem Maßstab ist.
Es tut mir leid, dass ich die Apple-Community beleidigt habe und nichts Gutes über Microsoft usw. gesagt habe. Ihr habt alle recht, ich schätze die vielen Diskussionen, die dieser Artikel ausgelöst hat! Aber manchmal muss man ein bisschen Welle schlagen, um die Diskussion anzustoßen, versteht ihr?
Danke fürs Lesen.
Update 2, 19.08.2020. Stripe !
Update 3, 31.08.2020. Ein Ingenieur von Google im Cloud Marketplace hat sich bei mir gemeldet, der sich als mein alter Freund entpuppte. Er wollte herausfinden, warum C2D nicht funktioniert, und schließlich fanden wir heraus: Der Grund ist, dass ich mein Netzwerk vor ein paar Jahren erstellt habe, und C2D funktioniert in veralteten Netzwerken nicht wegen eines fehlenden Subnetzparameters in ihren Vorlagen. Ich denke, potenzielle GCP-Nutzer sollten sicherstellen, dass sie genügend erfahrene Ingenieure bei Google haben...
Quelle: habr.com
