Migrando de Kubernetes a stack más simple: caso real de reducción de complejidad

La narrativa pública de los últimos seis años fue siempre en la misma dirección: todo el mundo migra hacia Kubernetes. Conferencias, posts patrocinados, vacantes de SRE, casos de proveedor — el vector es único. Salió de máquina virtual desnuda y subió a K8s. Salió de Heroku y subió a K8s. Salió de Docker Compose y subió a K8s. La dirección es una sola flecha, y quien no está en la flecha debe estar haciéndolo mal.

La realidad silenciosa que nadie publica en conferencia es el vector inverso: cientos de equipos migran fuera de Kubernetes después de descubrir que pagaron caro por la complejidad que no necesitaban. No es titular, pero ocurre todos los meses. Empresa de quince devs con cluster EKS de seis nodos percibe que el equipo de plataforma se volvió la mitad del presupuesto de ingeniería. Startup que adoptó K8s al segundo día descubre que tres años después todavía gasta un viernes entero al mes solo actualizando versión de Helm chart de operadores. Equipo de producto que debería estar shippando feature está depurando webhook de admission controller.

Este post es el playbook para esa migración inversa, con las trampas reales que vimos suceder. No es pitch — es manual operacional. Si lees esto y decides quedarte en Kubernetes, genial. La decisión informada de quedarse es tan valiosa como la decisión informada de salir.

La pregunta de calificación: ¿deberías siquiera considerar esto?

Antes de cualquier cosa, descarta el caso. Migración inversa solo tiene sentido para un perfil específico — y la mayoría de los equipos que piensa en salir de K8s no está en ese perfil. Los demás están investigando alternativa cuando deberían estar contratando un SRE más o simplificando el uso actual del K8s.

El perfil en que la migración tiene sentido tiene seis señales simultáneas:

Señal 1: la empresa corre Kubernetes en producción hace un año o más. Migración no es experimento. Si el equipo está en K8s hace tres meses y ya está reclamando, el problema es onboarding, no plataforma. Espera el ciclo de aprendizaje completar antes de declarar quiebra.

Señal 2: el equipo de plataforma tiene entre una y tres personas. Empresas con cinco o más ingenieros dedicados a plataforma tienen escala de operación que justifica K8s. Por debajo de eso, la herramienta tiende a consumir el equipo entero en mantenimiento.

Señal 3: el cluster tiene menos de cincuenta servidores en producción. Por encima de ese número, el ecosistema de K8s te da herramientas de tooling — escalado horizontal de nodos, balanceo entre regiones, federación multi-cluster — que otra stack no te da. Por debajo, estás pagando overhead por capacidad que no usas.

Señal 4: las apps son típicas. Web HTTP, base relacional, cache en memoria, jobs asíncronos, alguna cola. Si el stack incluye operador exótico de base distribuida, malla de servicio con políticas L7 sofisticadas, o agendamiento de GPU para entrenamiento de modelo, la migración inversa se complica.

Señal 5: 80% del tiempo de plataforma es mantenimiento, no feature nueva. Si el equipo de plataforma pasa la mayoría de las semanas actualizando Helm chart, depurando upgrade de versión de cluster, o arreglando webhook que falló, es síntoma claro. La plataforma se volvió producto interno que se consume a sí mismo.

Señal 6: el salario total de plataforma representa más del 5% del MRR. No es regla absoluta, pero es métrica útil. Cuando el equipo que opera la infra cuesta más que un veintavo del ingreso recurrente mensual, la infra está demasiado cara para la escala actual de la empresa.

Si tu empresa marca las seis, vale la pena leer el resto del post. Si marca tres o cuatro, lee pero decide con cautela. Si marca una o dos, probablemente el problema es otro.

Quién definitivamente no debe migrar

Misma honestidad en el inverso. Existe perfil en que salir de K8s es decisión equivocada, y quien encaja debería cerrar esa pestaña.

Equipo fuerte de plataforma con proceso maduro. Si tienes cinco ingenieros de plataforma que dominan K8s, pipeline de CI/CD estable, runbook escrito, observabilidad configurada — salir de todo eso para empezar de cero en un stack más simple es tirar inversión real. La simplicidad del destino no compensa el reset.

