Demonios, Google, no quería volver a escribir en el blog. Tengo tantas cosas que hacer. Hacer un blog requiere tiempo, energía y creatividad que podría utilizar por otros medios: mis libros, , mi juego y así sucesivamente. Pero me has molestado lo suficiente como para que tenga que escribir esto.
Así que pongámonos al día.
Comenzaré con una pequeña, pero significativa historia de cuando empecé a trabajar en Google. Sé que últimamente he hablado mucho mal de Google, pero me frustra cuando mi propia empresa toma decisiones comerciales incompetentes de manera regular. Sin embargo, hay que reconocer que la infraestructura interna de Google es realmente extraordinaria; se puede afirmar sin dudar que hoy no hay nada mejor. Los fundadores de Google eran mucho mejores ingenieros de lo que jamás seré, y esta historia solo confirma ese hecho.
Primero un poco de contexto: Google tiene una tecnología de almacenamiento de datos llamada . Este fue un logro técnico impresionante, uno de los primeros (si no el primero) almacenamiento de pares «clave-valor» 'infinita' (key-value store, K/V): en esencia, el comienzo de NoSQL. Hoy en día, Bigtable todavía se siente bien en un espacio bastante saturado de almacenes K/V, pero en ese momento (2005) era increíblemente asombroso.
Un detalle curioso sobre Bigtable es que tenían objetos internos de plano de control (como parte de la implementación) llamados tablet-servers, con grandes índices, y en algún momento se convirtieron en un cuello de botella al escalar el sistema. Los ingenieros de Bigtable se devanaban los sesos para implementar la escalabilidad y de repente se dieron cuenta de que podían reemplazar los tablet-servers por otros almacenes de Bigtable. Así que Bigtable es parte de la implementación de Bigtable. Estos almacenes están en todos los niveles.
Otro detalle interesante es que, por algún tiempo, Bigtable se volvió popular y omnipresente dentro de Google, y cada equipo tenía su propio almacenamiento. Así que, en una de las reuniones del viernes, Larry Page preguntó casualmente: "¿Por qué tenemos más de un Bigtable? ¿Por qué no simplemente uno solo?" Teóricamente, un solo almacenamiento debería haber sido suficiente para todas las necesidades de almacenamiento de Google. Claro, nunca se pasaron a uno solo por razones prácticas de desarrollo (como las implicaciones de una posible falla), pero la teoría era interesante. Un almacenamiento para todo el universo (por cierto, ¿alguien sabe si Amazon hizo algo parecido con su Sable?)
De todos modos, aquí está mi historia.
En ese momento, llevaba poco más de dos años trabajando en Google, y un día recibí un correo del equipo de ingeniería de Bigtable que decía algo así:
Estimado Steve,
Saludos del equipo de Bigtable. Queremos informarte que en el centro de datos [nombre del centro de datos] estás usando un archivo binario de Bigtable muy, muy antiguo. Esta versión ya no se soporta, y queremos ayudarte a actualizar a la última versión.
Por favor, háznos saber si puedes programar un tiempo para trabajar juntos en este asunto.
Todo lo mejor,
El equipo de Bigtable
En Google, recibes mucho correo, así que a primera vista leí algo así:
Estimado destinatario,
Hola de algún equipo. Queremos informarte que bla bla bla bla bla. Bla bla bla bla bla bla, y bla bla bla de inmediato.
Por favor, háznos saber si puedes dedicar parte de tu valioso tiempo a bla bla bla.
Todo lo mejor,
Algún equipo
Casi lo borré de inmediato, pero en la frontera de mi conciencia sentí una pesada y molesta sensación de que esto no era exactamente una carta formal, aunque obviamente, hubo un error con el destinatario, porque yo no había usado Bigtable.
Pero eso era extraño.
El resto del día alterné entre pensar en el trabajo y en qué tipo de carne de tiburón probar en la micrococina, de las cuales al menos tres estaban lo suficientemente cerca como para llegar con un lanzamiento certero de una galleta, pero la idea del correo no me dejó con una creciente sensación de leve inquietud.
Claramente mencionaron mi nombre. Y la carta fue enviada a mi dirección de correo electrónico, no a la de nadie más, y no es un cc: o bcc:. El tono es muy personal y directo. ¿Podría ser un error?
Finalmente, la curiosidad me ganó y fui a echar un vistazo a la consola Borg en el centro de datos que mencionaron.
Y, por supuesto, tenía a mi cargo un almacenamiento BigTable. ¿Qué? Eché un vistazo a su contenido y ¡vaya! Era del incubador Codelab, donde estuve durante la primera semana de trabajo en Google en junio de 2005. Codelab te obligaba a lanzar Bigtable para que insertarás algunos valores, y aparentemente no cerré el almacenamiento después de eso. Aún estaba funcionando, aunque habían pasado más de dos años.
Hay varios aspectos notables en esta historia. Primero, el funcionamiento de Bigtable era tan insignificante en comparación con Google que solo alguien notó el almacenamiento sobrante después de dos años, y solo porque la versión del binario estaba desactualizada. Para ponerlo en perspectiva, alguna vez consideré usar para mi juego en línea. En ese tiempo, este servicio costaba alrededor de $16,000 al año por un vacío Bigtable en GCP. No digo que te engañen, pero, en mi opinión personal, es mucho dinero por una base de datos completamente vacía.
Otro aspecto notable es que el almacenamiento siguió funcionando después de dos años. ¿Qué demonios? Los centros de datos vienen y van; enfrentan interrupciones, pasan por mantenimiento programado, están en constante cambio. El hardware se actualiza, los conmutadores se cambian de lugar, todo se mejora constantemente. ¿Cómo, diablos, lograron mantener mi programa en funcionamiento durante dos años considerando todos estos cambios? Puede parecer un logro modesto en 2020, pero entre 2005 y 2007 fue bastante impresionante.
Y el aspecto más sorprendente es que un equipo de ingeniería externo de algún otro estado se comunica conmigo, el propietario de una pequeña y prácticamente vacía instancia de Bigtable, que tiene cero tráfico durante los últimos dos años, y ofrecen ayuda para actualizarla.
Les agradecí, eliminé el almacenamiento y la vida siguió su curso. Pero trece años después, todavía pienso en esa carta. Porque a veces recibo cartas similares de Google Cloud. Se ven así:
Estimado usuario de Google Cloud,
Le recordamos que estamos descontinuando el servicio [importante servicio que está utilizando] a partir de agosto de 2020, después de lo cual no podrá actualizar sus instancias. Recomendamos migrar a la última versión que está en fase beta, la cual no tiene documentación, no ofrece un camino de migración y que ha quedado obsoleta con nuestra cortesía.
Nos esforzamos para que este cambio afecte mínimamente a todos los usuarios de la plataforma Google Cloud.
Mejores amigos para siempre,
Plataforma en la nube de Google
Pero casi no leo tales cartas, porque en realidad dicen lo siguiente:
Estimado destinatario,
Vete al diablo. Vete, vete, vete. Deja todo lo que estás haciendo porque no importa. Lo que importa es nuestro tiempo. Estamos gastando tiempo y dinero manteniendo nuestra porquería, y estamos cansados de esto, así que ya no la mantendremos. Así que olvida tus malditos planes y empieza a hurgar en nuestra maldita documentación, pidiendo migajas en los foros, y, por cierto, nuestra nueva porquería es completamente diferente de la vieja porquería, porque realmente arruinamos este diseño, jaja, pero ese es tu problema, no el nuestro.
Todavía estamos haciendo esfuerzos para que todo tu desarrollo se vuelva inutilizable en el transcurso de un año.
Por favor, vete a la mierda,
Plataforma en la nube de Google
Y la cuestión es que recibo cartas como estas aproximadamente una vez al mes. Ocurre con tanta frecuencia y de forma tan constante que inevitablemente me alejaron de GCP hacia el campo de los opositores a la nube. Ya no estoy de acuerdo en depender de sus desarrollos propietarios, porque en realidad a un DevOps le resulta más fácil mantener un sistema de código abierto en una máquina virtual desnuda, que intentar seguirle el ritmo a Google con su política de cierre de productos "obsoletos".
Antes de volver a Google Cloud, porque yo ni siquiera cerca no he terminado de criticarlos, veamos el trabajo de la empresa en algunas otras áreas. Los ingenieros de Google están orgullosos de su disciplina en el desarrollo de software, y esto en realidad genera problemas. El orgullo es una trampa para los descuidados, ha hecho que muchos empleados de Google crean que sus soluciones siempre son correctas y que la corrección (según alguna definición vaga) es más importante que el cuidado hacia los clientes.
Voy a dar algunos ejemplos aleatorios de otros grandes proyectos fuera de Google, pero espero que vean este patrón en todas partes. Se resume en lo siguiente: la compatibilidad hacia atrás mantiene la vitalidad y relevancia de los sistemas durante décadas.
La compatibilidad hacia atrás es el objetivo del diseño de todos los sistemas exitosos diseñados para uso abierto, es decir, implementados con código abierto y/o estándares abiertos. Siento que estoy diciendo algo demasiado obvio, que a todos les resulta incluso incómodo, pero no. Es una cuestión política, por lo que se necesitan ejemplos. El primer sistema que elegiré es el más antiguo: GNU Emacs, es una especie de híbrido entre el Bloc de notas de Windows, el núcleo del sistema operativo y la Estación Espacial Internacional. Es un poco complicado de explicar, pero en pocas palabras, Emacs es una plataforma creada en 1976 (sí, hace casi medio siglo) para la programación, diseñada para incrementar su productividad, pero disfrazada de editor de texto.
Uso Emacs todos los días. Sí, también uso IntelliJ cada día; se ha convertido en una poderosa plataforma de herramientas por sí misma. Pero escribir extensiones para IntelliJ es una tarea mucho más ambiciosa y compleja que escribir extensiones para Emacs. Y lo que es más importante, todo lo escrito para Emacs se conserva
para siempre. Todavía utilizo software que escribí para Emacs en 1995. Y estoy seguro de que alguien usa módulos escritos para Emacs a mediados de los años 80, si no antes. De vez en cuando pueden necesitar ajustes menores, pero eso realmente es bastante raro. No sé de nada de lo que he escrito para Emacs (y he escrito mucho) que haya necesitado reestructurar la arquitectura..
Я по-прежнему использую программное обеспечение, которое написал для Emacs ещё в 1995 году. И уверен, что кто-то используют модули, написанное для Emacs в середине 80-х, если не раньше. Время от времени они могут потребовать незначительной настройки, но это действительно довольно редко. Я не знаю ничего из того, что я когда-либо писал для Emacs (а я написал много), в чём пришлось бы перестроить архитектуру.
En Emacs, hay una función llamada make-obsolete para entidades obsoletas. La terminología de Emacs para conceptos computacionales fundamentales (como el que es una "ventana") a menudo difiere de las convenciones de la industria, porque Emacs las introdujo hace mucho tiempo. Este es un peligro típico para aquellos que se adelantaron a su tiempo: todos sus términos pueden ser incorrectos. Pero en Emacs realmente hay un concepto de obsolescencia, que en su jerga se llama obsolescencia.
Pero en el mundo de Emacs, parece haber otra definición de trabajo. Una filosofía fundamental diferente, si se quiere.
En el mundo de Emacs (y en muchas otras áreas que abordaremos a continuación), el estatus de una API obsoleta principalmente significa: "Realmente no deberías usar este enfoque, porque aunque funciona, tiene varias desventajas que enumeraremos aquí. Pero, al final, es tu elección".
En el mundo de Google, el estatus de un producto obsoleto significa: "Estamos rompiendo nuestras promesas contigo". Así es. Esto es lo que significa en esencia. Significa que te obligarán a hacer algún trabajo, posiblemente mucho trabajo, como castigo por haber creído en su colorida publicidad Es como vender un coche de segunda mano que definitivamente se romperá después de 1500 km.
Estas son dos definiciones filosóficas completamente diferentes de "obsolescencia". La definición de Google huele a
obsolescencia planificada obsolescencia planificada en el mismo sentido que la de Apple. Pero Google definitivamente planea romper tus programas de manera indirecta. Lo sé porque trabajé allí como ingeniero de software durante más de 12 años. Tienen pautas internas vagamente definidas sobre hasta qué punto deben mantener la compatibilidad hacia atrás, pero, en última instancia, depende de cada equipo o servicio individual. No hay recomendaciones a nivel corporativo o ingenieril, y la recomendación más audaz en términos de ciclos de obsolescencia es "intenta darle a los clientes entre 6 y 12 meses para actualizar, antes de romper todo su sistema". realmente запланированное устаревание в том же смысле, как у Apple. Но Google определённо планирует сломать ваши программы, окольным путём. Я знаю это, потому что проработал там инженером-программистом более 12 лет. У них есть расплывчатые внутренние рекомендации, в какой мере следует соблюдать обратную совместимость, но в конечном итоге это зависит от каждой отдельной команды или службы. Нет никаких рекомендаций корпоративного или инженерного уровня, и самая смелая рекомендация с точки зрения циклов устаревания — это «попробуйте дать клиентам 6-12 месяцев на обновление, прежде чем сломать им всю систему».
El problema es mucho más serio de lo que piensan, y persistirá durante muchos años, porque el cuidado del cliente no forma parte de su ADN. Más detalles sobre esto a continuación.
En este momento, me atrevo a hacer una afirmación audaz: Emacs ha tenido mucho éxito en gran medida y hasta principalmente porque se toman muy en serio la retrocompatibilidad. De hecho, ese es el tema de nuestro artículo. Los sistemas de código abierto exitosos y de larga duración deben su éxito a microcomunidades que han vivido durante décadas alrededor de extensiones/plugins. Esa es la ecosistema. Ya he reflexionado sobre la naturaleza de las plataformas y lo importantes que son, así como que Google nunca ha entendido a lo largo de su historia corporativa lo que implica crear una plataforma abierta exitosa, más allá de Android o Chrome.
De hecho, debo mencionar brevemente Android, porque probablemente hayas pensado en él.
En primer lugar, Android no es Google. No tienen casi nada en común. Android es una empresa que fue comprada por Google en julio de 2005, a la que se le permitió operar más o menos de manera autónoma y, de hecho, ha permanecido en gran medida intacta a lo largo de los años. Android es un stack técnico tristemente célebre y una organización igualmente famosa por ser espinosa. Como dijo un empleado de Google, "no se puede simplemente entrar en Android".
En uno de mis artículos anteriores ya he reflexionado sobre lo malas que eran algunas de las decisiones de diseño iniciales de Android. Maldita sea, cuando escribí ese artículo, estaban desplegando una porquería llamada "aplicaciones instantáneas", que ahora (¡sorpresa!) , y siento si fuiste lo suficientemente ingenuo para seguir el consejo de Google y trasladar tu contenido a estas aplicaciones instantáneas.
Pero aquí hay una diferencia, una diferencia significativa, que radica en que las personas de Android realmente entienden cuán importantes son las plataformas, y se esfuerzan al máximo por mantener la funcionalidad de las aplicaciones antiguas de Android. De hecho, su esfuerzo por mantener la compatibilidad hacia atrás es tan extremo que incluso yo, durante mi breve estancia en la división de Android hace algunos años, descubrí que estaba tratando de convencerlos de que dejaran de dar soporte a algunos de los dispositivos y API más antiguos (me equivoqué, como en muchas otras cosas del pasado y presente. Lo siento, chicos de Android. Ahora que he estado en Indonesia, entiendo por qué son necesarios).
Las personas de Android mantienen la compatibilidad hacia atrás hasta extremos casi inimaginables, lo que acumula una enorme cantidad de deuda técnica obsoleta en sus sistemas y cadenas de herramientas. Oh Dios, deberían ver algunas de las cosas locas que tienen que hacer en su sistema de compilación, y todo esto en nombre de la compatibilidad.
Por esto, otorgo a Android el codiciado premio "No eres Google". Realmente no quieren convertirse en Google, que no sabe crear plataformas duraderas, mientras que Android sí sabe cómo hacerlo. conoce, y por eso Google se comporta de manera muy sabia en un aspecto: permite que las personas en Android hagan todo a su manera.
Sin embargo, las aplicaciones instantáneas de Android fueron una idea bastante tonta. ¿Y saben por qué? Porque requerían volver a escribir y rediseñar su aplicación! Como si las personas simplemente fueran a tomar y reescribir dos millones de aplicaciones. Supongo que las aplicaciones instantáneas eran la idea de algún empleado de Google.
Pero aquí hay una diferencia. La compatibilidad hacia atrás conlleva grandes costos. Android asume el peso de estos costos, mientras que Google insiste en que este peso lo lleven tú, el cliente de pago.
Puedes ver el compromiso de Android con la compatibilidad hacia atrás en sus interfaces de API. Cuando tienes cuatro o cinco subsistemas diferentes para realizar literalmente la misma cosa, es una señal clara de que hay un compromiso con la compatibilidad hacia atrás. Lo que, en el mundo de las plataformas, es sinónimo de compromiso con tus clientes y tu mercado.
El principal problema de Google aquí es su orgullo por su higiene ingenieril. No les gusta que haya muchas formas diferentes de hacer lo mismo, especialmente cuando los métodos antiguos y menos deseables coexisten junto a los nuevos y más sofisticados. Esto aumenta la curva de aprendizaje para los nuevos en el sistema, incrementa la carga de mantenimiento de las API obsoletas, ralentiza la velocidad de implementación de nuevas funciones, y el principal pecado—es poco estético. Google es como la Señora Escot de 'Alicia en el País de las Maravillas' de Tim Burton:
Señora Escot:
— Alicia, ¿sabes qué es lo que más temo?
— ¿La caída de la aristocracia?
— Temía que tuviera nietos feos.
Para entender el compromiso entre lo bello y lo práctico, echemos un vistazo a la tercera plataforma exitosa (después de Emacs y Android) y veamos cómo funciona: Java en sí.
Java tiene un montón de API obsoletas. La obsolescencia es muy común entre los programadores de Java, incluso más que en la mayoría de los lenguajes de programación. En el propio Java, el lenguaje principal y las bibliotecas, hay constantemente API que se vuelven obsoletas.
Si tomamos solo uno de los miles de ejemplos, se considera obsoleto. Se volvió obsoleto desde la salida de Java 1.2 en diciembre de 1998. Han pasado 22 años desde entonces.
Pero mi código real en producción aún mata hilos cada día. ¿Está bien eso? ¡Absolutamente! Quiero decir, por supuesto, si reescribiera el código hoy, lo haría de otra manera. Pero el código de mi juego, que ha hecho felices a cientos de miles de personas en las últimas dos décadas, está escrito con la función de cierre de hilos, que cuelga demasiado tiempo, y nunca he tenido que cambiarlo. Conozco mi sistema mejor que nadie, tengo literalmente 25 años de experiencia trabajando con él en producción, y puedo decir con precisión: en mi caso, cerrar estos hilos de trabajo específicos es completamente inoffensivo. No vale la pena gastar tiempo y esfuerzo reescribiendo este código, y gracias a Larry Ellison (probablemente), Oracle no me ha obligado a reescribirlo.
Probablemente Oracle también sabe sobre plataformas. Quién sabe.
Las pruebas se pueden encontrar en todas las claves de la API de Java, que están impregnadas de olas de obsolescencia, al igual que las líneas de un glaciar en un cañón. En la biblioteca Java Swing, es fácil encontrar cinco o seis diferentes administradores de enfoque de teclado (KeyboardFocusManager). De hecho, es difícil encontrar una API de Java que no esté obsoleta. ¡Pero todavía funcionan! Creo que el equipo de Java realmente eliminará la API solo si la interfaz plantea un problema de seguridad evidente.
Aquí está el problema, amigos: nosotros, los desarrolladores de software, estamos todos muy ocupados y en cada área del software nos encontramos con alternativas competitivas. En cualquier momento, los programadores en el lenguaje X consideran el lenguaje Y como un posible reemplazo. Oh, ¿no me crees? ¿Quieres mencionar Swift? Diciendo que todos están migrando a Swift y nadie se está yendo, ¿verdad? Vaya, cuánto sabes. Las empresas están considerando los costos de tener equipos de desarrollo móvil duplicados (iOS y Android) y comienzan a entender que estos sistemas de desarrollo multiplataforma con nombres ridículos, como Flutter y React Native, realmente funcionan, y con ellos pueden reducir el tamaño de sus equipos móviles a la mitad o, por el contrario, hacer que sean el doble de productivos. Hay dinero en juego. Sí, hay compromisos, pero por otro lado, el lu-u-u-u-ujoso dinero.
Supongamos hipotéticamente que Apple, por error, siguió el ejemplo de Guido van Rossum y anunció que Swift 6.0 no es compatible hacia atrás con Swift 5.0, de manera similar a como Python 3 no es compatible con Python 2.
Probablemente conté esta historia hace unos diez años, pero hace unos quince años fui al campamento Foo de O’Reilly con Guido, me senté en una carpa con Paul Graham y un montón de grandes figuras. Estábamos sentados bajo un calor agotador esperando que Larry Page aterrizara en su helicóptero privado, mientras Guido murmuraba monótonamente sobre "Python 3000", que nombró por la cantidad de años que llevaría a todos migrar allí. Todo el tiempo le preguntábamos por qué estaba rompiendo la compatibilidad, y él respondía: “Unicode”. Y le preguntábamos, si tendríamos que reescribir nuestro código, ¿qué otras ventajas veríamos? Y él respondía: “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.
Si instalas el SDK de Google Cloud Platform (“gcloud”), recibirás la siguiente notificación:
Estimado destinatario,
Nos gustaría recordarle que el soporte para Python 2 ha finalizado, así que ¡adiós!
… y así sucesivamente. Ciclo de vida.
Pero la cuestión es que cada desarrollador tiene una opción. Y si los obligas a reescribir código con demasiada frecuencia, podrían pensar en otras otros opciones. No son tus rehenes, por mucho que desees que lo sean. Son tus invitados. Python sigue siendo un lenguaje de programación muy popular, pero, ¡vaya!, Python 3(000) ha creado un desastre en sus comunidades y entre sus usuarios, que no han podido recuperarse durante quince años.
¿Cuántos programas de Python se han reescrito en Go (o Ruby, o alguna otra alternativa) debido a esta incompatibilidad hacia atrás? ¿Cuántos nuevos softwares se han creado en algo diferente a Python, aunque podría haber sido escrito en Python, si Guido no hubiera quemado toda la aldea? Es difícil decirlo, pero Python claramente ha sufrido. Es un desastre enorme, y todos pierden. Así que supongamos que Apple toma ejemplo de Guido y rompe la compatibilidad. ¿Qué crees que sucederá luego? Bueno, puede que el 80-90% de los desarrolladores reescriban su software, si pueden. En otras palabras, el 10-20% de la base de usuarios se irá automáticamente a algún lenguaje competidor, como Flutter.
Hazlo varias veces y perderás la mitad de tu base de usuarios. Al igual que en el deporte, la forma actual también importa en el mundo de la programación.
. Cualquiera que pierda la mitad de sus usuarios en cinco años será considerado un Gran Fracaso. Debes estar al día en el mundo de las plataformas. Pero es aquí donde la falta de soporte para versiones antiguas te llevará a la ruina. Porque cada vez que te deshaces de parte de los desarrolladores, (a) los pierdes para siempre, ya que se enojan contigo por romper el contrato, y (b) se los entregas a tus competidores. todoPor irónico que parezca, también ayudé a Google a convertirse en esa diva que ignora la compatibilidad hacia atrás cuando creé Grok, un sistema de análisis y comprensión de código fuente que facilita la automatización y la dotación de herramientas basada en el propio código. Se parece a un IDE, pero aquí el servicio en la nube almacena representaciones materializadas de miles de millones de líneas de código fuente de Google en un gran almacén de datos.
По иронии судьбы, я тоже помог Google превратиться в такую примадонну, которая игнорирует обратную совместимость, когда создал Grok, систему анализа и понимания исходного кода, которая облегчает автоматизацию и оснастку инструментарием на основе самого кода — похоже на IDE, но здесь облачный сервис хранит материализованные представления всех миллиардов строк исходного кода Google в большом хранилище данных.
Grok ha proporcionado a los googlers una potente base para llevar a cabo la refactorización automatizada en toda la base de código (literalmente en todo Google). El sistema calcula no solo tus dependencias ascendentes (de las que dependes), sino también descendentes (que dependen de ti), por lo que al cambiar la API sabes a todos los que rompes. Así, al hacer cambios, puedes verificar que cada consumidor de tu API se ha actualizado a la nueva versión, y de hecho, a menudo con la herramienta Rosie, que ellos escribieron, puedes automatizar completamente el proceso.
Esto permite que la base de código de Google sea internamente casi sobrenaturalmente 'limpia', ya que tienen estos sirvientes robotizados que deambulan por la casa y automáticamente limpian todo, si han renombrado SomeDespicablyLongFunctionName a SomeDespicablyLongMethodName, porque alguien decidió que era un nieto feo y debía ser dejado en paz.
Y, sinceramente, funciona bastante bien para Google… internamente. Quiero decir, sí, la comunidad de Go en Google realmente se ríe amablemente de la comunidad de Java en Google debido a su costumbre de refactorización continua. Si reinicias algo N veces, significa que no solo lo estropeaste N-1 veces, sino que después de un tiempo se vuelve completamente claro que probablemente lo estropeaste también en el N-ésimo intento. Pero, en general, ellos se mantienen por encima de este alboroto y mantienen el código 'limpio'.
Los problemas comienzan cuando intentan imponer esta actitud a sus clientes en la nube y a los usuarios de otras APIs.
Te he introducido un poco a Emacs, Android y Java; veamos la última plataforma exitosa y de larga duración: la Web misma. ¿Puedes imaginar cuántas iteraciones ha pasado HTTP desde 1995, cuando utilizábamos etiquetas parpadeantes <blink> y el icono de 'En desarrollo' en las páginas web?
¡Pero aún funciona! ¡Y esas páginas siguen funcionando! Sí, chicos, los navegadores son campeones mundiales en compatibilidad hacia atrás. Chrome es otro ejemplo raro de una plataforma de Google que está bien estructurada, y, como ya habrás adivinado, Chrome funciona efectivamente como una empresa aislada separada del resto de Google.
También quiero agradecer a nuestros amigos entre los desarrolladores de sistemas operativos: Windows, Linux, NO APPLE VÁMONOS APPLE, FreeBSD y así sucesivamente, por el gran trabajo que han hecho en términos de compatibilidad retroactiva en sus exitosas plataformas (Apple recibe como mucho un tres menos porque constantemente rompen todo sin ninguna razón válida, pero de alguna manera la comunidad se las arregla con esto en cada lanzamiento, y aún hay contenedores con OS X que no están completamente obsoletos... por ahora).
Pero espera, dirás. ¿Acaso no estamos comparando manzanas con naranjas: sistemas de software autónomos en una máquina, como Emacs/JDK/Android/Chrome, con sistemas multinodo y API, como en los servicios en la nube?
Bueno, escribí sobre esto ayer en Twitter, pero en el estilo de Larry Wall (creador del lenguaje de programación Perl — nota del traductor) con el principio de 'basura/regla' busqué la palabra está obsoleto en los sitios para desarrolladores de Google y Amazon. Y aunque AWS tiene cientos de veces más ofertas de servicios que GCP, la documentación para desarrolladores de Google menciona la obsolescencia aproximadamente siete veces más a menudo.
Si alguien de Google lee esto, seguramente están listos para sacar gráficos al estilo de Donald Trump, mostrando que en realidad están haciendo todo bien, y que no debería hacer comparaciones injustas, como 'el número de menciones de la palabra deprecated en relación con el número de servicios'.
Pero después de tantos años, Google Cloud sigue siendo el servicio número 3 (tampoco escribí el artículo sobre el fallido intento de ser número 2), pero si se cree a los informantes, hay algunas preocupaciones de que pronto podrían caer al número 4.
No tengo argumentos sólidos para 'demostrar' mi tesis. Todo lo que tengo son ejemplos vívidos que he acumulado a lo largo de 30 años de experiencia como desarrollador. Ya he mencionado la naturaleza profundamente filosófica de este problema; en cierto sentido está politizado en las comunidades de desarrolladores. Algunos creen que los creadores de plataformas deben preocuparse por la compatibilidad, mientras que otros creen que esa es una preocupación usuarios (de los propios desarrolladores). Es una de dos. Y de verdad, ¿no es una cuestión política cuando decidimos quién debe asumir los costos de los problemas comunes?
Así que es política. Y seguramente habrá respuestas airadas a mi declaración.
¿Cómo usuario como usuario de la plataforma en la nube de Google, así como de AWS durante dos años (trabajando en Grab), puedo decir que hay una gran diferencia entre las filosofías de Amazon y Google cuando se trata de prioridades. No estoy activamente desarrollando en AWS, por lo que no estoy muy familiarizado con la frecuencia con la que eliminan las API antiguas. Pero sospecho que esto no ocurre tan a menudo como en Google. Y realmente creo que esta fuente constante de disputas y decepciones en GCP es uno de los mayores factores que limitan el desarrollo de la plataforma.
Sé que no he mencionado ejemplos específicos de sistemas de GCP que han sido descontinuados. Puedo decir que prácticamente todo lo que he utilizado, desde redes (desde las más antiguas hasta VPC) hasta almacenamiento (Cloud SQL v1-v2), Firebase (ahora Firestore con una API completamente diferente), App Engine (ni siquiera empecemos), puntos finales en la nube Cloud Endpoint y hasta... no sé absolutamente todo esto me obligaba a reescribir el código cada 2-3 años como máximo, y nunca automatizaban la migración para usted, y a menudo . Como si así fuera.
Y cada vez que miro a AWS, me pregunto qué demonios hago todavía en GCP. Claramente no necesitan clientes. Necesitan compradores. ¿Entiendes la diferencia? Déjame explicarte.
Google Cloud tiene un , donde las personas ofrecen sus soluciones de software, y para evitar el efecto de un restaurante vacío, necesitaban llenarlo con algunas ofertas, por lo que firmaron un contrato con Bitnami para crear un montón de soluciones que se despliegan "con un solo clic", o debería escribir "soluciones" yo mismo, porque estas no resuelven nada. Simplemente existen como marcas, como relleno de marketing, y a Google nunca le ha importado si alguna de estas herramientas funciona realmente. Conozco a gerentes de producto que estaban al volante y puedo asegurarte que a estas personas no les importa.
Tomemos, por ejemplo, una solución que supuestamente se despliega "con un solo clic" . Estoy harto de los trucos de Google Cloud SQL, así que empecé a considerar la creación de mi propio clúster Percona como una alternativa. Y esta vez Google parece haber hecho algo bueno, ¡están dispuestos a ahorrarme un poco de tiempo y esfuerzo con solo presionar un botón!
Bueno, vamos. Sigamos el enlace y hagamos clic en este botón. Seleccionamos 'Sí' para aceptar todos los parámetros predeterminados y desplegar el clúster en nuestro proyecto de Google Cloud. Ja, ja, no funciona. Nada de esta porquería funciona. La herramienta nunca fue probada y comenzó a deteriorarse desde el primer minuto, y no me sorprendería si más de la mitad de las 'soluciones' para desplegar con un solo clic (ahora entendemos por qué las comillas) en absoluto no funcionan. Es una oscuridad absolutamente desesperante, donde es mejor no entrar.
Pero Google claramente llama a que la usen. Quieren que las compres.. Para ellos es una transacción. No quieren nada soportar. Eso no es parte del ADN de Google. Sí, los ingenieros se apoyan entre sí, como lo demuestra mi historia con Bigtable. Pero en productos y servicios para personas comunes, son siempre implacables en , que no alcanza el umbral de rentabilidad, incluso si tiene millones de usuarios.
Y esto presenta un problema real para GCP, porque este ADN respalda todas las ofertas en la nube. No buscan mantener nada; es bien sabido que se niegan a alojar (como servicio gestionado) cualquier software de terceros hasta que, hasta que AWS haga lo mismo y construya un negocio exitoso a su alrededor, y cuando los clientes literalmente exijan lo mismo. Sin embargo, se necesita hacer un esfuerzo considerable para convencer a Google de que mantenga algo.
Esta falta de cultura de soporte, combinada con el principio de 'rompamos para embellecer', aleja a los desarrolladores de ellos.
Y eso no es bueno si quieres construir una plataforma duradera.
Google, despierta, maldita sea. Ahora es 2020. Aún estás perdiendo. Es hora de mirarte al espejo y preguntarte si realmente quieres quedarte en el negocio de la nube.
Si quieres quedarte, deja de romper todo.Chicos, ustedes son ricos. Nosotros, los desarrolladores, no lo somos. Por lo tanto, cuando se trata de quién cargará con la carga de la compatibilidad, deben asumirlo. No nosotros.
Porque hay al menos otros tres nubes realmente buenas. Ellas te llaman.
Y ahora seguiré arreglando todos mis sistemas rotos. Ah.
¡Hasta la próxima vez!
P. S. Actualización después de leer algunas discusiones sobre este artículo (las discusiones son maravillosas, por cierto). El soporte para Firebase no ha sido interrumpido, y no hay planes de los que yo sepa. Sin embargo, tienen un molesto error de transmisión que hace que el cliente Java se detenga en App Engine. Uno de sus ingenieros me ayudó a enfrentar este problema, cuando trabajaba en Google, pero nunca realmente arreglaron el bug, así que tengo un arreglo bastante malo, tengo que reiniciar la aplicación GAE todos los días. ¡Y así ya van cuatro años! Ahora tienen Firestore. Se requerirá mucho trabajo para migrar a él, ya que es un sistema completamente diferente, y el error de Firebase nunca será corregido. ¿Qué conclusión se puede sacar? Puede obtener ayuda, si trabaja en una empresa. Probablemente soy el único que usa Firebase en GAE, porque estoy registrando menos de 100 claves en una aplicación nativa 100%, y se detiene cada pocos días debido a un error conocido. ¿Qué se puede decir, excepto usarlo bajo su propio riesgo? Estoy cambiando a Redis.
También he visto a algunos usuarios más experimentados de AWS decir que AWS generalmente nunca interrumpe el soporte de ningún servicio, y SimpleDB es un gran ejemplo. Mis suposiciones de que en AWS no hay esa enfermedad de interrumpir el soporte como en Google parecen estar justificadas.
Además, noté que hace 20 días el equipo de Google App Engine rompió el hosting de una biblioteca crítica de Go, cerrando la aplicación GAE para uno de los principales desarrolladores de Go. Realmente, resultó ser bastante tonto.
Finalmente, escuché que los googlers ya están discutiendo este asunto y en general están de acuerdo conmigo (¡los quiero, chicos!). Pero parece que consideran que el problema es irresoluble porque en la cultura de Google nunca ha habido una estructura de incentivos adecuada. Creo que valdría la pena dedicar un tiempo para discutir la experiencia absolutamente asombrosa de trabajar con los ingenieros de AWS cuando trabajé en la empresa Grab. ¡Espero que en algún momento en el futuro!
Y sí, en 2005 realmente tenían diferentes tipos de carne de tiburón en un gigantesco buffet en el edificio 43, y me gustaba más la carne de tiburón martillo. Sin embargo, para 2006, Larry y Sergey eliminaron todos los refrigerios poco saludables. Así que durante la historia de Bigtable en 2007, de hecho no había tiburones y te engañé vilmente.
Cuando miré Bigtable en la nube hace unos cuatro años (más o menos), el costo era exactamente ese. Parece que ahora ha bajado un poco, pero sigue siendo muchísimo para un almacenamiento de datos vacío, especialmente considerando que mi primera historia muestra cuán insignificante es una gran tabla vacía a su escala.
Lo siento por ofender a la comunidad de Apple y por no haber dicho nada bueno sobre Microsoft, etc. Todos tienen razón, ¡aprecio mucho todas las discusiones que ha generado este artículo! Pero a veces hay que hacer un poco de ruido para iniciar la conversación, ¿saben?
Gracias por leer.
Actualización 2, 19.08.2020. Stripe !
Actualización 3, 31.08.2020. Me contactó un ingeniero de Google en Cloud Marketplace, que resultó ser un viejo amigo mío. Quería averiguar por qué C2D no funcionaba, y al final descubrimos: la razón es que creé mi red hace varios años, y C2D no se activa en redes obsoletas debido a falta del parámetro de subred en sus plantillas. Creo que es mejor que los potenciales usuarios de GCP se aseguren de tener suficientes ingenieros familiarizados en Google...
Fuente: habr.com
