Maldito Google, no quería volver a escribir en el blog. Tengo mucho que hacer. Escribir un blog requiere tiempo, energía y creatividad, algo que podría aprovechar: mis libros, , mi juego y así sucesivamente. Pero me has enojado lo suficiente como para tener que escribir esto.
Así que acabemos con esto.
Permítanme comenzar con una historia breve pero instructiva de cuando comencé a trabajar en Google. Sé que últimamente he estado diciendo muchas cosas malas sobre Google, pero me molesta que mi propia empresa tome regularmente decisiones comerciales incompetentes. Al mismo tiempo, debemos reconocerlo: la infraestructura interna de Google es realmente extraordinaria, se puede decir con seguridad que hoy no hay nada mejor. Los fundadores de Google fueron mucho mejores ingenieros de lo que yo seré jamás, y esta historia sólo confirma ese hecho.
Primero, un poco de historia: Google tiene una tecnología de almacenamiento de datos llamada . Fue un logro técnico notable, uno de los primeros (si no el primero) almacén de valores clave (K/V) “infinitamente escalable”: esencialmente el comienzo de NoSQL. Hoy en día, a Bigtable todavía le va bien en el espacio de almacenamiento K/V, bastante concurrido, pero en ese momento (2005) era increíblemente genial.
Una cosa curiosa de Bigtable es que tenían objetos de plano de control interno (como parte de la implementación) llamados servidores de tableta, con índices grandes, y en algún momento se convirtieron en un cuello de botella al escalar el sistema. Los ingenieros de Bigtable estaban desconcertados sobre cómo implementar la escalabilidad y de repente se dieron cuenta de que podían reemplazar los servidores de tabletas con otro almacenamiento de Bigtable. Entonces Bigtable es parte de la implementación de Bigtable. Estas instalaciones de almacenamiento están ahí en todos los niveles.
Otro detalle interesante es que durante un tiempo Bigtable se volvió popular y omnipresente dentro de Google, teniendo cada equipo su propio repositorio. Entonces, en una de las reuniones del viernes, Larry Page preguntó casualmente de pasada: “¿Por qué tenemos más de una Bigtable? ¿Por qué no sólo uno? En teoría, un almacenamiento debería ser suficiente para todas las necesidades de almacenamiento de Google. Por supuesto, nunca optaron por uno solo por razones prácticas de desarrollo (como las consecuencias de un posible fallo), pero la teoría era interesante. Un repositorio para todo el Universo (Por cierto, ¿alguien sabe si Amazon hizo esto 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 electrónico del equipo de ingeniería de Bigtable que decía algo como esto:
Querido Steve,
Hola de parte del equipo de Bigtable. Nos gustaría informarle que en [nombre del centro de datos] está utilizando un binario de Bigtable muy, muy antiguo. Esta versión ya no es compatible y queremos ayudarle a actualizar a la última versión.
Avíseme si puede programar algo de tiempo para trabajar juntos en este tema.
Mis mejores deseos,
Equipo de mesa grande
En Google recibes muchos correos, así que a primera vista leí algo como esto:
Estimado destinatario,
Hola de algún equipo. Queremos comunicar que bla, bla, bla, bla, bla. Bla, bla, bla, bla, bla, bla, y bla, bla, bla, inmediatamente.
Háganos saber si puede reservar algo de su valioso tiempo para bla, bla, bla.
Mis mejores deseos,
Algún tipo de comando
Casi lo borré de inmediato, pero en el borde de mi conciencia sentí una sensación dolorosa y persistente de que no del todo aunque parece una carta formal obviamente, que el destinatario se equivocó porque no usé Bigtable.
Pero fue extraño.
Pasé el resto del día pensando alternativamente 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 golpearlas desde mi asiento con un lanzamiento certero de una galleta, pero el La idea de escribir nunca me dejó con un sentimiento creciente de ligera ansiedad.
Dijeron claramente mi nombre. Y el correo electrónico se envió a mi dirección de correo electrónico, no a la de otra persona, y no es cc: ni bcc:. El tono es muy personal y claro. ¿Quizás esto sea algún tipo de error?
Finalmente, la curiosidad se apoderó de mí y fui a mirar la consola Borg en el centro de datos que mencionaron.
Y, por supuesto, tenía el almacenamiento de BigTable bajo administración. ¿Disculpa que? Miré su contenido y ¡guau! Fue de la incubadora Codelab en la que estuve durante mi primera semana en Google en junio de 2005. Codelab te obligó a ejecutar Bigtable para escribir algunos valores allí y aparentemente nunca cerré el almacenamiento después de eso. Seguía funcionando a pesar de que habían pasado más de dos años.
Hay varios aspectos destacables en esta historia. En primer lugar, el trabajo de Bigtable era tan insignificante en comparación con Google que sólo dos años después alguien se dio cuenta del almacenamiento adicional, y sólo porque la versión del binario estaba desactualizada. A modo de comparación, una vez consideré usar para mi juego en línea. En ese momento, este servicio costaba aproximadamente 16 dólares al año. vacío Gran mesa en GCP. No digo que te estén estafando, pero en mi opinión personal, eso es mucho dinero para una puta base de datos vacía.
Otro aspecto destacable es que el almacenamiento sigo trabajando después de dos años. ¿Qué carajo? Los centros de datos van y vienen; experimentan cortes, se someten a mantenimiento programado, cambian todo el tiempo. El hardware se actualiza, los interruptores se intercambian y todo se mejora constantemente. ¿Cómo diablos pudieron mantener mi programa funcionando durante dos años con todos estos cambios? Esto puede parecer un logro modesto en 2020, pero en 2005-2007 fue bastante impresionante.
Y lo más maravilloso es que un equipo de ingeniería externo en algún otro estado se acerca a mí, el propietario de una instancia pequeña, casi vacía, de Bigtable, que tiene tráfico cero durante los últimos dos años y ofrecemos ayuda para actualizarlo.
Les di las gracias, eliminé el almacenamiento y la vida siguió como de costumbre. Pero trece años después, todavía pienso en esa carta. Porque a veces recibo correos electrónicos similares de Google Cloud. Se ven así:
Estimado usuario de Google Cloud:
Le recordamos que suspenderemos el servicio [servicio esencial que utiliza] a partir de agosto de 2020, después del cual no podrá actualizar sus instancias. Recomendamos actualizar a la última versión, que se encuentra en prueba beta, no tiene documentación, no tiene ruta de migración y ya está desactualizada con nuestra amable ayuda.
Nos comprometemos a garantizar que este cambio tenga un impacto mínimo en todos los usuarios de la plataforma Google Cloud.
Mejores amigos para siempre,
Plataforma en la nube de Google
Pero casi nunca leo cartas así, porque lo que en realidad dicen es:
Estimado destinatario,
Vete al infierno. Vete a la mierda, vete a la mierda, vete a la mierda. Deja todo lo que hagas porque no importa. Lo que importa es nuestro tiempo. Perdemos tiempo y dinero manteniendo nuestra basura y estamos cansados de ella, así que no la apoyaremos más. Así que abandona tus malditos planes y comienza a buscar en nuestra documentación de mierda, a pedir fragmentos en los foros y, por cierto, nuestra nueva mierda es completamente diferente de la vieja, porque arruinamos bastante este diseño, je, pero ese es tu problema, no el nuestro.
Seguimos esforzándonos para que todos sus desarrollos queden inutilizables en el plazo de un año.
Por favor vete a la mierda
Plataforma en la nube de Google
Y el hecho es que recibo este tipo de cartas aproximadamente una vez al mes. Esto sucede tan a menudo y tan constantemente que inevitablemente empujado lejos Yo de GCP al campo anti-nube. Ya no acepto depender de sus desarrollos propietarios, porque de hecho es más fácil para los devops mantener un sistema de código abierto en una máquina virtual desnuda que intentar seguir el ritmo de Google con su política de cerrar productos "obsoletos".
Antes de volver a Google Cloud porque incluso cerca Aún no hemos terminado de criticarlos, veamos el desempeño de la empresa en algunas otras áreas. Los ingenieros de Google se enorgullecen de su disciplina de ingeniería de software y esto es lo que realmente causa los problemas. El orgullo es una trampa para los incautos y ha llevado a muchos empleados de Google a pensar que sus decisiones siempre son correctas y que tener razón (según alguna definición vaga y confusa) es más importante que preocuparse por los clientes.
Daré algunos ejemplos aleatorios de otros proyectos grandes fuera de Google, pero espero que veas este patrón en todas partes. Es el siguiente: La compatibilidad con versiones anteriores mantiene los sistemas vivos y actualizados durante décadas..
La compatibilidad con versiones anteriores es el objetivo de diseño de todos los sistemas exitosos diseñados para abrir uso, es decir, implementado con código fuente abierto y/o estándares abiertos. Siento que estoy diciendo algo demasiado obvio que incluso todos se sienten incómodos, pero no. Esta es una cuestión política, por lo que se necesitan ejemplos.
El primer sistema que elegiré es el más antiguo: GNU Emacs, que es una especie de híbrido entre el Bloc de notas de Windows, el kernel del sistema operativo y la Estación Espacial Internacional. Es un poco difícil de explicar, pero en pocas palabras, Emacs es una plataforma creada en 1976 (sí, hace casi medio siglo) para programar para hacerte más productivo, pero disfrazada de editor de texto.
Utilizo Emacs todos los días. Sí, también uso IntelliJ todos los días; se ha convertido en una poderosa plataforma de herramientas por derecho propio. 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, se conserva todo lo escrito para Emacs. para siempre.
Todavía uso el software que escribí para Emacs en 1995. Y estoy seguro de que alguien está usando módulos escritos para Emacs a mediados de los 80, si no antes. Es posible que requieran pequeños ajustes de vez en cuando, pero esto es bastante raro. No sé de nada que haya escrito para Emacs (y he escrito mucho) que requiriera una re-arquitectura.
Emacs tiene una función llamada make-obsolete para entidades obsoletas. La terminología de Emacs para conceptos informáticos fundamentales (como lo 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 de quienes se adelantan a su tiempo: todos sus términos son incorrectos. Pero Emacs tiene un concepto de desaprobación, que en su jerga se llama obsolescencia.
Pero en el mundo de Emacs parece haber una definición funcional diferente. Una filosofía subyacente diferente, por así decirlo.
En el mundo de Emacs (y en muchas otras áreas, que cubriremos a continuación), el estado de API obsoleto básicamente significa: "Realmente no deberías usar este enfoque, porque si bien funciona, adolece de varias deficiencias que lista aquí. Pero al final del día, es tu elección."
En el mundo de Google, ser obsoleto significa "incumplimos nuestro compromiso con usted". Esto es cierto. Esto es lo que significa esencialmente. Esto significa que te obligarán regularmente hacer algo de trabajo, tal vez mucho trabajo, como castigo por creer en ellos : Tenemos el mejor software. ¡El más rápido! Haces todo según las instrucciones, inicias tu aplicación o servicio y luego bam, después de uno o dos años se estropea.
Es como vender un coche usado que definitivamente se estropeará después de 1500 km.
Éstas son dos definiciones filosóficas completamente diferentes de "obsolescencia". La definición de olor de Google . no creo esto de hecho obsolescencia programada en el mismo sentido que Apple. Pero Google definitivamente planea romper sus programas, de una manera indirecta. Lo sé porque trabajé allí como ingeniero de software durante más de 12 años. Tienen pautas internas vagas sobre cuánta compatibilidad con versiones anteriores se debe seguir, pero en última instancia depende de cada equipo o servicio individual. No existen recomendaciones a nivel empresarial o de ingeniería, y la recomendación más audaz en términos de ciclos de obsolescencia es "intentar darles a los clientes entre 6 y 12 meses para actualizar antes de dañar todo su sistema".
El problema es mucho mayor de lo que creen y persistirá durante años porque la atención al cliente no está en su ADN. Más sobre esto a continuación.
En este punto voy a hacer una declaración audaz de que Emacs tiene éxito en gran medida e incluso básicamente porque se toman muy en serio la compatibilidad con versiones anteriores. En realidad, esta es la tesis de nuestro artículo. Los sistemas abiertos exitosos y duraderos deben su éxito a las microcomunidades que han vivido a su alrededor durante décadas. extensiones/complementos. Este es el ecosistema. Ya he hablado de la naturaleza de las plataformas y de lo importantes que son, y de cómo Google nunca en toda su historia corporativa ha entendido lo que implica la creación de una plataforma abierta exitosa fuera de Android o Chrome.
En realidad, debería mencionar brevemente Android porque probablemente estés pensando en ello.
En primer lugar, android no es google. No tienen casi nada en común entre sí. Android es una empresa que fue adquirida por Google en julio de 2005, a la que se le permitió funcionar de forma más o menos autónoma y, de hecho, se ha mantenido prácticamente intacta en los años transcurridos. Android es una pila tecnológica notoria y una organización espinosa igualmente notoria. Como dijo un empleado de Google: "No se puede simplemente iniciar sesión en Android".
En un artículo anterior, hablé de lo malas que fueron algunas de las primeras decisiones de diseño de Android. Diablos, cuando escribí ese artículo estaban lanzando basura llamada "aplicaciones instantáneas" que ahora son (¡sorpresa!) , y lo comprendo si fueras lo suficientemente estúpido como para escuchar a Google y mover tu contenido a estas aplicaciones instantáneas.
Pero aquí hay una diferencia, una diferencia significativa, y es que la gente de Android realmente entiende lo importantes que son las plataformas y hacen todo lo posible para mantener funcionando las aplicaciones antiguas de Android. De hecho, sus esfuerzos por mantener la compatibilidad con versiones anteriores son tan extremos que incluso yo, durante mi breve paso por la división de Android hace unos años, me encontré tratando de convencerlos de que abandonaran el soporte para algunos de los dispositivos y API más antiguos (me equivoqué). , como lo fue en muchas otras cosas pasadas y presentes. ¡Lo siento, muchachos de Android! Ahora que he estado en Indonesia, entiendo por qué los necesitamos).
La gente de Android lleva la compatibilidad hacia atrás a extremos casi inimaginables, acumulando enormes cantidades de deuda técnica heredada en sus sistemas y cadenas de herramientas. Dios mío, deberías ver algunas de las locuras que tienen que hacer en su sistema de compilación, todo en nombre de la compatibilidad.
Por esto le otorgo a Android el codiciado premio "No eres Google". Realmente no quieren convertirse en Google, que no sabe crear plataformas duraderas, pero Android sabe, cómo hacerlo. Y por eso Google está siendo muy inteligente en un aspecto: permitir que las personas hagan las cosas a su manera en Android.
Sin embargo, las aplicaciones instantáneas para Android fueron una idea bastante estúpida. Y sabes por que? porque exigieron reescribe y rediseña tu aplicación! Es como si la gente simplemente reescribiera dos millones de aplicaciones. Supongo que Instant Apps fue idea de algún Googler.
Pero hay una diferencia. La compatibilidad con versiones anteriores tiene un alto costo. El propio Android soporta la carga de estos costos, mientras que Google insiste en que la carga sea asumida usted, cliente de pago.
Puede ver el compromiso de Android con la compatibilidad con versiones anteriores en sus API. Cuando tienes cuatro o cinco subsistemas diferentes haciendo literalmente lo mismo, es una señal segura de que existe un compromiso con la compatibilidad con versiones anteriores en el núcleo. Lo cual 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 la higiene de su ingeniería. No les gusta cuando hay muchas formas diferentes de hacer lo mismo, con las formas antiguas y menos deseables al lado de las nuevas y más sofisticadas. Aumenta la curva de aprendizaje para aquellos nuevos en el sistema, aumenta la carga de mantener las API heredadas, ralentiza la velocidad de las nuevas funciones y el pecado capital es que no es bonito. Google, como Lady Ascot de Alicia en el país de las maravillas de Tim Burton:
Señora Ascot:
- Alice, ¿sabes a qué le tengo más miedo?
- ¿La decadencia de la aristocracia?
- Tenía miedo de haberlo hecho. nietos feos.
Para comprender el equilibrio entre belleza y práctica, echemos un vistazo a la tercera plataforma exitosa (después de Emacs y Android) y veamos cómo funciona: el propio Java.
Java tiene muchas API obsoletas. La desaprobación es muy popular entre los programadores de Java, incluso más popular que en la mayoría de los lenguajes de programación. El propio Java, el lenguaje principal y las bibliotecas están constantemente desaprobando las API.
Para tomar sólo uno de miles de ejemplos, considerado obsoleto. Ha quedado en desuso desde el lanzamiento de Java 1.2 en diciembre de 1998. Han pasado 22 años desde que esto quedó obsoleto.
Pero mi código real en producción todavía está matando hilos. cada día. ¿De verdad crees que eso es bueno? ¡Absolutamente! Quiero decir, por supuesto, si tuviera que reescribir el código hoy, lo implementaría de manera diferente. Pero el código de mi juego, que ha hecho felices a cientos de miles de personas durante las últimas dos décadas, está escrito con una función para cerrar hilos que duran demasiado, y yo nunca tuve 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 certeza: en mi caso, cerrar estos subprocesos de trabajo específicos es completamente inofensivo. No vale la pena el tiempo y el esfuerzo para reescribir este código, y agradezco a Larry Ellison (probablemente) que Oracle no me obligó a reescribirlo.
Probablemente Oracle también entienda las plataformas. Quién sabe.
Se pueden encontrar pruebas en las API principales de Java, que están plagadas de oleadas de obsolescencia, como las líneas de un glaciar en un cañón. Puede encontrar fácilmente cinco o seis administradores de navegación por teclado diferentes (KeyboardFocusManager) en la biblioteca Java Swing. En realidad, es difícil encontrar una API de Java que no esté en desuso. ¡Pero todavía funcionan! Creo que el equipo de Java sólo eliminará realmente una API si la interfaz plantea un problema de seguridad evidente.
Aquí está la cuestión, amigos: los desarrolladores de software estamos todos muy ocupados y en cada área del software nos enfrentamos a alternativas competitivas. En un momento dado, los programadores en el lenguaje X están considerando el lenguaje Y como un posible reemplazo. ¿No me crees? ¿Quieres llamarlo Swift? Todo el mundo está migrando a Swift y nadie lo abandona, ¿verdad? Vaya, qué poco sabes. Las empresas están contando los costos de los equipos de desarrollo móvil duales (iOS y Android) y están empezando a darse cuenta de que esos sistemas de desarrollo multiplataforma con nombres divertidos como Flutter y React Native realmente funcionan y pueden usarse para reducir el tamaño de su equipos móviles dos veces o, por el contrario, hacerlos dos veces más productivos. Hay dinero real en juego. Sí, hay compromisos, pero, por otro lado, dinero.
Supongamos hipotéticamente que Apple tontamente siguió el ejemplo de Guido van Rossum y declaró que Swift 6.0 es incompatible con Swift 5.0, al igual que Python 3 es incompatible con Python 2.
Probablemente conté esta historia hace unos diez años, pero hace unos quince años fui al Foo Camp de O'Reilly con Guido, me senté en una tienda de campaña con Paul Graham y un grupo de peces gordos. Nos sentamos en el calor sofocante esperando a que Larry Page volara en su helicóptero personal mientras Guido hablaba sobre “Python 3000”, al que llamó así por la cantidad de años que tardarían todos en migrar allí. Seguimos preguntándole por qué estaba rompiendo la compatibilidad y respondió: "Unicode". Y preguntamos, si tuviéramos que reescribir nuestro código, ¿qué otros beneficios veríamos? Y él respondió “Yooooooooooooouuuuuuuniiiiiiicoooooooode”.
Si instala el SDK de Google Cloud Platform (“gcloud”), recibirá la siguiente notificación:
Estimado destinatario,
Nos gustaría recordarte que la compatibilidad con Python 2 ha quedado obsoleta, así que vete a la mierda
… etcétera. Círculo de la vida.
Pero la cuestión es que cada desarrollador tiene una opción. Y si los obligas a reescribir código con suficiente frecuencia, podrían pensar en otro opciones. No son tus rehenes, por mucho que quieras que lo sean. Ellos son tus invitados. Python sigue siendo un lenguaje de programación muy popular, pero maldita sea, Python 3(000) creó tal lío en sí mismo, en sus comunidades y entre los usuarios de sus comunidades que las consecuencias no se han aclarado en quince años.
¿Cuántos programas Python se han reescrito en Go (o Ruby o alguna otra alternativa) debido a esta incompatibilidad hacia atrás? ¿Cuánto software nuevo se ha escrito en algo que no sea Python, aunque podría ser escrito en Python, si Guido no hubiera quemado todo el pueblo? Es difícil decirlo, pero Python claramente ha sufrido. Es un desastre enorme y todos pierden.
Entonces digamos que Apple sigue el ejemplo de Guido y rompe la compatibilidad. ¿Que crees que pasará después? Bueno, tal vez entre el 80% y el 90% de los desarrolladores reescriban su software si es posible. En otras palabras, entre el 10% y el 20% de la base de usuarios accede automáticamente a algún idioma de la competencia, como Flutter.
Haga esto varias veces y perderá la mitad de su base de usuarios. Al igual que en los deportes, en el mundo de la programación la forma actual también importa. todos. Cualquiera que pierda la mitad de sus usuarios en cinco años será considerado un gran perdedor. Debes estar a la moda en el mundo de las plataformas. Pero aquí es donde no admitir versiones anteriores te arruinará con el tiempo. Porque cada vez que te deshaces de algunos desarrolladores, (a) los pierdes para siempre porque están enojados contigo por romper el contrato y (b) los regalas a tus competidores.
Irónicamente, también ayudé a Google a convertirse en una prima donna que ignora la compatibilidad con versiones anteriores cuando creé Grok, un sistema de análisis y comprensión del código fuente que facilita la automatización e instrumentación del código en sí, similar a un IDE, pero aquí el servicio en la nube almacena Representaciones materializadas de los miles de millones de líneas de código fuente de Google en un gran almacén de datos.
Grok proporcionó a los empleados de Google un marco poderoso para realizar refactorizaciones automatizadas en todo su código base (literalmente en todo Google). El sistema calcula no sólo sus dependencias ascendentes (de las que usted depende), sino también río abajo (que dependen de usted), de modo que cuando cambie las API, sepa a todos a quienes está rompiendo. De esta manera, cuando realiza cambios, puede verificar que todos los consumidores de su API se hayan actualizado a la nueva versión y, en realidad, a menudo con la herramienta Rosie que escribieron, puede automatizar completamente el proceso.
Esto permite que el código base de Google esté internamente casi sobrenaturalmente limpio, ya que tienen estos sirvientes robóticos corriendo por la casa y limpiando todo automáticamente si cambian el nombre de SomeDespicablyLongFunctionName a SomeDespicablyLongMethodName porque alguien decidió que era un nieto feo y necesitaba ser puesto a dormir.
Y, francamente, funciona bastante bien para Google... internamente. Quiero decir, sí, la comunidad Go de Google se ríe mucho de la comunidad Java de Google debido a su hábito de refactorización continua. Si reinicias algo N veces, eso significa que no solo lo arruinaste N-1 veces, sino que después de un tiempo queda bastante claro que probablemente también lo arruinaste en el enésimo intento. Pero, en general, se mantienen por encima de todo este alboroto y mantienen el código "limpio".
El problema comienza cuando intentan imponer esta actitud a sus clientes de la nube y a los usuarios de otras API.
Les presenté un poco a Emacs, Android y Java; Echemos un vistazo a la última plataforma exitosa y duradera: la propia Web. ¿Te imaginas cuántas iteraciones ha pasado HTTP desde 1995 cuando usamos etiquetas intermitentes? e íconos "En construcción" en páginas web.
¡Pero todavía funciona! ¡Y estas páginas siguen funcionando! Sí, muchachos, los navegadores son los campeones mundiales en compatibilidad con versiones anteriores. Chrome es otro ejemplo de la rara plataforma de Google que tiene sus cabezas atornilladas correctamente y, como habrás adivinado, Chrome opera efectivamente como una empresa aislada del resto de Google.
También quiero agradecer a nuestros amigos desarrolladores de sistemas operativos: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, etc., por hacer un gran trabajo de compatibilidad con versiones anteriores en sus exitosas plataformas (Apple obtiene una C en el mejor de los casos con The La desventaja es que rompen todo todo el tiempo sin una buena razón, pero de alguna manera la comunidad lo soluciona con cada lanzamiento, y los contenedores de OS X aún no están completamente obsoletos... todavía).
Pero espera, dices. ¿No estamos comparando manzanas con naranjas: sistemas de software independientes en una sola máquina como Emacs/JDK/Android/Chrome versus sistemas multiservidor y API como los servicios en la nube?
Bueno, ayer tuiteé sobre esto, pero al estilo de Larry Wall (creador del lenguaje de programación Perl - aprox. per.) según el principio "sucks/rules" busqué la palabra en los sitios de desarrolladores de Google y Amazon. Y aunque AWS tiene bajar veces más ofertas de servicios que GCP, la documentación para desarrolladores de Google menciona la obsolescencia unas siete veces más a menudo.
Si alguien en Google está leyendo esto, probablemente esté listo para sacar gráficos al estilo de Donald Trump que muestran que en realidad están haciendo todo bien y que no debería hacer comparaciones injustas como "número de menciones de la palabra obsoleta versus número de servicios" "
Pero después de todos estos años, Google Cloud sigue siendo el servicio número 3 (nunca escribí un artículo sobre el intento fallido de convertirse en el número 2), pero si hay que creer a los expertos, existen algunas preocupaciones de que pronto podría caer a No. 4.
No tengo ningún argumento convincente para "probar" mi tesis. Todo lo que tengo son los coloridos ejemplos que he acumulado durante 30 años como desarrollador. Ya he mencionado la naturaleza profundamente filosófica de este problema; de alguna manera está politizado en las comunidades de desarrolladores. Algunos creen que creadores Las plataformas deberían preocuparse por la compatibilidad, mientras que otros piensan que esto es una preocupación. usuarios (los propios desarrolladores). Uno de cada dos. De hecho, ¿no es una cuestión política cuando decidimos quién debe soportar los costos de los problemas comunes?
Entonces esto es política. Y probablemente habrá respuestas airadas a mi discurso.
cómo usuario Google Cloud Platform, y como usuario de AWS durante dos años (mientras trabajaba para Grab), puedo decir que existe una gran diferencia entre las filosofías de Amazon y Google en lo que respecta a las prioridades. No desarrollo activamente en AWS, por lo que no sé muy bien con qué frecuencia eliminan las API antiguas. Pero existe la sospecha de que esto no sucede tan a menudo como en Google. Y realmente creo que esta fuente de constante controversia y frustración en GCP es uno de los mayores factores que frenan el desarrollo de la plataforma.
Sé que no mencioné ejemplos específicos de sistemas GCP que ya no son compatibles. Puedo decir que casi todo lo he usado, 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 empecemos) , puntos finales en la nube Cloud Endpoint y hasta... No lo sé - absolutamente todo esto te obligaron a reescribir el código después de un máximo de 2 o 3 años y nunca automatizaron la migración por ti y, a menudo, . Como si se suponía que así fuera.
Y cada vez que miro AWS, me pregunto por qué diablos sigo en GCP. Claramente no necesitan clientes. Necesitan compradores. ¿Entiendes la diferencia? Dejame explicar.
Google Cloud tiene , donde la gente propone sus soluciones de software, y para evitar el efecto de restaurante vacío, necesitaban llenarlo con algunas propuestas, por lo que contrataron a una empresa llamada Bitnami para crear un montón de soluciones que se implementan con “un clic”, o debería Yo mismo lo escribo “soluciones”, porque no resuelven nada. Simplemente existen como casillas de verificación, como relleno de marketing, y a Google nunca le ha importado si alguna de las herramientas realmente funciona. Conozco gerentes de producto que han estado en el asiento del conductor y puedo asegurarles que a estas personas no les importa.
Tomemos, por ejemplo, una solución de implementación supuestamente de “un clic”. . Estaba harto de las travesuras de Google Cloud SQL, así que comencé a considerar la posibilidad de construir mi propio clúster Percona como alternativa. Y esta vez Google parecía haber hecho un buen trabajo, ¡me iban a ahorrar algo de tiempo y esfuerzo con solo hacer clic en un botón!
Bueno genial, vámonos. Sigamos el enlace y hagamos clic en este botón. Seleccione "Sí" para aceptar todas las configuraciones predeterminadas e implementar el clúster en su proyecto de nube de Google. Jaja, no funciona. Nada de esta basura funciona. La herramienta nunca fue probada y empezó a pudrirse desde el primer minuto, y no me sorprendería que más de la mitad de las "soluciones" sean implementaciones con un solo clic (ahora entendemos el por qué de las comillas). en general No funciona. Esta es una oscuridad absolutamente desesperada, donde es mejor no entrar.
Pero Google tiene razón. impulsos que los utilices. ellos quieren que lo hagas compraron. Para ellos es una transacción. ellos no quieren nada para apoyar. 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 la gente común siempre fueron despiadados en , que no cumple con el estándar de rentabilidad incluso si tiene millones de usuarios.
Y esto presenta un verdadero desafío para GCP porque es el ADN detrás de todas las ofertas de nube. No están tratando de apoyar nada; Es bien sabido que se niegan a alojar (como servicio gestionado) cualquier software de terceros. hasta entonces, 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 algo de esfuerzo para lograr que Google admita algo.
Esta falta de cultura de soporte, junto con la mentalidad de “rompámoslo para hacerlo más hermoso”, aliena a los desarrolladores.
Y eso no es bueno si quieres construir una plataforma duradera.
Google, despierta, maldita sea. Ya estamos en 2020. Todavía estás perdiendo. Es hora de mirarse detenidamente en el espejo y responder si realmente desea permanecer en el negocio de la nube.
Si quieres quedarte entonces deja de romper todo. Chicos, sois ricos. Nosotros los desarrolladores no. Entonces, cuando se trata de quién asumirá la carga de la compatibilidad, debes asumirla tú mismo. No para nosotros.
Porque hay al menos tres nubes más realmente buenas. Ellos hacen señas.
Y ahora pasaré a reparar todos mis sistemas averiados. Eh.
¡Hasta la proxima vez!
Actualización de PD después de leer algunas de las discusiones sobre este artículo (las discusiones son geniales, por cierto). El soporte de Firebase no se ha interrumpido y, que yo sepa, no hay planes. Sin embargo, tienen un error de transmisión desagradable que hace que el cliente Java se detenga en App Engine. Uno de sus ingenieros me ayudó a resolver este problema, cuando trabajaba en google, pero en realidad nunca solucionaron el error, por lo que tengo la mala solución de tener que reiniciar la aplicación GAE todos los días. ¡Y así ha sido durante cuatro años! Ahora tienen Firestore. Se necesitará mucho trabajo para migrar a él, ya que es un sistema completamente diferente y el error de Firebase nunca se solucionará. ¿Qué conclusión se puede sacar? puedes obtener ayuda si trabajas en una empresa. Probablemente soy el único que usa Firebase en GAE porque registro menos de 100 claves en una aplicación 100 % nativa y deja de funcionar cada dos días debido a un error conocido. ¿Qué puedo decir aparte de usarlo bajo su propio riesgo? Me estoy cambiando a Redis.
También he visto a algunos usuarios de AWS más experimentados decir que AWS generalmente nunca deja de admitir ningún servicio, y SimpleDB es un gran ejemplo. Mis suposiciones de que AWS no tiene el mismo fin de soporte que Google parecen estar justificadas.
Además, noté que hace 20 días el equipo de Google App Engine rompió el alojamiento de una biblioteca Go crítica, cerrando una aplicación GAE de uno de los principales desarrolladores de Go. Fue realmente estúpido.
Finalmente, escuché a empleados de Google discutir este tema y, en general, estar de acuerdo conmigo (¡los amo, muchachos!). Pero parecen pensar que el problema no tiene solución porque la cultura de Google nunca tuvo la estructura de incentivos adecuada. Pensé que sería bueno tomarme un tiempo para hablar sobre la experiencia absolutamente increíble que tuve trabajando con ingenieros de AWS mientras trabajaba en Grab. ¡Algún día en el futuro, espero!
Y sí, en 2005 tenían diferentes tipos de carne de tiburón en el buffet gigante del edificio 43, y mi favorita era la carne de tiburón martillo. Sin embargo, en 2006, Larry y Sergei se deshicieron de todos los snacks no saludables. Entonces, durante la historia de Bigtable en 2007, realmente no había tiburones y los engañé.
Cuando miré la nube Bigtable hace cuatro años (más o menos), aquí es donde estaba el costo. Parece haber disminuido un poco ahora, pero sigue siendo muchísimo para un almacén de datos vacío, especialmente porque mi primera historia muestra cuán intrascendente es una tabla grande vacía a su escala.
Perdón por ofender a la comunidad de Apple y no decir nada bueno sobre Microsoft, etc. Estás bien, ¡realmente aprecio toda la discusión que ha generado este artículo! Pero a veces es necesario generar un poco de revuelo para iniciar una discusión, ¿sabes?
Gracias por leer.
Actualización 2, 19.08.2020/XNUMX/XNUMX. Raya !
Actualización 3, 31.08.2020/2/2. Me contactó un ingeniero de Google en Cloud Marketplace que resultó ser un viejo amigo mío. Quería descubrir por qué CXNUMXD no funcionaba y finalmente descubrimos que era porque yo había construido mi red hace años y CXNUMXD no funcionaba en redes heredadas porque faltaba el parámetro de subred en sus plantillas. Creo que es mejor para los usuarios potenciales de GCP asegurarse de conocer suficientes ingenieros en Google...
Fuente: habr.com