Stack que depende de operadores críticos. Base relacional con replicación automática gestionada por operador, cola distribuida con balanceo gestionado por operador, base columnar con bootstrap automático. Esos operadores son valor real. Cambiar a "humano cuida de eso" es regresión operacional, no simplificación.

Compliance que exige Kubernetes nominalmente. Algunos frameworks de auditoría — FedRAMP en determinados niveles, ciertos contratos de gobierno, algunos sellos de seguridad sectoriales — listan herramientas pre-aprobadas. Si tu compliance officer necesita apuntar a un certificado existente, K8s es la respuesta. Migrar a herramienta que no está en la lista crea fricción que cuesta más que economía.

Federación multi-cluster en producción. Si corres workloads que se mueven entre clusters en regiones diferentes, con replicación de estado coordinada por herramienta tipo Argo o FluxCD en modo multi-cluster, el ecosistema de K8s tiene primitivas que otros stacks no tienen. Migrar de eso es proyecto de seis meses como mínimo.

Workloads de ML/AI con agendamiento de GPU complejo. Entrenamiento distribuido, particionamiento de GPU, agendamiento que entiende afinidad de hardware específico. K8s tiene operadores y plugins maduros para eso. Stack más simple no tiene.

Si encajas en cualquiera de esos cinco, la recomendación honesta es quedarse donde estás y optimizar el uso actual de K8s.

Pre-flight assessment: uno a dos días antes de comprometer

Migración inversa empieza con inventario. Antes de marcar reunión de "vamos a salir de K8s", el equipo necesita medir lo que tiene hoy. Sin números, la decisión es vibe — y vibe no sobrevive al primer problema imprevisto durante cutover.

Inventario de manifests. Corre kubectl get all -A --output yaml > all.yaml y cuenta. ¿Cuántos archivos en el repositorio de manifiestos? ¿Cuántas líneas en el agregado? ¿Cuántos namespaces? Nuestra medición informal en equipos pequeños: empresa con diez apps típicas suele tener entre 1.500 y 4.000 líneas de YAML, distribuidas entre Deployment, Service, Ingress, ConfigMap, Secret, HorizontalPodAutoscaler, y algún NetworkPolicy. Cada una de esas líneas es trabajo de migración.

Inventario de releases Helm. helm list -A muestra cada chart instalado. Cada uno es una decisión. ¿Chart de operador de base — va a volverse job común en el destino, con replicación manual? ¿Chart de ingress — va a volverse config de router integrado? ¿Chart de monitoring — va a volverse agente externo? Cuantos más charts, más tiempo de migración.

Inventario de operadores. kubectl get crds lista cada Custom Resource Definition. Cada CRD es una dependencia crítica que probablemente no tiene equivalente directo en el destino. Si la salida tiene tres o cuatro CRDs (cert-manager, ingress-nginx, prometheus-operator, sealed-secrets), está dentro de lo esperado para equipo pequeño. Si tiene treinta CRDs, la migración no es trivial — construiste plataforma sobre plataforma.

Inventario de RBAC y políticas complejas. NetworkPolicy declarando aislamiento entre namespaces, PodSecurityPolicy o PodSecurityStandards configurados, RoleBinding de granularidad fina. Todo eso necesita equivalente en el destino, y el equivalente raramente es 1:1.

Volumen de tráfico. Solicitudes por segundo en el horario pico, conexiones simultáneas en la base, throughput agregado de salida. El destino necesita absorber todo eso. Si nunca lo mediste, mídelo ahora — antes de comprometer cronograma de migración.

Mapeo de Service a Ingress. Cada Service expuesto se vuelve punto de entrada en el destino. Lista de dominios, certificados asociados, sticky sessions configuradas, reglas de path-based routing. Sin esa lista, la migración se rompe exactamente en el momento de cutover.

Ese assessment lleva uno a dos días para un dev competente. Es barato. Saltarse esa etapa es la mayor fuente de migración que estalla cronograma.

Decisión de stack destino

Cuatro opciones principales hoy para equipo pequeño. Cada una con trade-off explícito.

Opción A: Docker Swarm. Compatibilidad directa con formato Compose, multi-server simple, baja curva de aprendizaje. Bueno para equipo de un dev que ya conoce Compose. Limitación seria: Swarm está en modo mantenimiento hace tiempo, sin desarrollo activo de feature nueva. Corre y funciona, pero estás apostando en herramienta que no evoluciona.

