La interrupción del 17 de agosto

Causa de la interrupción y debate sobre escalado

• Muchos ven los incidentes como clásicos precipicios de capacidad: los sistemas funcionan bien y luego un pequeño aumento de carga (p. ej., de 2,8 mil millones a 2,9 mil millones de commits/mes) desencadena cuellos de botella ocultos y fallos en cascada.
• Otros argumentan que GitHub debería haber detectado antes condiciones de “capacidad máxima” y diseñado para evitar esos precipicios; “añadir más hardware” (3 millones de núcleos de CPU, 120 PB de almacenamiento) se considera insuficiente sin mejor arquitectura y resiliencia.
• Algunos comentaristas señalan que este tipo de fallo es común a hiperescalas; otros dicen que el RCA de GitHub parece el de un equipo que apenas ahora está construyendo prácticas maduras a gran escala.

Explosión de tráfico impulsada por IA

• El enorme crecimiento de commits se atribuye ampliamente a la programación con IA/agentes y a flujos de trabajo automatizados, no a más desarrolladores humanos.
• Muchos describen GitHub como inundado de “AI slop”: commits, PR e issues frecuentes, de baja calidad y generados automáticamente (Bun se cita repetidamente como un ejemplo extremo).
• Hay desacuerdo sobre si este crecimiento es “impresionante” (desde el punto de vista de infraestructura) o más bien como un “crecimiento canceroso” que degrada el servicio mientras añade poco valor.

Azure, Microsoft y arquitectura

• Existe un fuerte escepticismo de que “migrar a Azure” sea una solución cuando Azure es percibido (por algunos) como un gran problema de fiabilidad, especialmente para productos históricamente basados en colocation como GitHub/LinkedIn.
• Otros discrepan: cualquier plataforma grande (AWS, Azure, GitHub) tendrá interrupciones; culpar solo a Azure se ve como una simplificación excesiva.

Reintentos, avalanchas y resiliencia

• Las tormentas de reintentos (en particular las de clientes de Copilot/VS Code) se consideran un problema de “thundering herd” / amplificación de reintentos de libro.
• Hay una larga discusión sobre buenas prácticas: retroceso exponencial con jitter, circuit breakers, limitación del lado del cliente, token buckets y diferenciación explícita entre errores reintentables y no reintentables.
• Varios sostienen que la verdadera causa raíz es la falta de degradación elegante y de reducción de carga, no solo de capacidad insuficiente.

Nivel gratuito, AI slop y modelo de negocio

• Muchos sospechan que la economía de GitHub está bajo presión: alojamiento masivo gratuito (incluido código generado por IA y Actions) frente a un presupuesto de infraestructura finito.
• Mitigaciones propuestas: límites de commits por usuario o por organización, limitación de tasa, niveles mínimos de pago (p. ej., 1 USD/mes) y separación de grupos de capacidad gratuitos y de pago.
• Contrapunto: Microsoft podría subvencionar gustosamente GitHub como un producto de captación para impulsar la adopción de IA y extraer código como datos de entrenamiento, aunque eso perjudique la fiabilidad.

Alternativas y autoalojamiento

• Hay un fuerte interés en GitLab autoalojado, Forgejo/Gitea, Codeberg, Sourcehut y nuevos foros “AI-native”.
• Se discuten las compensaciones:
  • Autoalojamiento: coste administrativo continuo moderado, pero mejor control, aislamiento del AI slop y sin punto único de fallo.
  • GitLab: maduro pero más caro y “engorroso”; menos interrupciones, pero no inmune.
  • Forgejo/Codeberg: FLOSS, más ligero, pero con un ecosistema de CI/aplicaciones más débil; la postura política de Codeberg preocupa a algunos.
  • Sourcehut: se elogia su flujo de trabajo basado en correo electrónico, pero es de pago y de nicho.

Experiencia de producto y flujos de trabajo de GitHub

• Algunos afirman que GitHub es el “más sofisticado” para issues/PR/CI integrados; muchos otros dicen que es “el peor en cada aspecto individual” pero gana por consolidación y efectos de red.
• Muchos equipos serios tratan ahora GitHub solo como un host git y hacen la planificación y el seguimiento de issues en otro sitio (p. ej., Linear).
• Actions se cita repetidamente como poco fiable bajo carga y como un punto doloroso para empresas.

Liderazgo, comunicación y confianza

• Molesta notablemente que la entrada del blog de GitHub use lenguaje corporativo (“we let you down”) sin un “lo sentimos” explícito ni compromisos concretos de reembolsar/compensar a los clientes de pago.
• A algunos les inquieta que el perfil público del CTO de GitHub no muestre código visible en el último año; otros sostienen que el trabajo de un CTO es liderar, no codificar activamente.
• Los usuarios empresariales están especialmente frustrados de que las interrupciones parezcan afectar por igual a usuarios de pago y gratuitos, y quieren un aislamiento estricto o infraestructura separada para los clientes de pago.

Preocupaciones más amplias: valor, entorno y calidad del software

• Varios hilos cuestionan si el crecimiento explosivo de commits ha producido un software o experiencias de usuario notablemente mejores; muchos dicen que el software de consumo está empeorando pese a haber más código.
• Otros responden que la IA ha empoderado a personas que no programan y ha permitido a aficionados crear herramientas que antes nunca habrían podido, aunque estos beneficios suelen ser personales y no muy visibles.
• El impacto ambiental de la IA y los centros de datos genera debate: algunos ven el consumo energético de la IA como moderado y compensable mediante mejoras de eficiencia; otros lo ven como un serio retroceso para los objetivos climáticos, especialmente dada la cancelación de objetivos de CO₂ por parte de grandes proveedores.