Lassen Sie uns das hinter uns bringen.
Ich beginne mit einer kleinen, aber lehrreichen Geschichte, als ich anfing, bei Google zu arbeiten. Ich weiß, dass ich in letzter Zeit viele schlechte Dinge über Google gesagt habe, aber es ärgert mich, wenn meine Heimatfirma regelmäßig inkompetente Geschäftsentscheidungen trifft. Trotzdem müssen wir Tribut zollen: Die interne Infrastruktur von Google ist wirklich außergewöhnlich, und wir können mit Sicherheit sagen, dass es heute nichts Besseres gibt. Die Gründer von Google waren weitaus bessere Ingenieure als ich jemals werden werde, und diese Geschichte bestätigt nur diese Tatsache.
Zunächst ein kleiner Hintergrund: Google hat eine Speichertechnologie namens Bigtable . Es war eine bemerkenswerte technische Leistung, eine der ersten (wenn nicht die erste) "unendlich skalierbaren" Schlüsselwertspeicher (K / V): im Wesentlichen der Beginn von NoSQL. Bigtable fühlt sich heutzutage immer noch gut in dem überfüllten K / V-Speicher an, aber zu der Zeit (2005) war es erstaunlich cool.
Eine lustige Sache an Bigtable ist, dass sie Objekte der internen Kontrollebene (als Teil der Implementierung) hatten, die als Tablet-Server bezeichnet wurden, mit großen Indizes, und irgendwann wurden sie zu einem Engpass bei der Skalierung des Systems. Die Ingenieure von Bigtable haben sich Gedanken darüber gemacht, wie Skalierbarkeit implementiert werden kann, und plötzlich festgestellt, dass sie Tablet-Server durch andere Bigtable-Speicher ersetzen können. Bigtable ist also Teil der Bigtable-Implementierung. Diese Lagereinrichtungen gibt es auf allen Ebenen.
Ein weiteres interessantes Detail ist, dass Bigtable für eine Weile in Google populär und allgegenwärtig wurde und jedes Team sein eigenes Repository hatte. Bei einem Treffen am Freitag fragte Larry Page beiläufig beiläufig: „Warum haben wir mehr als eine Bigtable? Warum nicht nur einer? Theoretisch sollte ein Speicherplatz für alle Speicheranforderungen von Google ausreichen. Natürlich sind sie aus praktischen Entwicklungsgründen (wie den Folgen eines möglichen Versagens) nie auf einen gesprungen, aber die Theorie war interessant. Ein Repository für das gesamte Universum ( weiß übrigens jemand, ob Amazon dies mit seinem Sable getan hat? )
Wie auch immer, hier ist meine Geschichte.
Zu dieser Zeit arbeitete ich etwas mehr als zwei Jahre bei Google und eines Tages erhielt ich eine E-Mail vom Bigtable-Engineering-Team:
Lieber Steve,
Grüße vom Bigtable-Team. Wir möchten Sie darüber informieren, dass Sie eine sehr, sehr alte Bigtable-Binärdatei im Rechenzentrum [Name des Rechenzentrums] 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 einplanen können, um an diesem Problem zusammenzuarbeiten.
Alles Gute,
Bigtable Team
Sie erhalten eine Menge E-Mails bei Google, daher habe ich auf den ersten Blick Folgendes gelesen:
,
- . , ----. -----, -- .
, , --.
,
-
Ich hätte es fast sofort gelöscht, aber am Rande meines Bewusstseins fühlte ich ein schmerzhaftes, schmerzendes Gefühl, dass dies nicht ganz wie ein formeller Brief aussieht, obwohl es offensichtlich ist, dass der Empfänger sich geirrt hat, weil ich Bigtable nicht verwendet habe.
Aber das war komisch.
Für den Rest des Tages dachte ich abwechselnd über Arbeit nach und darüber, welche Art von Haifischfleisch ich in einer Mikroküche probieren sollte, von denen mindestens drei nahe genug waren, um mit einem gezielten Keks von meinem Platz zu verschwinden, aber der Gedanke an das Schreiben ließ mich nicht mit einem wachsenden Gefühl zurück. leichte Angst.
Sie haben eindeutig meinen Namen genannt. Und die E-Mail wird an meine E-Mail-Adresse gesendet, nicht an die einer anderen Person, und es ist 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 in dem von ihnen erwähnten Rechenzentrum an.
Und natürlich hatte ich den BigTable-Speicher unter meiner Kontrolle. Was was? Ich habe mir den Inhalt angesehen und - wow! Es war aus dem Codelab-Inkubator, wo ich im Juni 2005 meine erste Woche bei Google verbracht habe. Codelab hat Sie gezwungen, Bigtable zu starten, damit Sie dort einige Werte schreiben, und danach habe ich das Repository wahrscheinlich nie mehr geschlossen. Es funktionierte immer noch, obwohl mehr als zwei Jahre vergangen waren.
Diese Geschichte hat mehrere bemerkenswerte Aspekte. Erstens war Bigtables Arbeit auf der Skala von Google so unbedeutend, dass nur zwei Jahre später jemand den zusätzlichen Speicher bemerkte, und selbst dann nur, weil die Version der Binärdatei veraltet war. Zum Vergleich habe ich einmal darüber nachgedacht, zu verwendenBigtable in Google Cloud für mein Online-Spiel. Zu diesem Zeitpunkt kostete dieser Service ungefähr 16.000 USD pro Jahr für eine leere 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 leere verdammte Datenbank.
Ein weiterer bemerkenswerter Aspekt ist, dass der Speicher nach zwei Jahren noch funktionierte... WTF? Rechenzentren kommen und gehen; Sie haben Unterbrechungen, werden routinemäßig gewartet und ändern sich ständig. Die Hardware wird aktualisiert, die Schalter werden ausgetauscht, alles wird ständig verbessert. Wie zum Teufel haben sie es geschafft, mein Programm mit all diesen Änderungen zwei Jahre lang am Laufen zu halten? Dies mag 2020 als bescheidene Leistung erscheinen, war aber 2005-2007 ziemlich beeindruckend.
Und das Schönste ist, dass ein externes Engineering-Team in einem anderen Bundesstaat mich kontaktiert, den Besitzer einer winzigen, fast leeren Instanz von Bigtable, die in den letzten zwei Jahren keinen Verkehr hatte - und Hilfe bei der Aktualisierung anbietet. ...
Ich dankte ihnen, entfernte das Gewölbe und das Leben ging wie gewohnt weiter. Aber dreizehn Jahre später denke ich immer noch an diesen Brief. Denn manchmal bekomme ich solche E-Mails von Google Cloud. Sie sehen so aus:
Sehr geehrter Google Cloud-Nutzer, wir
erinnern Sie daran, dass wir den Dienst [einen wichtigen Dienst, den Sie verwenden] ab August 2020 einstellen. Danach können Sie Ihre Instanzen nicht mehr aktualisieren. Wir empfehlen Ihnen, ein Upgrade auf die neueste Version durchzuführen, die sich im Beta-Test befindet, keine Dokumentation und keinen Migrationspfad enthält und mit unserer freundlichen Hilfe im Voraus veraltet ist.
Wir setzen uns dafür ein, dass diese Änderung die geringsten Auswirkungen auf alle Nutzer der Google Cloud-Plattform hat.
Beste Freunde für immer,
Google Cloud Platform
Aber ich lese solche Briefe kaum, weil sie tatsächlich Folgendes sagen:
Lieber Empfänger,
Fick dich. Fick dich, fick dich, fick dich. Wirf alles weg, was du tust, weil es keine Rolle spielt. Was zählt, ist unsere Zeit. Wir geben Zeit und Geld aus, um unsere Scheiße zu unterstützen, und wir haben es satt, also werden wir sie nicht mehr unterstützen. Lassen Sie also Ihre verdammten Pläne fallen und stöbern Sie in unserer beschissenen Dokumentation, betteln Sie in den Foren um Schrott, und unsere neue Scheiße unterscheidet sich übrigens völlig von der alten, weil wir dieses Design ziemlich durcheinander gebracht haben, heh, aber das ist Ihr Problem, nicht unsere.
Wir arbeiten immer noch hart daran, dass alle Ihre Designs innerhalb eines Jahres unbrauchbar werden.
Bitte gehen Sie nah,
Google Cloud Platform
Und Tatsache ist, dass ich solche Briefe ungefähr einmal im Monat erhalte. Dies passiert so oft und so ständig, dass sie mich unweigerlich von der GCP weg und in das gegnerische Wolkenlager drängten . Ich bin nicht mehr damit einverstanden, von ihrer proprietären Entwicklung abhängig zu sein, da es für Entwickler tatsächlich einfacher ist, ein Open-Source-System auf einer nackten virtuellen Maschine zu warten, als zu versuchen, mit der Politik von Google, "veraltete" Produkte zu schließen, Schritt zu halten.
Bevor ich zurück zu Google Cloud gehe, weil ich sogar in der Nähe binLassen Sie uns die Leistung des Unternehmens in einigen anderen Bereichen betrachten. Google-Ingenieure sind stolz auf ihre Software-Engineering-Disziplin, und genau das verursacht tatsächlich Probleme. Stolz ist eine Falle für Unachtsame. Viele Google-Mitarbeiter sind der Meinung, dass ihre Entscheidungen immer richtig sind und dass es wichtiger ist, richtig zu sein (nach einer vagen, unscharfen Definition) als die Kundenbetreuung.
Hier sind einige willkürliche Beispiele aus anderen großen Projekten außerhalb von Google, aber ich hoffe, Sie sehen dieses Muster überall. Es ist dies: Abwärtskompatibilität hält Systeme über Jahrzehnte am Leben und auf dem neuesten Stand .
Abwärtskompatibilität ist das Entwurfsziel aller erfolgreichen Systeme, die darauf ausgelegt sindOpen Use, dh implementiert mit Open Source und / oder Open Standards. Ich habe das Gefühl, ich sage etwas zu Offensichtliches, als dass es allen unangenehm ist, aber nein. Dies ist ein politisches Thema, daher sind Beispiele erforderlich.
Das erste System, das ich wähle, ist das älteste: GNU Emacs, eine Art Hybrid zwischen Windows Notepad, dem Betriebssystemkern und der Internationalen Raumstation. Es ist ein wenig schwierig zu erklären, aber kurz gesagt, Emacs ist eine Plattform, die 1976 (ja, vor fast einem halben Jahrhundert) für die Programmierung zur Steigerung Ihrer Produktivität geschaffen wurde, sich jedoch als Texteditor tarnt.
Ich benutze Emacs jeden Tag. Ja, ich benutze IntelliJ auch jeden Tag, es ist selbst zu einer leistungsstarken Werkzeugplattform geworden. Das Schreiben von Erweiterungen für IntelliJ ist jedoch viel ehrgeiziger und schwieriger als das Schreiben von Erweiterungen für Emacs. Und was noch wichtiger ist, alles, was für Emacs geschrieben wurde, wird für immer dauern .
Ich benutze immer noch Software, die ich 1995 für Emacs geschrieben habe. Und ich bin sicher, dass jemand Module verwendet, die Mitte der 80er Jahre für Emacs geschrieben wurden, wenn nicht vorher. Sie können von Zeit zu Zeit geringfügige Anpassungen erfordern, aber dies ist wirklich ziemlich selten. Ich weiß nichts, was ich jemals für Emacs geschrieben habe (und ich habe viel geschrieben), was die Architektur neu gestalten müsste.
Emacs hat eine Funktion namens make-obsolete für Legacy-Entitäten. Die Emacs-Terminologie für grundlegende Computerkonzepte (z. B. was ein "Fenster" ist) unterscheidet sich häufig von Branchenkonventionen, da Emacs sie vor langer Zeit eingeführt hat. Dies ist eine typische Gefahr für diejenigen, die ihrer Zeit voraus sind: Alle Ihre Bedingungen sind falsch. Aber Emacs hat ein Konzept der Veralterung, das in ihrer Fachsprache als Veralterung bezeichnet wird .
Aber in der Emacs-Welt scheint es eine andere Arbeitsdefinition zu geben. Eine andere zugrunde liegende Philosophie, wenn Sie so wollen.
In der Emacs-Welt (und in vielen anderen Bereichen, die wir weiter unten behandeln werden) bedeutet der Verfallsstatus von APIs im Grunde: „Sie sollten diesen Ansatz wirklich nicht verwenden, da er zwar funktioniert, aber unter verschiedenen Nachteilen leidet, die wir hier auflisten. Aber am Ende haben Sie die Wahl. "
In der Google-Welt bedeutet der Status eines Legacy-Produkts "Wir verstoßen gegen unsere Verpflichtung Ihnen gegenüber." Das ist tatsächlich so. Das ist es, was es im Wesentlichen bedeutet. Dies bedeutet, dass sie Sie zwingen werden , regelmäßig zu arbeiten , vielleicht viel Arbeit, als Strafe für das Vertrauen in ihre farbenfrohen Anzeigen : Wir haben die beste Software. Die schnellste! Sie tun alles gemäß den Anweisungen, starten Ihre Anwendung oder Ihren Dienst und bammen dann nach ein oder zwei Jahren.
Es ist wie der Verkauf eines Gebrauchtwagens, der nach 1500 km definitiv kaputt geht.
Dies sind zwei völlig unterschiedliche philosophische Definitionen von "Veralterung". Googles Definition riecht nach geplanter Veralterung . Ich glaube nicht, dass es wirklich so istgeplante Veralterung im gleichen Sinne wie Apple. Aber Google plant definitiv, Ihre Programme auf Umwegen zu brechen. Ich weiß das, weil ich dort über 12 Jahre als Softwareentwickler gearbeitet habe. Sie haben vage interne Richtlinien, wie viel Abwärtskompatibilität sein sollte, aber letztendlich hängt es von jedem einzelnen Team oder Service ab. Es gibt keine Unternehmens- oder Engineering-Empfehlung, und die kühnste Empfehlung in Bezug auf Veralterungszyklen lautet: „Versuchen Sie, den Kunden 6 bis 12 Monate Zeit für ein Upgrade zu geben, bevor Sie das gesamte System beschädigen.“
Das Problem ist viel schwerwiegender als gedacht und wird auch in den kommenden Jahren bestehen bleiben, da die Kundenbetreuung nicht Teil ihrer DNA ist. Mehr dazu weiter unten.
Im Moment werde ich die kühne Aussage machen, dass Emacs zum großen Teil und sogar größtenteils erfolgreich ist , weil sie die Abwärtskompatibilität so ernst nehmen. Eigentlich ist dies die These unseres Artikels. Erfolgreiche langlebige Open Source-Systeme verdanken ihren Erfolg Mikrogemeinschaften, die sich seit Jahrzehnten mit Erweiterungen / Plugins beschäftigen . Dies ist das Ökosystem. Ich habe bereits über die Essenz von Plattformen gesprochen und darüber, wie wichtig sie sind und wie Google in seiner gesamten Unternehmensgeschichte nie verstanden hat, was zur Schaffung einer erfolgreichen offenen Plattform beiträgt, abgesehen von Android oder Chrome.
Eigentlich muss ich Android kurz erwähnen, weil du wahrscheinlich darüber nachgedacht hast.
Erstens ist Android nicht Google... Sie haben fast nichts miteinander zu tun. Android ist ein Unternehmen, das im Juli 2005 von Google gekauft wurde. Dieses Unternehmen durfte mehr oder weniger autonom arbeiten und ist im Laufe der Jahre weitgehend intakt geblieben. Android ist ein berüchtigter Tech-Stack und eine ebenso berüchtigte dornige Organisation. Wie ein Googler es ausdrückte: "Sie können nicht einfach in Android gehen."
In einem meiner früheren Artikel habe ich besprochen, wie schlecht einige der frühen Entscheidungen zum Android-Design waren. Heck, als ich diesen Artikel schrieb, stellten sie eine Scheiße namens "Instant Apps" bereit, die jetzt (Überraschung!) Veraltet sindund ich sympathisiere, wenn Sie dumm genug waren, Google zu hören und Ihre Inhalte auf diese Sofort-Apps zu bringen.
Aber es gibt einen Unterschied, einen signifikanten Unterschied, nämlich dass Android-Leute wirklich verstehen, wie wichtig Plattformen sind. Sie versuchen ihr Bestes, um alte Android-Apps funktionsfähig zu halten. Tatsächlich sind ihre Bemühungen, die Abwärtskompatibilität aufrechtzuerhalten, so extrem, dass selbst ich während meiner kurzen Zeit in der Android-Abteilung vor einigen 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 war viele andere Dinge in Vergangenheit und Gegenwart. Sorry Android Leute! Jetzt, wo ich in Indonesien war, verstehe ich, warum wir sie brauchen.
Die Android-Leute behalten die Abwärtskompatibilität mit fast unvorstellbaren Extremen bei und häufen eine riesige Menge veralteter technischer Schulden in ihren Systemen und Toolchains an. Oh mein Gott, du hättest einige verrückte Dinge sehen sollen, die sie in ihrem Build-System tun müssen, alles im Namen der Kompatibilität.
Dafür gebe ich Android den begehrten You Are Not Google Award. Sie wollen wirklich nicht Google werden, das nicht weiß, wie man dauerhafte Plattformen baut, aber Android weiß, wie man das macht. Und so ist Google in einer Hinsicht sehr weise: Es ermöglicht Menschen auf Android, Dinge auf ihre eigene Weise zu tun.
Sofortige Android-Apps waren jedoch eine ziemlich dumme Idee. Weißt du, warum? Weil sie es verlangtenSchreiben Sie Ihre Anwendung neu und gestalten Sie sie neu ! Als würden die Leute einfach zwei Millionen Apps nehmen und neu schreiben. Ich denke, die Sofort-Apps waren eine Googler-Idee.
Aber hier gibt es einen Unterschied. Abwärtskompatibilität ist teuer. Android selbst trägt die Last dieser Kosten, während Google darauf besteht, dass Sie als bezahlter Kunde die Last tragen .
Sie können das Engagement von Android für die Abwärtskompatibilität in seinen APIs sehen. Wenn Sie vier oder fünf verschiedene Subsysteme haben, um buchstäblich dasselbe zu tun, ist dies ein sicheres Zeichen dafür, dass die Verpflichtung zur Abwärtskompatibilität im Mittelpunkt steht. Was in der Plattformwelt gleichbedeutend mit Engagement für Ihre Kunden und Ihren Markt ist.
Das Hauptproblem von Google ist der Stolz auf die technische Hygiene. Sie mögen es nicht, wenn es viele verschiedene Möglichkeiten gibt, dasselbe zu tun, wobei ältere, weniger wünschenswerte Möglichkeiten neben neueren, bizarreren Möglichkeiten stehen. Es erhöht die Lernkurve für Systemneulinge, erhöht die Belastung durch die Wartung älterer APIs, verlangsamt die Geschwindigkeit neuer Funktionen und die Hauptsünde ist hässlich. Google - wie Lady Ascot aus "Alice im Wunderland" von Tim Burton:
Lady Ascot:
- Alice, weißt du, wovor ich am meisten Angst habe?
- Der Niedergang der Aristokratie?
- Ich hatte Angst, dass ich hässliche Enkelkinder haben würde .
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 eine Menge älterer APIs. Verfall ist bei Java-Programmierern sehr beliebt, sogar noch beliebter als die meisten Programmiersprachen. In Java selbst, der Hauptsprache und den Bibliotheken, treten ständig API-Verwerfungen auf.
Wenn Sie nur eines von Tausenden von Beispielen verwenden, ist das Schließen von Streams veraltet. Es ist seit der Veröffentlichung von Java 1.2 im Dezember 1998 veraltet. Es ist 22 Jahre her, seit dies veraltet war.
Aber mein echter Produktionscode tötet immer noch jeden Tag Threads... Ist es gut? Absolut! Ich meine natürlich, wenn ich den Code heute neu schreiben würde, würde ich ihn anders implementieren. Aber der Code für mein Spiel, der in den letzten zwei Jahrzehnten Hunderttausende glücklich gemacht hat, wurde mit der Funktion geschrieben, Threads zu schließen, die zu lange hängen, und ich musste ihn nie ändern . Ich kenne mein System am besten, ich habe buchstäblich 25 Jahre Erfahrung in der Produktion, und ich kann mit Sicherheit sagen: In meinem Fall ist das Schließen dieser spezifischen Arbeitsabläufe völlig harmlos . Sie sollten keine Zeit und Mühe damit verschwenden, diesen Code neu zu schreiben, und Larry Ellison (wahrscheinlich) loben, dass Oracle mich nicht gezwungen hat, ihn neu zu schreiben.
Wahrscheinlich ist Oracle auch plattformbewusst. Wer weiß.
Es gibt Beweise für alle Java-Kern-APIs, die von Wellen der Veralterung durchsetzt sind, wie Gletscherlinien 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, das Java-Team wird die API nur dann wirklich entfernen, wenn die Schnittstelle ein schwerwiegendes Sicherheitsproblem verursacht.
Hier ist die Sache, Leute: Wir Softwareentwickler sind alle sehr beschäftigt, und in jedem Bereich der Software stehen wir vor konkurrierenden Alternativen. Zu jedem Zeitpunkt sehen X-Programmierer Y als möglichen Ersatz. Oh glaubst du mir nicht? Willst du Swift heißen? 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 sie beginnen zu erkennen, dass diese plattformübergreifenden Entwicklungssysteme wie Flutter und React Native funktionieren und die Größe ihrer mobilen Teams reduzieren können. zweimal oder umgekehrt doppelt so produktiv. Es geht um echtes Geld. Ja, es gibt Kompromisse, aber andererseits De-E-Geld.
Nehmen wir hypothetisch an, Apple sei törichterweise dem Beispiel von Guido van Rossum gefolgt und habe angekündigt, dass Swift 6.0 mit Swift 5.0 abwärtskompatibel ist, ähnlich wie Python 3 mit Python 2 nicht kompatibel ist.
Ich habe diese Geschichte wahrscheinlich vor zehn Jahren erzählt, aber vor fünfzehn Jahren ging mit Guido zu O'Reillys Foo Camp, saß mit Paul Graham und ein paar großen Beulen in einem Zelt. Wir saßen in der drückenden Hitze und warteten darauf, dass Larry Page in seinem persönlichen Hubschrauber abhob, während Guido monoton über den Python 3000 murmelte, den er nach der Anzahl der Jahre benannte, die jeder brauchen würde, um dorthin zu migrieren. Wir haben ihn die ganze Zeit gefragt, warum dies die Kompatibilität beeinträchtigt, und er antwortete: "Unicode". Und wir fragten, ob wir unseren Code neu schreiben müssen, welche anderen Vorteile werden 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 Python 2-Unterstützung veraltet ist
… usw. Der Kreislauf des Lebens.
Aber der Punkt ist, jeder Entwickler hat die Wahl. Und wenn Sie sie dazu bringen, den Code oft genug neu zu schreiben, denken sie möglicherweise über andere Optionen nach. Sie sind nicht deine Geiseln, egal wie sehr du sie haben willst. Sie sind Ihre Gäste. Python ist immer noch eine sehr beliebte Programmiersprache, aber zum Teufel hat Python 3 (000) in seinen Communitys und bei den Benutzern seiner Communitys ein derartiges Durcheinander verursacht, dass die Konsequenzen seit fünfzehn Jahren nicht geklärt sind.
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 dies möglicherweise der Fall wargeschrieben in Python, wenn Guido nicht das ganze Dorf niedergebrannt hätte? Es ist schwer zu sagen, aber Python hat eindeutig gelitten. Dies ist ein großes Durcheinander, und jeder verliert.
Nehmen wir also an, Apple folgt dem Beispiel von Guido und bricht die Kompatibilität. Was glaubst du wird als nächstes passieren? Nun, vielleicht werden 80-90% der Entwickler ihre Software neu schreiben, wenn sie können. Mit anderen Worten, 10-20% der Benutzer gehen automatisch zu einer konkurrierenden Sprache wie Flutter.
Wenn Sie dies einige Male tun, verlieren Sie die Hälfte Ihrer Benutzerbasis. Wie im Sport bedeutet auch in der Programmierwelt die aktuelle Form alles.... Jeder, der in fünf Jahren die Hälfte seiner Nutzer verliert, wird als Big Fat Loser angesehen. Sie sollten in der Plattformwelt im Trend liegen. Aber hier werden Sie mit der Zeit umgebracht, wenn Sie die Unterstützung für ältere Versionen aufgeben. Denn jedes Mal, wenn Sie einen Teil der 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 Ihren Konkurrenten.
Ironischerweise habe auch ich dazu beigetragen, Google zu einer abwärtskompatiblen Primadonna zu machen, als ich Grok entwickelte, ein Quellcode-Analyse- und Verständnissystem, das die codebasierte Automatisierung und das Tooling erleichtert - ähnlich einer IDE, aber hier entstanden die Cloud-Service-Stores Darstellungen aller Milliarden Zeilen des Google-Quellcodes in einem großen Data Warehouse.
Grok stellte Googlern ein leistungsstarkes Framework für das automatisierte Refactoring über die gesamte Codebasis (buchstäblich über Google) zur Verfügung. Das System berechnet nicht nur Ihre Upstream-Abhängigkeiten (von denen Sie abhängig sind), sondern auch die Downstream- Abhängigkeiten (von denen Sie abhängen). Wenn Sie also die API ändern, kennen Sie jeden, den Sie brechen! Auf diese Weise können Sie bei Änderungen überprüfen, ob jeder Verbraucher Ihrer API auf die neue Version aktualisiert wurde. In der Realität können Sie den Prozess häufig mit dem von ihnen geschriebenen Rosie-Tool vollständig automatisieren.
Dies ermöglicht es Googles Codebasis, intern fast übernatürlich "sauber" zu sein, da diese Roboterdiener durch das Haus huschen und automatisch alles bereinigen, wenn sie SomeDespicablyLongFunctionName in SomeDespicablyLongMethodName umbenennen, weil jemand dachte, es sei ein hässlicher Enkel und sein müssen eingeschläfert werden.
Und um ehrlich zu sein, funktioniert es ziemlich gut für Google ... intern. Ich meine, ja, die Go-Community bei Google hat ein wirklich gutes Lachen über die Java-Community bei Google, weil sie die Gewohnheit hat, sich ständig umzugestalten. Wenn Sie etwas N-mal neu starten, bedeutet dies, dass Sie es nicht nur N-1-mal durcheinander gebracht haben, sondern nach einer Weile wird klar, dass Sie es wahrscheinlich beim n-ten Versuch durcheinander gebracht haben. Aber im Großen und Ganzen bleiben sie über dieser Aufregung und halten den Code "sauber".
Die Probleme beginnen, wenn sie versuchen, ihren Cloud-Clients und Benutzern anderer APIs diese Einstellung aufzuzwingen.
Ich habe Sie ein wenig mit Emacs, Android und Java bekannt gemacht. Werfen wir einen Blick auf die neueste erfolgreiche, langlebige Plattform: das Web selbst. Sie können sich vorstellen, wie viele Iterationen HTTP seit 1995 durchlaufen hat, als wir blinkende <blink> -Tags und im Aufbau befindliche Symbole auf Webseiten verwendet haben.
Aber es funktioniert immer noch! Und diese Seiten funktionieren immer noch! Ja Leute, Browser sind die Abwärtskompatibilitäts-Champions der Welt. Chrome ist ein weiteres Beispiel für eine seltene Google-Plattform, deren Köpfe korrekt angeschraubt sind. Sie haben es erraten, Chrome fungiert effektiv als isoliertes Unternehmen, das vom Rest von Google getrennt ist.
Ich möchte auch unseren Freunden unter den Entwicklern von Betriebssystemen danken: Windows, Linux, NOT APPLE FOLLOW YOU APPLE, FreeBSD usw., die auf ihren erfolgreichen Plattformen so viel Abwärtskompatibilitätsarbeit geleistet haben (Apple erreicht bestenfalls die Top 3 mit Minus, da sie ohne guten Grund ständig alles kaputt machen, aber irgendwie kümmert sich die Community in jeder Version darum, und bis jetzt sind OS X-Container noch nicht vollständig veraltet ... noch nicht.
Aber warte, sagst du? Vergleichen wir nicht Äpfel mit Orangen - eigenständige Softwaresysteme auf einem einzelnen Computer wie Emacs / JDK / Android / Chrome mit Multi-Server-Systemen und APIs wie Cloud-Diensten?
Nun, ich habe gestern darüber getwittert, aber im Larry Wall-Stil von Suck / Rule habe ich das Wort nachgeschlagen, das auf Google- und Amazon-Entwicklerseiten veraltet ist . Obwohl AWS hunderte Male mehr Serviceangebote als GCP bietet, wird in der Entwicklerdokumentation von Google etwa siebenmal häufiger die Ablehnung erwähnt.
Wenn jemand von Google dies liest, ist er wahrscheinlich bereit, Diagramme zu erstellen, die den Donald Trump-Stil zeigen, dass er tatsächlich alles richtig macht und dass ich keine unfairen Vergleiche anstellen sollte, wie z. B. „Die Anzahl der Erwähnungen des Wortes ist abhängig von der Anzahl der Dienste veraltet ".
Aber nach so vielen Jahren ist Google Cloud immer noch die Nummer 3 (ich habe nie einen Artikel über den fehlgeschlagenen Versuch geschrieben, die Nummer 2 zu werden), aber wenn Sie den Insidern glauben, gibt es einige Befürchtungen, dass sie bald auf Nummer 4 fallen könnten.
Ich habe keine Überzeugung Argumente, um Ihre These zu "beweisen". Ich habe nur farbenfrohe Beispiele, die ich über 30 Jahre als Entwickler gesammelt habe. Ich habe bereits die zutiefst philosophische Natur dieses Problems erwähnt; In gewisser Weise wird es in den Entwicklergemeinschaften politisiert. Einige Leute denken , dass Plattform Schöpfer über die Kompatibilität sorgen sollte, während andere glauben , dass dies die Sorge ist Benutzer.(die Entwickler selbst). Einer von zweien. Ist es nicht ein politisches Problem, wenn wir entscheiden, wer die Kosten für gemeinsame Probleme tragen soll?
Das ist also Politik. Und es wird sicherlich wütende Antworten auf meine Rede geben.
Als Nutzer der Google Cloud-Plattform sowie seit zwei Jahren AWS-Nutzer (bei 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 mich nicht aktiv in AWS, daher weiß ich nicht genau, wie oft alte APIs entfernt werden. Es besteht jedoch der Verdacht, dass dies nicht so häufig vorkommt wie bei Google. Und ich bin der festen Überzeugung, dass diese Quelle ständiger Kontroversen und Frustrationen bei GCP eine der größten Einschränkungen für die Entwicklung der Plattform darstellt.
Ich weiß, dass ich keine spezifischen Beispiele für GCP-Systeme genannt habe, die nicht mehr unterstützt werden. Ich kann sagen, dass praktisch alles, was ich verwendet habe, vom Netzwerk (vom ältesten bis zur VPC) bis zum Speicher (Cloud SQL v1-v2), Firebase (jetzt Firestore mit einer völlig anderen API), App Engine (nicht einmal starten), Cloud-Endpunkte und früher ... Ich weiß nicht - absolut alles hat Sie dazu gebracht, den Code in maximal 2-3 Jahren neu zu schreiben, und sie haben die Migration für Sie nie automatisiert, und oft gab es überhaupt keinen dokumentierten Migrationspfad . Als ob es sein sollte.
Und jedes Mal, wenn ich mir AWS anschaue, frage ich mich, warum zum Teufel ich immer noch auf GCP sitze. Sie brauchen eindeutig keine Kunden. Sie wollen Käufer . Verstehst du den Unterschied? Lassen Sie mich erklären.
Google Cloud verfügt über einen Marktplatz, auf dem Nutzer ihre Softwarelösungen anbieten. Um die Auswirkungen eines leeren Restaurants zu vermeiden, mussten sie einige Vorschläge unterbreiten. Daher haben sie mit Bitnami einen Vertrag abgeschlossen, um eine Reihe von Lösungen zu erstellen, die "mit einem Klick" oder "bereitgestellt" werden Ich muss die "Lösungen" selbst schreiben, weil sie keine verdammte Sache lösen. Sie existieren nur als Flaggen, als Marketing-Füller, und Google hat sich nie darum gekümmert, ob eines der Tools tatsächlich funktioniert hat. Ich kenne Produktmanager, die gefahren sind, und ich kann Ihnen versichern, dass es diesen Leuten egal ist.
Nehmen Sie zum Beispiel die Ein-Klick- Bereitstellungslösung Percona... Die Google Cloud SQL-Possen haben mich zu Tode gelangweilt, daher begann ich, einen eigenen Percona-Cluster als Alternative zu erstellen. Und diesmal schien Google einen guten Job zu machen, sie würden mir mit einem Klick Zeit und Mühe sparen!
Gut, großartig, lass uns gehen. Folgen wir dem Link und drücken Sie diese Taste. Wählen Sie "Ja", um allen Standardeinstellungen zuzustimmen und den Cluster für Ihr Google Cloud-Projekt bereitzustellen. Haha, funktioniert nicht. Nichts von dieser Scheiße funktioniert. Das Tool wurde noch nie getestet und begann von der ersten Minute an zu verrotten. Es würde mich nicht überraschen, wenn mehr als die Hälfte der „Lösungen“ für die Ein-Klick-Bereitstellung (jetzt verstehen wir, warum die Angebote) überhaupt nicht funktionieren. Dies ist absolut hoffnungslose Dunkelheit, in die es besser ist, nicht einzutreten.
Google empfiehlt Ihnen jedoch ausdrücklich , diese zu verwenden. Sie wollen, dass du sie kaufst . Für sie ist es eine Transaktion. Sie wollen nicht unterstützen alles . Es ist nicht Teil von Googles DNA. Ja, Ingenieure unterstützen sich gegenseitig, wie meine Geschichte mit Bigtable zeigt. Aber bei Produkten und Dienstleistungen für normale Menschen haben sie immer rücksichtslos alle Dienste eingestellt , die die Rentabilität nicht erreichen, selbst wenn sie Millionen von Benutzern haben.
Dies ist eine echte Herausforderung für GCP, da diese DNA hinter allen Cloud-Angeboten steht. Sie versuchen nichts zu unterstützen; Es ist bekannt, dass sie sich weigern, Software von Drittanbietern (als verwalteten Dienst) zu hostenSolange AWS nicht dasselbe tut und kein erfolgreiches Geschäft aufbaut und wenn Kunden genau dasselbe benötigen. Es erfordert jedoch einige Anstrengungen, um Google dazu zu bringen, etwas zu unterstützen.
Dieses Fehlen einer Kultur der Unterstützung, verbunden mit dem Prinzip „Lass es uns brechen, um es schön zu machen“, entfremdet Entwickler von ihnen.
Und das ist nicht gut, wenn Sie eine langlebige Plattform bauen möchten.
Google wach auf, verdammt. Es ist 2020. Du verlierst immer noch. Es ist Zeit, einen genauen Blick in den Spiegel zu werfen und zu antworten, ob Sie wirklich im Cloud-Geschäft bleiben möchten.
Wenn du bleiben willst, dann hör auf, alles zu zerbrechen... Ihr seid reich. Wir Entwickler sind nicht. Wenn es darum geht, wer die Last der Kompatibilität übernimmt, müssen Sie diese auf sich nehmen. Nicht für uns.
Weil es noch mindestens drei wirklich gute Wolken gibt. Sie winken ihnen zu.
Und jetzt werde ich alle meine kaputten Systeme reparieren. Eh.
Bis zum nächsten Mal!
PS Update nach dem Lesen einiger Diskussionen in diesem Artikel (Diskussionen sind übrigens großartig). Firebase wurde nicht eingestellt und es gibt keine Pläne, die mir bekannt sind. Sie haben jedoch einen bösen Streaming-Fehler, der dazu führt, dass der Java-Client in App Engine gestoppt wird. Einer ihrer Ingenieure hat mir bei diesem Problem geholfen, als ich bei Google gearbeitet habe, , , 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!
Update 3, 31.08.2020. Ich wurde von einem Google-Ingenieur auf dem Cloud Marketplace kontaktiert, der sich als ein alter Freund von mir herausstellte. Er wollte herausfinden, warum C2D nicht funktioniert, und am Ende haben wir herausgefunden: Der Grund ist, dass ich mein Netzwerk vor einigen Jahren erstellt habe und C2D aufgrund des fehlenden Subnetzparameters in den Vorlagen nicht in älteren Netzwerken funktioniert. Ich denke, potenzielle GCP-Benutzer sollten besser sicherstellen, dass sie über genügend vertraute Ingenieure bei Google verfügen ...