Opción B: Nomad. Similar a K8s en modelo declarativo, pero más simple y con binario único. Bueno para quien gusta de modelo declarativo robusto y quiere HA real. Limitación: la licencia cambió a modelo restringido desde 2023, y la empresa detrás fue adquirida en 2025. Para adopción nueva hoy, es camino con asterisco.

Opción C: HeroCtl. Orquestador independiente con plano de control replicado, binario único, configuración corta. Bueno para quien quiere simplicidad operacional y alta disponibilidad real desde el primer día. Limitación honesta: ecosistema menor que K8s, sin biblioteca profunda de operadores listos.

Opción D: panel self-hosted (Coolify, Dokploy, similares). Panel web que orquesta Docker en una máquina o pequeño conjunto. Bueno para equipo muy pequeño sin requisitos formales de HA. Limitación: arquitectura que no soporta consenso distribuido real entre varios servidores — creció, se volvió punto único de falla.

La elección depende del perfil. Equipo de un dev sin requisito de SLA = Opción D. Equipo pequeño con requisito de HA real = Opción C. Equipo que prefiere modelo declarativo robusto y acepta licencia restringida = Opción B. Equipo ya invertido en Compose = Opción A.

Los cinco pasos de la migración

A partir de aquí el playbook asume que el stack destino es HeroCtl, pero el esqueleto se aplica a cualquier destino. Ajusta los mapeos conceptuales para Swarm/Nomad/Coolify según elección.

Paso 1 — Setup del destino en paralelo (una semana)

Regla dura: nunca migrar in-place. El cluster K8s actual sigue corriendo intocado durante toda la migración. El destino se provisiona en paralelo, en servidores nuevos, con dominio temporal o subdominio de prueba.

Tres a cinco servidores Linux nuevos. Instalar el stack destino. Validar que la red entre los servidores funciona, que el storage persiste después de reboot, que certificados son emitidos automáticamente, que secretos pueden ser inyectados en apps. Conectar el destino con el mismo registry de imágenes que el K8s actual usa — así la misma imagen que corre en producción va al destino sin rebuild.

Ese paso es deliberadamente liviano. La intención es probar que el destino funciona con app sintético antes de comprometer migración de app real.

Paso 2 — Migración de manifests para spec del destino (una a dos semanas)

La mayor parte del esfuerzo está aquí. Cada workload del K8s necesita ser reexpresado en el formato del destino. El mapeo conceptual de K8s para HeroCtl sirve de referencia:

• Deployment + ReplicaSet → job con replicas: N. El concepto es el mismo: N copias del mismo workload, balanceadas entre servidores.
• Service ClusterIP → service interno. En HeroCtl no necesita crear — cualquier task tiene nombre resolvible dentro del cluster por defecto.
• Service LoadBalancer o Ingress → ingress integrado. Sin operador externo, sin cert-manager separado, sin ingress-nginx — todo embebido en el orquestador.
• Pod → task. Concepto 1:1.
• PersistentVolume → volumen nombrado. Puede exigir copia de datos, dependiendo del storage backend usado en K8s.
• ConfigMap → bloque de env o archivo en el spec. No hay objeto separado.
• Secret → secreto integrado del orquestador. Cifrado en reposo en el plano de control.
• HorizontalPodAutoscaler → política de scaling en el spec del job. Disparada por uso de CPU, RAM, o métrica custom.
• DaemonSet → job con restricción de placement "1 por nodo".
• CronJob → job tipo periodic con expresión cron.
• Helm chart → spec custom. No convierte 1:1 — reescribir a mano.

En líneas brutas, la reducción es dramática. Una app web típica en K8s tiene 30 a 50 líneas de Deployment, más 20 de Service, más 50 a 100 de Ingress + cert-manager + annotations. Total 100 a 170 líneas. El equivalente en HeroCtl queda entre 30 y 50 líneas, agregando todo en un único archivo.

Tiempo medio de migración por app: uno a tres días para dev competente. Diez apps en tres semanas es ritmo realista. Si llega mucho más lento, hay operador escondido o complejidad no detectada en el assessment — para y remide.

Paso 3 — Migración de base y storage (uno a tres días)

