Tras una migración de 11 semanas a Kubernetes, una empresa olvida por qué existe (2020)

 (theolognion.com)
1 puntos por GN⁺ 2024-03-02 | 1 comentarios | Compartir por WhatsApp
  • La startup de Silicon Valley Xenobroom Inc. decidió migrar su infraestructura de servidores existente a Kubernetes cuando el uso diario se disparó durante la pandemia, en mayo de 2020
  • La migración pasó de ser una simple mejora de despliegue a un trabajo de largo plazo para revisar y rediseñar su configuración basada en scripts bash y VPS
  • El alcance siguió ampliándose al incluir actualizaciones de dependencias y bibliotecas, la conversión de partes de PostgreSQL a un almacenamiento KV distribuido y el aprovechamiento de la flexibilidad de AWS
  • El servidor de staging existente y los despliegues diarios desde la rama develop fueron reemplazados por un flujo de trabajo de CI solo para producción, con enrutamiento dinámico, pruebas A/B y soporte para dependencias regionales
  • Cuando la migración parecía haber terminado, nadie en la organización recordaba el propósito del producto, y usuarios e inversionistas admitieron que tampoco habían entendido el producto original, lo que hizo que restaurarlo fuera prácticamente imposible

Alcance ampliado por la migración a Kubernetes

  • Xenobroom Inc. inició en mayo de 2020 una actualización de su infraestructura de servidores
    • Según fragmentos del diario del CEO y notas de ingeniería del CTO, el uso diario aumentó bruscamente durante la pandemia
    • Luego se decidió migrar la infraestructura existente a Kubernetes
  • El trabajo se alargó más de lo esperado
    • Había que recrear, revisar y rediseñar los simples scripts bash y las máquinas VPS
    • Dentro de la empresa vieron la oportunidad de actualizar también las dependencias y bibliotecas del software
  • El cambio de infraestructura derivó en una reestructuración mayor
    • Consideraron que podían reemplazar grandes partes de la base de datos PostgreSQL que funcionaba en una sola máquina por un almacenamiento KV distribuido
    • También se sumó el argumento de aprovechar la flexibilidad de AWS
    • Desapareció el simple servidor de staging desde el que se desplegaba diariamente desde la rama develop
    • En su lugar, se introdujo un flujo de trabajo de CI solo para producción con enrutamiento dinámico, y una configuración que soportaba de forma fluida pruebas A/B y dependencias regionales

