Verdammtes Google, ich wollte nicht schon wieder bloggen. Ich habe so viel zu tun. Blogging kostet Zeit, Energie und Kreativität, die ich besser für meine Bücher, , mein Spiel und so weiter nutzen könnte. Aber du hast mich genug verärgert, und ich muss das schreiben.
Also lass uns das klären.
Ich fange mit einer kleinen, aber lehrreichen Geschichte an, aus der Zeit, als ich gerade bei Google angefangen habe. Ich weiß, dass ich in letzter Zeit viel Schlechtes über Google gesagt habe, aber es macht mich traurig, wenn mein eigener Arbeitgeber regelmäßig inkompetente Geschäftsentscheidungen trifft. Man muss jedoch auch sagen: Die interne Infrastruktur von Google ist wirklich außergewöhnlich, man kann mit Sicherheit behaupten, dass es heute nichts Besseres gibt. Die Gründer von Google waren weitaus bessere Ingenieure, als ich es je sein werde, und diese Geschichte bestätigt das nur.
Zuerst ein wenig Hintergrund: Google hat eine Datenspeichertechnologie namens . Dies war eine bemerkenswerte technische Errungenschaft, eine der ersten (wenn nicht sogar die erste) "unendlich skalierbare" Schlüssel-Wert-Datenbanken (Key-Value Store, K/V): im Grunde genommen der Beginn von NoSQL. Heutzutage hält Bigtable in einem ziemlich überfüllten Bereich von K/V-Datenbanken immer noch gut mit, aber zu dieser Zeit (2005) war es einfach beeindruckend.
Eine interessante Anekdote zu Bigtable ist, dass sie interne Objekte im Managementbereich (als Teil der Implementierung) mit dem Namen Tablet-Server hatten, die große Indizes verwalteten, und irgendwann wurden sie zum Engpass beim Skalieren des Systems. Die Ingenieure von Bigtable überlegten, wie sie die Skalierbarkeit umsetzen können, und plötzlich erkannten sie, dass sie Tablet-Server durch andere Bigtable-Speicher ersetzen konnten. So ist Bigtable ein Teil der Bigtable-Implementierung. Diese Speicher sind auf allen Ebenen vorhanden.
Eine interessante Tatsache ist, dass Bigtable für eine gewisse Zeit sehr beliebt und allgegenwärtig innerhalb von Google war, wobei jedes Team sein eigenes Speicher hatte. Bei einem der Freitagsmeetings fragte Larry Page beiläufig: „Warum haben wir mehr als ein Bigtable? Warum nicht einfach nur eines?“ Theoretisch sollte ein Speicher ausreichen, um alle Speicheranforderungen von Google abzudecken. Natürlich sind sie aus praktischen Entwicklungsgründen (zum Beispiel aufgrund der potenziellen Auswirkungen eines Ausfalls) nie auf nur eines umgestiegen, aber die Theorie war interessant. Ein Speicher für das gesamte Universum.Übrigens, weiß jemand, ob Amazon das mit ihrem Sable gemacht hat?)
So oder so, hier ist meine Geschichte.
Zu dieser Zeit arbeitete ich seit etwas mehr als zwei Jahren bei Google, und eines Tages erhielt ich eine E-Mail vom Bigtable-Ingenieurteam mit ungefähr folgendem Inhalt:
Lieber Steve,
Grüße vom Bigtable-Team. Wir möchten Ihnen mitteilen, dass Sie im Rechenzentrum [название дата-центра] eine sehr, sehr alte Bigtable-Binärdatei verwenden. Diese Version wird nicht mehr unterstützt, und wir möchten Ihnen helfen, auf die neueste Version umzusteigen.
Bitte lassen Sie uns wissen, ob Sie etwas Zeit für eine gemeinsame Bearbeitung dieses Anliegens einplanen können.
Alles Gute,
Das Bigtable-Team
Bei Google erhalten Sie eine Menge E-Mails, deshalb habe ich beim ersten Durchsehen etwa Folgendes gelesen:
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 etwas von Ihrer wertvollen Zeit für blablabla einplanen können.
Alles Gute,
Ein Team
Ich hätte es fast sofort gelöscht, aber am Rand meines Bewusstseins verspürte ich ein belastendes, nagendes Gefühl, dass dies nicht ganz wie ein formeller Brief aussieht, obwohl offensichtlich, dass der Empfänger verwechselt wurde, da ich Bigtable nicht genutzt habe.
Aber es war seltsam.
Den Rest des Tages dachte ich abwechselnd an die Arbeit und daran, welchen Typ Haifischfleisch ich in der Mikro-Küche probieren sollte, von denen mindestens drei nah genug waren, um mit einem gezielten Wurf eines Kekses zu treffen, aber der Gedanke an den Brief ließ mich mit einem wachsenden Gefühl der leichten Unruhe nicht los.
Sie haben eindeutig 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. Könnte das ein Fehler sein?
Schließlich gewann die Neugierde die Oberhand und ich ging, um die Borg-Konsole im Rechenzentrum zu überprüfen, das sie erwähnt hatten.
Und natürlich hatte ich das BigTable-Speicher im Management. Was? Ich schaute mir den Inhalt an, und – wow! Es stammte aus dem Codelab-Inkubator, in dem ich die erste Woche meiner Arbeit bei Google im Juni 2005 verbracht hatte. Codelab verlangte, dass Sie Bigtable starten, um einige Werte dort zu speichern, und anscheinend habe ich das Speicher nach dieser Zeit nie geschlossen. Es lief immer noch, obwohl mehr als zwei Jahre vergangen sind.
Es gibt einige bemerkenswerte Aspekte dieser Geschichte. Erstens war der Betrieb von Bigtable so unbedeutend im Maßstab von Google, dass erst zwei Jahre später jemand das überflüssige Speicher bemerkte, und das nur, weil die Binärversion veraltet war. Zum Vergleich: Ich hatte einst 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 viel Geld für eine leere verdammte Datenbank.
Ein weiterer bemerkenswerter Aspekt ist, dass der Speicher nach zwei Jahren immer noch funktioniert. WTF? Rechenzentren kommen und gehen; sie haben Ausfälle, sie führen geplante Wartungen durch, sie ändern sich ständig. Die Hardware wird aktualisiert, die Switches werden ausgetauscht, alles wird ständig verbessert. Wie zur Hölle konnten sie mein Programm trotz all dieser Veränderungen zwei Jahre lang am Laufen halten? Das mag im Jahr 2020 wie eine bescheidene Leistung erscheinen, aber in den Jahren 2005 bis 2007 war es ziemlich beeindruckend.
Und das bemerkenswerteste ist, dass ein fremdes Ingenieurteam aus einem anderen Bundesstaat sich an mich, den Besitzer einer kleinen, nahezu leeren Bigtable-Instanz, die null Traffic in den letzten zwei Jahren hatte, wendet und Hilfe anbietet, um es zu aktualisieren.
Ich habe ihnen gedankt, den Speicher gelöscht, und das Leben ging weiter. Doch dreizehn Jahre später denke ich 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 Dienst, den Sie nutzen] ab August 2020 einstellen werden. Danach können Sie Ihre Instanzen nicht mehr aktualisieren. Wir empfehlen Ihnen, auf die neueste Version zu wechseln, die sich in der Beta-Phase befindet, keine Dokumentation hat, keinen Migrationspfad und die bereits im Voraus mit unserer freundlichen Unterstützung veraltet ist.
Wir setzen alles daran, dass diese Änderung minimale Auswirkungen auf alle Nutzer der Google Cloud-Plattform hat.
Beste Freunde für immer,
Google Cloud-Plattform
Doch ich lese solche Briefe kaum, denn tatsächlich sagen sie folgendes:
Sehr geehrter Empfänger,
Geh zur Hölle. Geh, geh, geh. Lass alles, was du tust, ruhen, denn es ist nicht wichtig. Wichtig ist unsere Zeit. Wir investieren Zeit und Geld, um unser Zeugs am Laufen zu halten, und wir haben genug davon, deshalb werden wir es nicht länger unterstützen. Also schau dir deine verdammten Pläne ab und fang an, in unserer miesen Dokumentation zu graben und in Foren nach Futter zu betteln. Übrigens, unser neues Zeug ist ganz anders als das alte, weil wir das Design ziemlich vermasselt haben, haha, aber das ist dein Problem, nicht unseres.
Wir setzen weiterhin alles daran, dass all deine Entwicklungen innerhalb eines Jahres unbrauchbar werden.
Bitte geh weg,
Google Cloud-Plattform
Und das Ding ist, ich bekomme solche Mails ungefähr einmal im Monat. Es passiert so oft und so beständig, dass sie mich unvermeidlich abgestoßen haben von GCP ins Lager der Cloud-Gegner. Ich möchte nicht länger von ihren proprietären Entwicklungen abhängen, denn es ist tatsächlich einfacher für einen DevOps-Engineer, ein System mit Open-Source auf einer nackten VM zu unterstützen, als mit Googles Politik der Einstellung von 'veralteten' Produkten Schritt zu halten.
Bevor wir zu Google Cloud zurückkehren, denn ich noch lange nicht mit meiner Kritik fertig bin, lassen Sie uns die Arbeit des Unternehmens in einigen anderen Bereichen betrachten. Die Ingenieure von Google sind stolz auf ihre Disziplin in der Softwareentwicklung, und genau das sorgt tatsächlich für Probleme. Stolz ist eine Falle für Unvorsichtige; er hat viele Google-Mitarbeiter dazu gebracht zu glauben, dass ihre Entscheidungen immer richtig sind und dass die Richtigkeit (nach einer gewissen unbestimmten, vagen Definition) wichtiger ist als die Sorge um die Kunden.
Ich werde einige willkürliche Beispiele aus anderen großen Projekten außerhalb von Google nennen, aber ich hoffe, dass Sie dieses Muster überall erkennen werden. Es lautet: Die Abwärtskompatibilität sichert die Lebensfähigkeit und Relevanz von Systemen über Jahrzehnte..
Abwärtskompatibilität ist ein Entwurfsziel aller erfolgreichen Systeme, die dazu bestimmt sind, offen verwendet zu werden, d.h. die als Open Source und/oder nach offenen Standards realisiert sind. Ich habe das Gefühl, dass ich etwas zu Offensichtliches sage, was den meisten unangenehm ist, aber das ist nicht der Fall. Es ist eine politische Frage, deshalb sind Beispiele nötig.
Das erste System, das ich wählen würde, ist das älteste: GNU Emacs. Es ist eine Art Hybrid zwischen Windows-Notepad, dem Betriebssystem-Kernel und der Internationalen Raumstation. Es ist etwas kompliziert zu erklären, aber kurz gesagt ist Emacs eine Plattform, die 1976 (ja, vor fast einem halben Jahrhundert) entwickelt wurde, um Ihre Produktivität beim Programmieren zu steigern, sich jedoch wie ein Texteditor tarnt.
Ich benutze Emacs jeden Tag. Ja, ich benutze auch IntelliJ jeden Tag; es hat sich zu einer mächtigen Plattform entwickelt. Aber das Schreiben von Erweiterungen für IntelliJ ist eine viel ambitioniertere und komplexere Aufgabe als das für Emacs. Und noch wichtiger: 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 nutzen, die in den mittleren 80er-Jahren für Emacs geschrieben wurden, wenn nicht sogar früher. Gelegentlich benötigen sie kleine Anpassungen, aber das kommt wirklich ziemlich selten vor. Ich kenne nichts von dem, was ich jemals für Emacs geschrieben habe (und ich habe eine Menge geschrieben), für das ich die Architektur neu gestalten müsste.
In Emacs gibt es eine Funktion namens make-obsolete für veraltete Entitäten. Die Terminologie von Emacs für grundlegende Computerbegriffe (wie „Fenster“) weicht oft von den Branchenkonventionen ab, da Emacs sie schon vor langer Zeit eingeführt hat. Dies ist eine typische Gefahr für diejenigen, die ihrer Zeit voraus sind: Alle Ihre Begriffe können falsch sein. Aber in Emacs gibt es tatsächlich das Konzept der Veraltung, das in ihrem Jargon obsolescence genannt wird. Obsoleszenz.
Doch 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 besprechen werden) bedeutet der Status eines veralteten APIs hauptsächlich: „Sie sollten diesen Ansatz wirklich nicht verwenden, denn auch wenn er funktioniert, leidet er unter verschiedenen Nachteilen, die wir hier auflisten werden. Aber letztendlich liegt es an Ihnen, zu entscheiden.“
In der Welt von Google bedeutet der Status eines veralteten Produkts: „Wir brechen unsere Verpflichtungen Ihnen gegenüber.“ Das ist in der Tat so. Im Grunde bedeutet das, dass sie Sie dazu bringen werden, regelmäßig einige Arbeiten zu leisten, möglicherweise viel Arbeit, als Strafe dafür, dass Sie an sie geglaubt haben. : Wir bieten die beste Software. Die schnellste! Sie befolgen einfach die Anweisungen, starten Ihre Anwendung oder Ihren Dienst, und dann - zack, nach einem Jahr oder zwei ist es kaputt.
Das ist so, als würde man ein gebrauchtes Auto verkaufen, das genau nach 1500 km kaputtgeht.
Das sind zwei völlig verschiedene philosophische Definitionen von "Veralterung". Die Google-Definition riecht nach . Ich glaube nicht, dass es sich hierbei tatsächlich um geplante Veralterung im gleichen Sinne handelt wie bei Apple. Aber Google plant definitiv, Ihre Programme auf indirekte Weise kaputt zu machen. Ich weiß das, weil ich über 12 Jahre als Software-Ingenieur dort gearbeitet habe. Es gibt vage interne Richtlinien, wie weit die Rückwärtskompatibilität eingehalten werden sollte, aber letztendlich hängt das von jedem einzelnen Team oder Dienst ab. Es gibt keine Empfehlungen auf Unternehmens- oder Ingenieurebene, und die kühnste Empfehlung bezüglich Veralterungszyklen ist: "Versuchen Sie, den Kunden 6-12 Monate Zeit für ein Upgrade zu geben, bevor Sie ihr gesamtes System kaputtmachen."
Das Problem ist viel ernster, als sie denken, und es wird noch viele Jahre bestehen bleiben, weil Kundendienst nicht Teil ihrer DNA ist. Weitere Informationen dazu finden Sie weiter unten.
Im Moment wage ich die kühne Behauptung, dass Emacs weitgehend erfolgreich ist, und sogar hauptsächlich weil sie so ernsthaft mit der Rückwärtskompatibilität umgehen. Tatsächlich ist dies die These unseres Artikels. Erfolgreiche, langlebige Open-Source-Systeme verdanken ihren Erfolg den Mikrogemeinschaften, die seit Jahrzehnten rund um Erweiterungen/Pluginsexistieren. Das ist das Ökosystem. Ich habe bereits über die Essenz von Plattformen und ihre Bedeutung nachgedacht und darüber, dass Google in seiner gesamten Unternehmensgeschichte nie verstanden hat, was es braucht, um eine erfolgreiche offene Plattform zu schaffen, mit Ausnahme von Android oder Chrome.
Eigentlich sollte ich Android kurz erwähnen, denn Sie haben wahrscheinlich daran gedacht.
Erstens, Android ist nicht Google. Sie haben kaum etwas miteinander gemein. Android ist ein Unternehmen, das im Juli 2005 von Google übernommen wurde. Dieses Unternehmen durfte mehr oder weniger unabhängig arbeiten und blieb in den vergangenen Jahren weitgehend unberührt. Android ist ein umstrittener technischer Stack und ebenso umstrittene Organisation. Wie ein Google-Mitarbeiter ausdrückte: „Man kann einfach nicht so in Android einsteigen.“
In einem früheren Artikel habe ich bereits darüber nachgedacht, wie schlecht einige der frühen Designentscheidungen bei Android waren. Verdammt, als ich diesen Artikel schrieb, waren sie damit beschäftigt, diesen Mist namens „Sofort-Apps“ einzuführen, der jetzt (Überraschung!) , und ich fühle mit Ihnen, wenn Sie so naiv waren, Google zu vertrauen und Ihre Inhalte in diese Sofort-Apps zu übertragen.
Aber hier gibt es einen Unterschied, einen wesentlichen Unterschied: Die Leute von Android wissen wirklich, wie wichtig Plattformen sind, und sie bemühen sich intensiv, die Funktionsfähigkeit älterer Android-Anwendungen aufrechtzuerhalten. Tatsächlich sind ihre Bemühungen um die Rückwärtskompatibilität so extrem, dass ich, während meines kurzen Aufenthalts bei der Android-Abteilung vor einigen Jahren, versucht habe, sie davon zu überzeugen, die Unterstützung für einige der ältesten Geräte und APIs einzustellen (ich lag falsch, wie bei vielen anderen Dingen in der Vergangenheit und in der Gegenwart. Entschuldigung, Android-Team! Jetzt, wo ich in Indonesien war, verstehe ich, warum sie so wichtig sind).
Die Leute von Android halten die Rückwärtskompatibilität bis zu fast unvorstellbaren Extremen aufrecht, was eine riesige Menge an veralteten technischen Schulden in ihren Systemen und Werkzeugketten aufbaut. Oh mein Gott, Sie müssten einige verrückte 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 möchten wirklich nicht wie Google sein, das nicht in der Lage ist, langlebige Plattformen zu schaffen, aber Android weiß, wie man es macht. Und deshalb verhält sich Google in einem Punkt sehr weise: Es erlaubt den Nutzern von Android, alles nach ihren Vorstellungen zu tun.
Allerdings waren die Instant-Apps für Android eine ziemlich dumme Idee. Und wissen Sie warum? Weil sie einmal Ihre App umschreiben und neu gestalten mussten! Als ob die Leute einfach mal so zwei Millionen Apps neu schreiben würden. Ich nehme an, dass die Instant-Apps die Idee eines Googlers waren.
Aber hier gibt es einen Unterschied. Die Abwärtskompatibilität ist mit hohen Kosten verbunden. Android trägt selbst die Last dieser Kosten, während Google darauf besteht, dass diese Last Sievon dem zahlenden Kunden getragen wird.
Sie können das Engagement von Android für die Rückwärtskompatibilität in seinen API-Schnittstellen sehen. Wenn Sie vier oder fünf verschiedene Subsysteme haben, um buchstäblich dasselbe zu tun, ist das ein sicheres Zeichen für ein Engagement für Rückwärtskompatibilität. In der Welt der Plattformen ist dies gleichbedeutend mit Loyalität gegenüber Ihren Kunden und Ihrem Markt.
Das Hauptproblem von Google hier ist ihr Stolz auf ihre technische Hygiene. Sie mögen es nicht, wenn es viele verschiedene Wege gibt, um dasselbe zu tun, insbesondere wenn alte, weniger wünschenswerte Methoden neben neuen, ausgefalleneren Methoden existieren. Das erhöht die Lernkurve für Neueinsteiger im System, es verstärkt die Supportbelastung veralteter APIs, es verlangsamt die Einführung neuer Funktionen, und die größte Sünde – es sieht nicht gut aus. Google ist wie die Herzogin aus ‚Alice im Wunderland‘ von Tim Burton:
Die Herzogin:
– Alice, weißt du, wovor ich am meisten Angst habe?
– Vor dem Verfall der Aristokratie?
– Ich habe mich gefürchtet, dass ich hässliche Enkelkinder habe..
Um den Kompromiss zwischen Schönheit und Praktikabilität 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 Fülle von veralteten APIs. Das Veralten ist unter Java-Entwicklern sehr verbreitet, sogar häufiger als in den meisten anderen Programmiersprachen. In der Java-Sprache selbst, in den Hauptbibliotheken, gibt es ständig neue veraltete APIs.
Nehmen wir nur ein Beispiel von tausend: wird als veraltet angesehen. Es ist seit der Einführung von Java 1.2 im Dezember 1998 veraltet. Es sind 22 Jahre vergangen, seit es als veraltet gilt.
Aber mein tatsächlicher Code in der Produktion schließt immer noch Threads jeden Tag. Ist das schlecht? Überhaupt nicht! Natürlich, wenn ich den Code heute neu schreiben würde, würde ich es anders angehen. Aber der Code meines Spiels, das in den letzten zwei Jahrzehnten Hunderttausende von Menschen glücklich gemacht hat, wurde mit der Funktion zum Schließen von Threads geschrieben, die zu lange hängen, und ich hatte nie Grund, ihn zu ändern. Ich kenne mein System besser als jeder andere, ich habe buchstäblich 25 Jahre Erfahrung damit in der Produktion, und ich kann mit Sicherheit sagen: In meinem Fall ist das Schließen dieser bestimmten Arbeits-Threads völlig unbedenklich.. Es lohnt sich nicht, Zeit und Mühe mit dem Umschreiben dieses Codes zu verschwenden, und man muss Larry Ellison (wahrscheinlich) danken, dass Oracle mich nicht gezwungen hat, ihn neu zu schreiben.
Wahrscheinlich kennt sich Oracle auch mit Plattformen aus. Wer weiß das schon.
Die Beweise finden Sie in allen wichtigen Java-APIs, die von Wellen der Veralterung durchzogen sind, ähnlich wie die Spuren von Gletschern im Canyon. In der Java Swing-Bibliothek gibt es leicht fünf oder sechs verschiedene 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 eine API nur dann wirklich entfernen, wenn die Schnittstelle ein eklatantes Sicherheitsproblem verursacht.
Hier ist das Dilemma, meine Damen und Herren: Wir, die Softwareentwickler, sind alle sehr beschäftigt, und in jedem Bereich der Software stehen wir vor alternativen Wettbewerbern. Zu jedem Zeitpunkt ziehen Programmierer in Sprache X Sprache Y als möglichen Ersatz in Betracht. Oh, glauben Sie mir nicht? Wollen Sie Swift nennen? Als ob alle zu Swift migrieren und niemand es ablehnt, richtig? Wow, wie wenig Sie wissen. Unternehmen betrachten die Kosten für doppelte mobile Entwicklungsteams (iOS und Android) — und beginnen zu realisieren, dass diese Plattform übergreifenden Entwicklungssysteme mit komischen Namen wie Flutter und React Native tatsächlich funktionieren und es damit möglich ist, die Größe ihrer mobilen Teams zu halbieren oder ihre Produktivität zu verdoppeln. Es geht um echtes Geld. Ja, es gibt Kompromisse, aber andererseits, Geld.
Nehmen wir hypothetisch an, Apple hätte aus Dummheit ein Beispiel an Guido van Rossum genommen und erklärt, dass Swift 6.0 nicht rückwärtskompatibel zu Swift 5.0 ist, ähnlich wie Python 3 nicht mit Python 2 kompatibel ist.
Ich habe diese Geschichte vielleicht vor zehn Jahren erzählt, aber vor fünfzehn Jahren war ich mit Guido beim O’Reilly’s Foo Camp und saß im Zelt mit Paul Graham und einer Menge großer Namen. Wir saßen in der unerträglichen Hitze und warteten darauf, dass Larry Page mit seinem Privathelikopter einflog, während Guido monoton über „Python 3000“ brabbelte, das er nach der Anzahl der Jahre benannte, die benötigt werden, um dorthin zu migrieren. Wir fragten ihn ständig, warum er die Kompatibilität breche, und er antwortete: „Unicode“. Und wir fragten, wenn wir unseren Code umschreiben müssten, welche anderen Vorteile wir sehen würden. 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 der Support für Python 2 eingestellt wurde, also machen Sie sich mal bereit.
… und so weiter. Der Lebenszyklus.
Aber das Ding ist, dass jeder Entwickler die Wahl hat. Und wenn sie gezwungen werden, ihren Code oft umzuschreiben, könnten sie darüber nachdenken und auch anderen zu sehen ist. Varianten. Sie sind nicht Ihre Gefangenen, egal wie sehr Sie das wünschen. Sie sind Ihre Gäste. Python bleibt eine sehr beliebte Programmiersprache, aber verdammte Axt, Python 3(000) hat ein solches Chaos in seinen Gemeinschaften und bei seinen Nutzern angerichtet, dass die Folgen seit fünfzehn Jahren nicht behoben werden können.
Wie viele Python-Programme wurden wegen dieser Rückwärtskompatibilität in Go (oder Ruby oder einer anderen Alternative) neu geschrieben? Wie viel neue Software wurde in etwas anderem als Python geschrieben, obwohl es auf Python hätte geschrieben werden können, wenn Guido nicht das ganze Dorf niedergebrannt hätte? Schwer zu sagen, aber Python hat eindeutig gelitten. Es ist ein riesiges Durcheinander, und alle verlieren. Angenommen, Apple folgt Guidos Beispiel und bricht die Kompatibilität. Was denken Sie, wird dann passieren? Nun, vielleicht 80-90% der Entwickler werden ihre Software, wenn möglich, neu schreiben. Mit anderen Worten, 10-20% der Nutzerbasis wechseln automatisch zu einer konkurrierenden Sprache, wie z.B. Flutter.
Tun Sie dies ein paar Mal – und Sie verlieren die Hälfte Ihrer Nutzerbasis. Wie im Sport, bedeutet auch in der Programmierwelt die aktuelle Form alles.
Mach das ein paar Mal und du verlierst die Hälfte deiner Nutzerbasis. Wie im Sport zählt auch in der Programmierung die aktuelle Form. alles. Jeder, der in fünf Jahren die Hälfte seiner Nutzer verliert, gilt als großer gescheiterter Versuch. Sie müssen am Puls der Zeit in der Welt der Plattformen bleiben. Doch genau hier wird das Aus für die Unterstützung älterer Versionen im Laufe der Zeit Ihr Untergang sein. Denn jedes Mal, wenn Sie einen Teil Ihrer Entwickler verlieren, verlieren Sie (a) sie für immer, weil sie aufgrund des Vertragsbruchs verärgert über Sie sind, und (b) übergeben sie an Ihre Konkurrenten.
Ironischerweise habe ich auch dazu beigetragen, Google in diese Diva zu verwandeln, die die Rückwärtskompatibilität ignoriert, als ich Grok entwickelt habe, ein System zur Analyse und Verständnis von Quellcode, das die Automatisierung und das Toolkit auf Basis des Codes erleichtert - ähnlich wie eine IDE, aber hier speichert ein Cloud-Dienst materialisierte Ansichten aller Milliarden Zeilen Quellcode von Google in einem großen Datenspeicher.
Grok bot den Google-Entwicklern eine leistungsstarke Grundlage für automatisiertes Refactoring über die gesamte Codebasis hinweg (buchstäblich bei ganz Google). 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 betroffen haben! Dadurch können Sie bei Änderungen sicherstellen, dass jeder Verbraucher Ihrer API auf die neue Version aktualisiert wurde. In der Realität können Sie häufig mit dem Tool Rosie, das sie entwickelt haben, den Prozess vollständig automatisieren.
Dies ermöglicht es dem Google-Code, intern nahezu übernatürlich 'sauber' zu sein, da diese robotergestützten Dienste im gesamten System herumlaufen und automatisch alles aufräumen, wenn sie SomeDespicablyLongFunctionName in SomeDespicablyLongMethodName umbenennen, weil jemand beschlossen hat, dass es ein unschöner Enkel ist, den man beseitigen sollte.
Und, ganz ehrlich, 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 Gewohnheit, kontinuierlich zu refaktorisieren. Wenn Sie etwas N-mal neu starten, bedeutet das, dass Sie es nicht nur N-1 Mal ruiniert haben, sondern mit der Zeit wird klar, dass Sie es wahrscheinlich auch beim N-ten Versuch ruiniert haben. Aber im Großen und Ganzen bleiben sie über diesem Tumult und halten den Code 'sauber'.
Probleme entstehen, wenn versucht wird, diese Haltung den Cloud-Kunden und Nutzern anderer APIs aufzuzwingen.
Ich habe Sie ein wenig mit Emacs, Android und Java vertraut gemacht; schauen wir uns die letzte erfolgreiche Langzeitplattform an: das Web selbst. Können Sie sich vorstellen, wie viele Iterationen HTTP seit 1995 durchlaufen hat, als wir noch 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, bei der alles richtig zusammengesetzt ist, und wie Sie bereits erraten haben, funktioniert 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 ihre großartige Arbeit in Bezug auf die Abwärtskompatibilität auf ihren erfolgreichen Plattformen (Apple bekommt bestenfalls eine drei minus, da sie ständig alles ohne triftigen Grund beschädigen, aber das Community kommt irgendwie bei jedem Release damit zurecht und die Container mit OS X sind noch nicht vollständig veraltet... vorerst).
Aber warten Sie, werden Sie sagen. Vergleichen wir nicht Äpfel mit Birnen – autonome Softwaresysteme auf einem Gerät, wie Emacs/JDK/Android/Chrome, mit Mehrserver-Systemen und APIs, wie sie in Cloud-Diensten vorkommen?
Nun, ich habe gestern darüber auf Twitter geschrieben, aber im Stil von Larry Wall (dem Schöpfer der Programmiersprache Perl – Anmerkung der Übersetzerin) nach dem Prinzip „Scheiße/Rulz“ suchte ich nach dem Wort deprecated auf den Entwicklerseiten von Google und Amazon. Und obwohl AWS über hunderte mal mehr Dienstleistungsangebote verfügt als GCP, erwähnt die Google-Dokumentation für Entwickler das Thema Abwärtskompatibilität etwa siebenmal häufiger.
Wenn jemand von Google das liest, dann sind sie sicherlich bereit, Diagramme im Stil von Donald Trump zu präsentieren, die tatsächlich alles richtig machen, und ich sollte keine unfairen Vergleiche anstellen, wie zum Beispiel "die Anzahl der Erwähnungen des Wortes deprecated im Verhältnis zur Anzahl der Dienste".
Aber nach all den Jahren bleibt Google Cloud nach wie vor der Dienst Nr. 3 (ich habe nie den Artikel über den gescheiterten Versuch, Nr. 2 zu werden, geschrieben), aber wenn man Insidern Glauben schenkt, gibt es einige Befürchtungen, dass sie bald auf Nr. 4 abrutschen könnten.
Ich habe keine stichhaltigen Argumente, um meine These zu "beweisen". Alles, was ich habe, sind lebhafte Beispiele, die ich über 30 Jahre als Entwickler gesammelt habe. Ich habe schon die tiefphilosophische Natur dieses Problems erwähnt; in gewissem Sinne ist es politisiert in den Entwicklergemeinschaften. Einige glauben, dass Ersteller Plattformen sich um die Kompatibilität kümmern sollten, während andere der Meinung sind, dass es die Verantwortung der Nutzer (der Entwickler selbst) ist. Entweder das oder das. Ist es nicht tatsächlich eine politische Frage, wenn wir entscheiden, wer die Kosten für gemeinsame Probleme tragen sollte?
Also, das ist die Politik. Und sicher wird es empörte Reaktionen auf meinen Beitrag geben.
Wie Benutzer Als Benutzer der Google Cloud-Plattform sowie als AWS-Nutzer über zwei Jahre (während meiner Tätigkeit bei Grab) kann ich sagen, dass es einen enormen Unterschied zwischen den Philosophien von Amazon und Google gibt, wenn es um Prioritäten geht. Ich bin kein aktiver Entwickler bei AWS, daher weiß ich nicht genau, wie häufig sie alte APIs entfernen. Es gibt jedoch den Verdacht, dass dies bei weitem nicht so häufig geschieht wie bei Google. Und ich glaube aufrichtig, dass diese ständigen Streitfragen und Enttäuschungen in der GCP einer der größten Faktoren sind, die das Wachstum der Plattform behindern.
Ich weiß, dass ich keine konkreten Beispiele für GCP-Systeme genannt habe, deren Unterstützung eingestellt wurde. Ich kann sagen, dass praktisch 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 (da brauchen wir gar nicht erst anzufangen), Cloud Endpoint und bis hin zu… ich weiß nicht – absolut alles das hatte mich gezwungen, den Code spätestens alle 2-3 Jahre neu zu schreiben, und sie haben niemals die Migration für euch automatisiert, sondern oft . Es scheint, als wäre das einfach so vorgesehen.
Und jedes Mal, wenn ich mir AWS ansehe, frage ich mich, warum ich immer noch auf GCP sitze. Offensichtlich brauchen sie keine Kunden. Sie brauchen Käufer. Verstehen Sie den Unterschied? Lassen Sie es mich erklären.
Google Cloud hat einen , auf dem Menschen ihre Softwarelösungen anbieten. Um den Effekt eines leeren Restaurants zu vermeiden, mussten sie ihn mit einigen Angeboten füllen. Deshalb haben sie einen Vertrag mit Bitnami abgeschlossen, um eine Menge Lösungen zu erstellen, die „mit einem Klick bereitgestellt“ werden. Oder ich muss selbst „Lösungen“ schreiben, weil diese überhaupt nichts lösen. Sie existieren einfach nur als Platzhalter, als Marketingfüllmaterial, und Google hat sich nie darum gekümmert, ob eines dieser Tools wirklich funktioniert. Ich kenne Produktmanager, die dabei waren, und ich kann Ihnen versichern, dass diesen Personen alles egal ist.
Nehmen wir zum Beispiel eine Lösung, die angeblich „mit einem Klick bereitgestellt“ werden kann. . Ich bin Google Cloud SQL überdrüssig geworden, also habe ich begonnen, die Erstellung eines eigenen Percona-Clusters als Alternative in Betracht zu ziehen. Und diesmal schien Google es gut zu machen, sie wollten mir mit einem einzigen Klick Zeit und Mühe sparen!
Na gut, dann lass uns loslegen. Lass uns auf den Link klicken und diesen Knopf drücken. Wir wählen „Ja“, um allen Standardeinstellungen zuzustimmen und den Cluster in unserem Google-Cloud-Projekt bereitzustellen. Haha, funktioniert nicht. Nichts von diesem Mist funktioniert. Das Tool wurde nie getestet und hat von der ersten Minute an begonnen zu verderben. Es würde mich nicht überraschen, wenn mehr als die Hälfte der „Lösungen“ für die Bereitstellung mit einem Klick (jetzt verstehen wir, warum in Anführungszeichen) überhaupt nicht funktioniert. Es ist absolut düster, besser nicht hineinzugehen.
Aber Google fordert dich direkt auf, es zu nutzen. Sie möchten, dass du es kaufst.Für sie ist es eine Transaktion. Sie wollen nichts unterstützen.Das gehört nicht zur DNA von Google. Ja, Ingenieure unterstützen sich gegenseitig, wie meine Geschichte mit Bigtable zeigt. Aber bei den Produkten und Dienstleistungen für die breite Masse waren sie immer gnadenlos beim , die nicht mit den Rentabilitätsstandards übereinstimmt, selbst wenn sie Millionen von Nutzern hat.
Und das stellt ein echtes Problem für GCP dar, denn diese DNA liegt allen Cloud-Angeboten zugrunde. Sie sind nicht bereit, etwas zu unterstützen; es ist bekannt, dass sie sich weigern, jegliche Drittanbieter-Software zu hosten (wie ein verwalteter Service). bis AWS das Gleiche tut und ein erfolgreiches Geschäft darum aufbaut, und wenn die Kunden buchstäblich dasselbe verlangen. Allerdings sind gewisse Anstrengungen erforderlich, um Google dazu zu bringen, etwas zu unterstützen.Diese 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 sehr gut, wenn man eine langlebige Plattform aufbauen möchte.
Google, wach auf, verdammte Axt. Es ist jetzt das Jahr 2020. Du verlierst immer noch. Es wird Zeit, sich ernsthaft im Spiegel anzusehen und zu überlegen, ob du wirklich im Cloud-Geschäft bleiben möchtest.
Wenn du bleiben willst, dann
hör auf, alles zu zerbrechen. hör auf, alles kaputt zu machen. Leute, Sie sind doch reich. Wir Entwickler sind es nicht. Daher müssen Sie, wenn es um Kompatibilität geht, die Verantwortung übernehmen. Nicht wir.
Denn es gibt mindestens drei wirklich gute Clouds, die darum buhlen.
Jetzt gehe ich zurück und repariere all meine kaputten Systeme. Ach ja.
Bis zum nächsten Mal!
P. S. Update nach dem Lesen einiger Diskussionen zu diesem Artikel (die Diskussionen sind übrigens großartig). Der Support für Firebase wurde nicht eingestellt, und ich kenne keine Pläne, dies zu tun. Allerdings gibt es einen nervigen Streaming-Bug, der dazu führt, dass der Java-Client in App Engine stoppt. Einer ihrer Ingenieure half mir, dieses Problem zu lösen, als ich bei Google arbeitete, aber sie haben den Bug niemals wirklich behoben, sodass ich mit einer schlechten Lösung leben muss und die GAE-Anwendung jeden Tag neu starten muss. So geht es schon seit vier Jahren! Jetzt haben sie Firestore. Es wird viel Arbeit erfordern, um darauf umzusteigen, da es ein ganz anderes System ist, und der Firebase-Bug wird niemals behoben werden. Was ist die Schlussfolgerung? Sie können Hilfe bekommen, Wenn Sie in einem Unternehmen arbeiten,Scheint es, dass ich der Einzige bin, der Firebase auf GAE verwendet, denn ich schreibe weniger als 100 Schlüssel in einer komplett nativen Anwendung, und sie funktioniert alle paar Tage aufgrund eines bekannten Fehlers nicht mehr. 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 sagten, dass AWS normalerweise niemals die Unterstützung für Dienste einstellt, und SimpleDB ist ein hervorragendes Beispiel dafür. Meine Annahme, dass AWS nicht an so einem Problem mit der Einstellung von Unterstützung leidet wie Google, scheint bestätigt zu sein.
Außerdem habe ich bemerkt, dass das Google App Engine-Team vor 20 Tagen das Hosting einer kritischen Go-Bibliothek sabotiert hat, indem sie die Anwendung GAE von einem der Hauptentwickler von Go ausgeschlossen haben. Das war wirklich dumm.
Ich habe endlich gehört, dass die Google-Mitarbeiter dieses Thema bereits diskutieren und insgesamt mit mir übereinstimmen (ich liebe euch, Leute!). Es scheint jedoch, dass sie das Problem als unlösbar betrachten, da es in der Google-Kultur nie die richtige Struktur für Anreize gab. Ich denke, es wäre gut, etwas Zeit zu finden, um die absolut erstaunlichen Erfahrungen zu besprechen, die ich mit den AWS-Ingenieuren gemacht habe, als ich bei Grab gearbeitet habe. Hoffentlich irgendwann in der Zukunft!
Ja, im Jahr 2005 gab es tatsächlich verschiedene Arten von Hai-Fleisch an einem riesigen Buffet im Gebäude 43, und mir hat das Fleisch der Hammerhaie am besten geschmeckt. Allerdings haben Larry und Sergey bis 2006 alle ungesunden Snacks abgeschafft. Also gab es während der Geschichte von Bigtable im Jahr 2007 wirklich keine Haie, und ich habe euch dreist belogen.
Als ich vor vier Jahren (ungefähr) einen Blick auf die Cloud Bigtable warf, war der Preis genau so. Es scheint, dass er jetzt ein wenig gesunken ist, aber das ist immer noch furchtbar viel für eine leere Datenspeicherung, insbesondere angesichts der Tatsache, dass meine erste Geschichte zeigt, wie unbedeutend eine leere große Tabelle in ihrem Maßstab ist.
Es tut mir leid, dass ich die Apple-Community verletzt habe und nichts Positives über Microsoft gesagt habe usw. Ihr habt alle recht, ich schätze die Diskussionen, die dieser Artikel ausgelöst hat, sehr! Manchmal muss man ein wenig Aufregung erzeugen, um das Gespräch anzustoßen, versteht ihr?
Danke fürs Lesen.
Update 2, 19.08.2020. Stripe !
Update 3, 31.08.2020. Ich wurde von einem Ingenieur bei Google im Cloud Marketplace kontaktiert, der ein alter Freund von mir ist. Er wollte herausfinden, warum C2D nicht funktioniert, und schließlich fanden wir heraus, dass ich mein Netzwerk vor einigen Jahren erstellt hatte und C2D in veralteten Netzwerken aufgrund eines fehlenden Subnetzparameters in ihren Vorlagen nicht funktioniert. Ich denke, potenzielle GCP-Nutzer sollten sicherstellen, dass sie genug vertraute Ingenieure bei Google haben...
Quelle: habr.com