Dos estrategias. Si la base es gestionada (RDS, Cloud SQL, equivalente), el destino solo apunta a la nueva cadena de conexión y listo — la base queda donde estaba, agnóstica de plataforma. Si la base es self-hosted en K8s, es dump-and-restore manual: pg_dump en la base antigua, pg_restore en la nueva, con ventana de mantenimiento corta en el momento de cutover.

Volúmenes persistentes de K8s se vuelven volúmenes nombrados en el destino. Puede exigir copia de datos vía rsync o snapshot — dependiendo del storage backend, eso es ventana adicional.

Los secretos son extraídos del K8s y reinsertados en el destino. Usa canal seguro (kubectl get secret -o yaml es solo medio de lectura; nunca commitar archivo intermedio). En HeroCtl, los secretos son sometidos vía API con TLS y quedan cifrados en el plano de control.

Paso 4 — Cutover (una a tres horas, normalmente nocturno)

El paso crítico. Pre-checks antes de cualquier cambio de DNS: smoke test en el destino — login funciona, página principal carga, base está conectada, latencia es aceptable, cola procesa job, métricas llegan en el monitoring. Si alguno de los cinco falla, aborta el cutover.

DNS preparado: TTL reducido a 60 segundos veinticuatro horas antes de la ventana. Sin eso, propagación lleva horas y rollback es doloroso.

Cutover propiamente dicho: cambia el registro DNS para apuntar a las IPs del destino. Monitorea 5xx y latencia en ventana de cinco minutos. Si algo se rompe significativamente en los primeros treinta minutos, switch DNS de vuelta al K8s — rollback completo en sesenta segundos de propagación adicional.

Mantén el cluster K8s corriendo como standby por treinta días. No apagues. El costo extra está justificado: si algún bug latente aparece en la semana tres del destino, todavía tienes adónde volver.

Paso 5 — Decommission del K8s (una a dos horas, después de treinta días)

Treinta días después del cutover, sin incidente significativo, hora de apagar. kubectl delete cluster en el caso self-hosted, o aws eks delete-cluster (o equivalente en otras nubes) en el caso gestionado. Cancelar managed addons separadamente — la factura tiene ítems que no desaparecen solo con delete-cluster.

Reembolso prorrateado del mes corriente del plan gestionado, si el proveedor lo ofrece. Cancelación de las instancias de worker. Backup final del estado del cluster antes del delete, en caso de auditoría futura.

Las seis trampas del camino

Assessment técnico cubre lo que logras medir. Las trampas abajo son lo que escapa al assessment y rompe el cronograma. Cada una ya causó migración que estalló plazo en algún equipo real.

Trampa 1: dependencia oculta en operador. Crees que no tienes operador complejo, pero cert-manager + ingress-nginx + sealed-secrets ya es stack de tres operadores. Y probablemente tiene más — kube-state-metrics para monitoring, external-dns para actualizar DNS automáticamente, reloader para reiniciar pods cuando ConfigMap cambia. Mapear todo. Cada operador es trabajo de migración que el assessment superficial pierde.

Trampa 2: asumir que Helm chart es reescribible en un día. Chart simple con cinco templates es reescritura de pocas horas. Chart complejo con treinta templates, valores anidados, hooks de pre-install/post-install, y dependencias de subcharts puede llevar una semana solo para mapear a spec equivalente. Calibra la estimación por el chart más complejo, no por el más simple.

Trampa 3: sticky sessions sin documentar. El ingress-nginx en K8s soporta sesión persistente por configuración de annotation. Si la app depende de eso (carrito de compras, sesión de admin, websocket persistente) y nadie lo documentó, la migración se rompe exactamente en el cutover cuando un usuario empieza a alternar entre dos servidores backend y pierde estado de sesión. Auditar configuración de ingress antes — no confiar solo en lo que el equipo recuerda.

Trampa 4: límites de recurso diferentes. K8s usa limit/request con semántica precisa: request es garantía, limit es techo. El destino puede tener modelo declarativo diferente (límite hard, o cuota agregada por job, o semántica de soft-limit). Error de tuning aquí rompe autoscaling — la app queda subdimensionada en producción y no escala cuando debería, o sobredimensionada y desperdicia capacidad. Remedir consumo real después del cutover, ajustar límites en la primera semana.

Trampa 5: formato de log. Algunos ingress en K8s emiten log en JSON por default — parser downstream (Loki, Datadog, ELK) está configurado para ese formato. Destino puede emitir log en texto plano o formato diferente. Parsing downstream se rompe silenciosamente — alertas paran de dispararse porque el pattern no coincide más. Verificar formato de log del router integrado del destino antes del cutover.