Pérdida del propósito del producto y ayuda externa

  • Cuando el proceso de migración parecía haberse completado, dentro de la empresa nadie recordaba el propósito del producto
  • Los usuarios y los inversionistas tampoco pudieron resolver la situación
    • Ambos grupos admitieron públicamente que, desde el principio, nunca habían entendido bien el producto
    • Tras varias semanas de downtime, restaurar el significado del producto se volvió prácticamente imposible
  • El CEO buscó ayuda de Phutar Afrayughum, un médium y experto en percepción extrasensorial
    • Se lo presenta como alguien que ayudó a Google a aumentar su cuota en el mercado de apps de mensajería y que también participó en el desarrollo del framework Material Design
    • Sin embargo, esa ayuda se trata como “allegedly”, por lo que no se afirma como un hecho

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-02
Comentarios de Hacker News

  • Este artículo es todavía más gracioso: despedimos al 20% de los mandos medios y la productividad de desarrollo aumentó accidentalmente 3 veces
    https://www.theolognion.com/p/company-accidentally-increased...

    • Esto ni siquiera parece fácil de ver como sátira

  • En nuestro $dayjob también estamos haciendo una migración así, pero empezó hace 2 años y todavía no llegamos ni al 30%
    La gente que antes gritaba más fuerte “hay que irnos a Kubernetes, hay que matar el monolito” ahora se olvidó de Kubernetes porque está jugueteando con LLM
    A algunas personas realmente les encantan las pruebas de concepto y las novedades brillantes, y supongo que ese rol tiene cierta utilidad

    • Es una estructura en la que obtienen satisfacción laboral a través de tecnología nueva y reluciente
      Por eso parece que mucha gente inteligente trabaja bastante contenta incluso en grandes tecnológicas poco éticas, empresas de publicidad o de vigilancia
      No importa mucho por qué existe la empresa ni qué hace realmente fuera de su propia computadora; lo importante es la libertad de perseguir tecnología y cosas nuevas
      A las empresas les gusta la productividad y el entusiasmo que esta gente genera, y además les pagan bien
      Normalmente estos desarrolladores también tienen conciencia, pero muchas veces esa conciencia queda absorbida y exhibida en forma de activismo social “bueno” y favorable para la empresa
    • Esto se parece menos a expansión de alcance y más a desarrollo guiado por el currículum intencional
      Alguien va tachando casillas solo para poder decir “he trabajado con X”
      En equipos pequeños, esta forma de trabajar puede frenar la productividad muy rápido, y a menudo se disfraza como un deseo de resolver todos los problemas
      Pero el resultado es que no se resuelve ninguno y, de hecho, aparecen todavía más problemas
    • En empresas cercanas a FAANG es muy difícil ascender, y por la estructura de niveles muchas veces la única manera de subir el sueldo es ascender
      Para ascender necesitas un paquete de promoción, y para ese paquete necesitas proyectos grandes y pesados
      Al final, el problema central que se intenta resolver deja de ser una necesidad del negocio y pasa a ser el ascenso, y así nacen enormes proyectos que salen a buscar un problema
    • Quizá sirva para quemar dinero de la empresa
      Lo que describes ni siquiera parece una prueba de concepto. La condición básica de una prueba de concepto es que al menos funcione; esto se parece más a montar algo para seguir a la manada y parecer ocupado
      Tampoco parece un entorno en el que sea agradable quedarse mucho tiempo como empleado
    • Me da la impresión de que justamente esa clase de gente es la que más asciende. Es una estructura realmente retorcida

  • En ese blog hay artículos todavía más graciosos. Este en particular me gustó mucho:
    https://www.theolognion.com/p/dev-builds-perfect-note-taking...
    Y también está este:
    https://www.theolognion.com/p/ai-solves-all-political-econom...

  • Sé que es una broma, pero si se hiciera un análisis post mortem, la causa del fracaso probablemente sería: “mucha gente dentro de la empresa pensó que ya que estábamos, también podíamos hacer actualizaciones de dependencias de software y bibliotecas. Además, creyeron que una gran parte de la base de datos PostgreSQL que corría en una sola máquina podía convertirse en un almacén distribuido de clave-valor aprovechando la enorme flexibilidad de AWS”
    Hay que cuidar el alcance

    • Eso está muy cerca de ser justamente el centro de la broma
      En el mundo hay mucha gente más enfocada en la tecnología que usa que en el producto que construye
      Enfocarse en el producto significa conocer el alcance y no sobrediseñar demasiado pronto
      La broma se enfoca en Kubernetes, pero podría hacerse exactamente igual con renderizado del lado del servidor, AI, $modernFrontendLib o $modernLanguage
    • También hay que cuidar el alcance de la empresa
      Si tu negocio no es vender infraestructura en la nube, entonces basta con usar un proveedor de nube ya hecho
      Y si ya le estás pagando a un proveedor de nube, mejor todavía no usar Kubernetes

  • En la vida real, una migración a Kubernetes de 11 semanas se habría considerado un éxito rotundo

    • En realidad habría tomado 11 meses, y ahora estarían en alguna etapa de “cloud-native” o algo así
      Claro, operar la base de datos habría sido un poco duro. Seguro se olvidaron de configurar bien el almacenamiento de Kubernetes y, después de que el pod se moviera de repente, los datos desaparecieron
    • Si ya usas Docker, casi no hay razón para que tome tanto tiempo
      Si ni siquiera usaban Docker, entonces en una migración parecida es muy probable que el problema no sea Kubernetes en sí

  • Nunca ha sido tan fácil y barato operar sistemas como ahora
    Y aun así, los ingenieros prefieren organizar una expedición, escalar el Everest para entregar una pizza, tomarle una foto a la pizza en la cima, luego llevarla de vuelta a casa en avión, alquilar un Lamborghini para correr el Rally de Mongolia y recién 18 meses después entregar esa pizza
    Cuando en todo ese tiempo, si simplemente te subes a un scooter barato y bajas por la calle, ganas

    • Nunca he trabajado en un lugar donde la complejidad inyectada por los ingenieros se acercara a la complejidad inyectada por la gerencia

  • Si una tecnología es compleja, primero hay que aprenderla. Hay que probarla primero en un servicio pequeño y poco importante
    Hay que hacer una sola cosa a la vez y empezar de forma simple
    Yo migré nuestro servicio a Kubernetes sin problemas, pero me tomó 2 años aprender y experimentar moviendo servicios pequeños
    Probé varios enfoques antes de llegar al que mejor encajaba, y no era uno que pudieras encontrar directamente en internet
    Uso GitOps, pero sin automatizarlo; simplemente ejecuto kubectl apply -k para lo que hace falta, porque en ese momento pensé que flux era innecesariamente complejo para empezar
    Ahora que ya tenemos decenas de servicios y más entendimiento, estoy pensando en adoptar flux

  • En 1977 trabajaba como joven abogado litigante en un bufete que facturaba por hora
    Registrábamos en papel qué trabajo se hacía para cada caso, y el personal de oficina cortaba tiras desprendibles de los formularios completados y las pegaba en la parte interior de la carpeta de papel de cada caso
    En 1979 compré una RadioShack Tandy I y pronto me metí de lleno en Foxbase, un programa de base de datos basado en DOS para usar en casa. Más tarde se convirtió en FoxPro y Microsoft lo adquirió a principios de los 90
    En 1981 abrí mi propio bufete, y en ese entonces la innovación más reciente en productividad de oficina era el fax y una máquina de escribir eléctrica con pantalla de una sola línea, memoria y un pequeño disco para guardar formatos. Las empresas todavía no usaban computadoras personales
    Mi bufete pronto creció hasta unos 10 abogados y 12 empleados de apoyo, y les compré computadoras Compaq a todas las secretarias
    Pasé mucho tiempo escribiendo un programa de horas y facturación para reemplazar el sistema manual de pegar tiras, y también aprendí a instalar redes para hacerlo yo mismo
    Ningún otro bufete que yo conociera tenía una sola computadora, pero nosotros teníamos más de 10 para el personal de apoyo y 4 o 5 Compaq “portátiles” para que los abogados revisaran las facturas antes de enviárselas a los clientes
    Al mismo tiempo, estaba arruinando mi negocio. Teníamos tecnología de clase mundial en una época en la que los demás ni siquiera tenían una sola computadora, pero en vez de concentrarme en ejercer el derecho o venderle a clientes corporativos, cerraba la puerta y me dedicaba a programar
    Al final cerré el bufete en 1994
    Aun así, era una época emocionante. Pronto todos los bufetes tendrían computadoras para procesamiento de texto, pero todavía no existían programas comerciales de facturación
    Todos los abogados de otros bufetes con los que trabajé durante unos 24 meses querían mi programa de facturación
    Pero yo, mientras me ahogaba en el trabajo de los casos, solo me obsesionaba con la programación divertida, y mi práctica legal era el laboratorio perfecto para el programa. Lamentablemente, esa programación arruinó mi negocio

    • Ese sistema de tiras desprendibles es realmente interesante. Me pregunto si era una forma común de llevar el tiempo en esa época
      Si todavía existe alguna foto, me gustaría verla

  • En mi campo, si cambias “Kubernetes” por GraphQL/React/Next, sigue aplicando exactamente igual
    Claro, se trata de migrar una app que funciona perfectamente bien, y que además en su mayor parte es CRUD
    Y aun así lo hacen aunque no necesitan para nada los trade-offs que trae GraphQL o un frontend interactivo
    Cuanto más tiempo paso en esta industria, más veo que muchas de las personas en puestos de responsabilidad no tienen idea de lo que están haciendo

    • La gente no recibe recompensas por mantener funcionando algo que ya funciona bien
      Reciben recompensas por el cambio, y basta con que puedan fingir al menos que ese cambio está dando resultados o que algún día los dará

  • Llevo 4 meses peleando día y noche para mover 500 mil blobs de un MinIO autohospedado a un almacenamiento de blobs administrado, y menos de una semana ha sido trabajo realmente productivo, no política y burocracia
    Así que una migración a Kubernetes de 11 semanas suena como un éxito rotundo