La empresa olvida por qué existe tras una migración de 11 semanas a Kubernetes (2020)
Un artículo satírico sobre una empresa que “olvida” su propósito tras una migración de 11 semanas a Kubernetes lleva a los ingenieros a reflexionar sobre el sobreingeniería y la persecución de la última novedad tecnológica. Muchos describen migraciones de plataforma de varios años que frenan las hojas de ruta del producto, impulsadas por el desarrollo orientado al currículum, incentivos desalineados y fascinación por nuevas herramientas en lugar de necesidades de negocio. Los comentaristas abogan por un alcance más estricto, cambios incrementales y centrarse en el producto real en lugar de la infraestructura compleja por sí misma.
Sátira y tono del artículo
- Muchos lectores lo reconocen rápidamente como una parodia, comparándolo con una sátira al estilo Silicon Valley.
- El chiste del psíquico / material design y el remate sobre olvidar el propósito del producto funcionan muy bien.
- Varios señalan que otras publicaciones del mismo blog se acercan incómodamente a la realidad, difuminando la línea entre sátira y verdad.
Experiencias reales de migración a Kubernetes
- Varios comentaristas dicen que una migración de 11 semanas sería en realidad un éxito enorme; sus empresas llevan 1–3+ años en migraciones incompletas a K8s/plataformas.
- Otros sostienen que, si ya usas Docker y tienes sistemas simples, 11 semanas “deberían” bastar.
- Ese “deberían” es cuestionado por personas que describen realidades caóticas: mainframes antiguos, Java obsoleto, bloqueos de licencias ligados al hardware, dependencias externas desconocidas, políticas corporativas estrictas y burocracia.
- Algunos informan migraciones parciales (por ejemplo, 30% completadas después de 2 años) con las hojas de ruta del producto en pausa para centrarse en el trabajo de plataforma.
Obsesión por el stack tecnológico frente al valor de negocio
- La interpretación central: los equipos se obsesionan con Kubernetes / nuevos stacks y olvidan para qué sirve el producto.
- Varios describen a empresas “haciendo cosplay” de las grandes tecnológicas, a pesar de ser principalmente organizaciones de ventas o de negocio con necesidades técnicas modestas.
- Las migraciones a menudo carecen de un problema de negocio claro; a veces las configuraciones existentes (por ejemplo, ECS) funcionan perfectamente.
Debate sobre estrategia de cloud y Kubernetes
- Un bando: si no trabajas en infraestructura, usa cloud estándar y evita Kubernetes autogestionado; añade coste, complejidad y personal.
- Otro bando: Kubernetes gestionado (EKS, etc.) suele ser sensato y puede reducir el bloqueo con un proveedor y habilitar configuraciones escalables y distribuidas geográficamente.
- El debate toca sorpresas en los costes de cloud (especialmente egress, NAT y otros cargos ocultos) y si los temores al multicloud/portabilidad están justificados.
Deriva de alcance y prácticas de migración
- Un patrón de fallo citado con frecuencia: usar una migración a K8s para actualizar al mismo tiempo bibliotecas, cambiar bases de datos y rediseñar sistemas.
- Consejo de quienes tienen experiencia:
- Aprende primero con servicios pequeños y de bajo riesgo.
- Haz un cambio importante a la vez.
- Empieza con la configuración más simple viable; añade después herramientas como la automatización GitOps.
Incentivos y comportamiento de la industria
- Los ascensos y el reconocimiento favorecen los proyectos grandes y vistosos frente al mantenimiento silencioso de sistemas fiables.
- El desarrollo orientado al currículum y el gusto por las pruebas de concepto empujan a reescrituras constantes (K8s, GraphQL, React, IA) en lugar de mejoras incrementales.
- Algunos ven el churn de devops/plataforma como una forma de seguridad laboral; otros culpan a la dirección por alinear los incentivos con el cambio en lugar del valor.