Trampa 6: pipeline de CI/CD acoplado. GitOps con ArgoCD o FluxCD apuntando a K8s necesita ser retrabajado. Si el pipeline aplica manifiesto declarativo con kubectl apply o helm upgrade, eso no funciona en el destino. Adapter scripts en la etapa de deploy son necesarios — recibir el manifiesto viejo, traducir a spec nuevo, someter vía API. Estimar una a dos semanas solo para pipeline de CI/CD, separado del tiempo de migración de manifests.

Cronograma realista

Calibración honesta de expectativa, en tres rangos de tamaño.

Equipo de uno a dos devs, cinco a diez apps: cuatro a seis semanas total. Descomposición: una semana de setup del destino, dos a tres semanas de migración de manifests y ajuste, uno a tres días de cutover, treinta días de operación paralela, un día de decommission. Atención: el trabajo de migración roba foco del desarrollo de producto durante ese período. Considera ventana de feature freeze.

Equipo de tres a cinco devs, veinte a cincuenta apps: ocho a doce semanas. La multiplicación no es lineal — apps adicionales aumentan matriz de pruebas de cutover. Vale la pena dedicar una persona a tiempo completo a la migración y mantener al resto del equipo en producto.

Empresa con cien o más apps: proyecto de cuatro a seis meses, con una a dos personas dedicadas. En ese tamaño, la migración se vuelve fase con gerente de proyecto, hitos quincenales, y reportes de status. No es sprint.

Resultados típicos post-migración

Rangos observados en equipos que completaron la migración. No son garantías — son puntos de referencia.

• Reducción de RAM total: 30% a 50%. El overhead de Kubernetes es real, y desaparece cuando sales. Cluster que usaba 32 GB de RAM agregado se vuelve algo entre 16 y 22 GB para el mismo workload.
• Reducción de costo cloud: 40% a 70%. Viene de tres frentes: sin managed control plane (US$73/mes por cluster sale del presupuesto), sin NAT gateway por subnet (algunos proveedores cobran por GB), instancias menores posibles (overhead de plataforma sale del consumo).
• Tiempo de deploy: similar o ligeramente mejor. No es donde está la ganancia — K8s es razonablemente rápido en deploy cuando está configurado bien.
• Tiempo de aprendizaje para dev nuevo: una semana, contra cuatro a seis en K8s. El modelo mental es más simple — menos abstracciones intermedias entre "quiero correr esto" y "está corriendo".
• Tiempo de operación mensual: una a tres horas-dev de mantenimiento, contra veinte a cuarenta en K8s. La ganancia mayor. Es aquí que el ROI se materializa.

Para calibrar la última métrica: cluster público de demostración nuestro corre en cuatro servidores totalizando cinco vCPUs y diez gigabytes de RAM, con plano de control ocupando entre 200 y 400 MB por servidor. Elección de nuevo coordinador, en caso de falla del actual, lleva cerca de siete segundos. Spec de aplicación típica en HeroCtl tiene cerca de cincuenta líneas — comparado a trescientas líneas o más de YAML en Kubernetes para equivalente "hello world" con TLS e ingress.

La pregunta inevitable: ¿va a volver a Kubernetes eventualmente?

Honestidad. Depende de escala.

Equipo que crece a treinta o más devs, con cien o más servidores en producción, multi-región, con requisito de federación entre clusters, eventualmente choca con el techo de stack más simple. En esa escala, K8s se vuelve elección racional — el ecosistema te da herramientas que otros stacks no tienen. La migración de vuelta es proyecto de meses, no de días, pero es camino viable.

Para startups que se mantienen sub-cincuenta servidores a lo largo de cinco años — la mayoría absoluta de ellas — raramente tiene sentido volver. La ganancia operacional del stack más simple se mantiene durante toda la vida útil del producto.

Migración reversa (HeroCtl → K8s) también es proyecto de semanas, no días. No es decisión one-way. Si la empresa crece mucho más rápido de lo que esperaba, el camino de vuelta existe — más caro que quedarse, pero existe. La decisión de migrar ahora no te encadena para siempre.

Preguntas que recibimos

¿En cuánto tiempo paga el ROI? Para equipo de uno a dos devs con cluster pequeño, la migración paga en tres a seis meses — el salario equivalente de tiempo recuperado en mantenimiento excede el costo del proyecto de migración. Para equipos mayores, depende de cuánto el equipo de plataforma consumía en mantenimiento; típicamente seis a doce meses.

¿Puedo mantener Kubernetes para un workload específico y migrar el resto? Sí, y en algunos casos es la estrategia correcta. Workload con operador crítico (base distribuida, cola con balanceo gestionado) queda en K8s. El resto va a stack más simple. Los dos clusters conviven con dominios separados o path-based routing en un router upstream. Cuesta un poco más que consolidar, pero evita reescribir lo que todavía funciona bien.

Helm charts complejos: ¿vale la pena reescribir? Caso a caso. Chart de operador de tercero con cincuenta archivos: probablemente no vale la pena, mantén en K8s o cambia la tecnología. Chart propio con veinte templates: vale la pena, es reescritura de pocos días y elimina dependencia de Helm.

¿ArgoCD funciona con HeroCtl? No directamente — ArgoCD fue hecho para aplicar manifiesto K8s. Pero el concepto de GitOps funciona: pipeline observa el repositorio, traduce spec del destino a payload de API, somete vía curl autenticado. Plugin nativo está en consideración; por ahora es adapter script de cincuenta líneas.

El equipo que aprendió Kubernetes — ¿van a quedar resentidos? Pregunta legítima. Curva de aprendizaje de K8s es inversión real, y a nadie le gusta ver inversión descartada. Conversación directa: la habilidad no desaparece. K8s sigue siendo estándar de mercado para escala grande, y dev que ya dominó sigue empleable y valioso. La migración es decisión de producto para escala actual, no veredicto sobre el conocimiento individual.

¿Cloud agnostic es más o menos viable después? Más viable, en la práctica. Stack más simple corre en cualquier servidor Linux con Docker — bare metal, VPS de cualquier proveedor, instancia de cualquier nube. K8s gestionado te ata al proveedor (EKS en AWS, GKE en Google, AKS en Azure) — cada uno con sabor propio. Salir amplía opciones.

¿Hay caso público de empresa que hizo esa migración? Varios, pero la mayoría no publica en conferencia (el vector narrativo sigue siendo K8s para todos lados). En foros y en conversaciones informales, es fácil encontrar relato. Si quieres conversar con alguien que hizo la migración, escríbenos — hacemos el puente.

Cierre

La decisión de salir de Kubernetes a stack más simple no es confesión de derrota — es reconocimiento de que la herramienta correcta depende de la escala actual de la empresa, y que la escala actual de la empresa no es la del libro de marketing del coloso. Equipo pequeño, cluster pequeño, apps típicas, plataforma consumiendo mitad del presupuesto de ingeniería: es exactamente el escenario en que la migración inversa paga.

No es decisión de una tarde. Es proyecto de cuatro a seis semanas para equipo pequeño, con inventario, mapeo, cutover nocturno, treinta días de operación paralela, y decommission cuidadoso. Pero es proyecto cuyo ROI se mide en horas-dev recuperadas todos los meses — todos los meses, durante los próximos años de la empresa.

Si quieres experimentar HeroCtl como destino candidato:

curl -sSL get.heroctl.com/install.sh | sh

Corre en cualquier servidor Linux con Docker. Tres servidores forman plano de control replicado con alta disponibilidad real. Spec de aplicación queda entre treinta y cincuenta líneas, agregando todo lo necesario (replicación, ingress, certificado automático, secretos). Plan Community gratuito permanente cubre todo el stack descrito aquí — solo Business y Enterprise agregan SSO, RBAC granular, auditoría detallada, escrow de código y soporte con SLA, dirigidos a empresas con requisitos formales de plataforma.

Para contexto adicional, k3s vs HeroCtl: cuándo cada uno tiene sentido trata de la elección cuando el equipo ya decidió salir del K8s vanilla pero duda entre distribución ligera de K8s y orquestador independiente. Y Kubernetes overkill: cuándo no lo necesitas es el argumento de fondo para quien todavía no está convencido de que la complejidad es innecesaria en la escala actual.

Migración inversa no es titular de conferencia. Pero es la decisión correcta para más equipos que lo que la narrativa pública admite.