F5 BIG-IP Next vs. Classic: La Guía de Migración de Ingeniería para 2026

La era de TMOS está terminando, y si todavía estás tratando tu balanceador de carga como un appliance monolítico en 2026, estás sentado sobre una bomba de tiempo de deuda técnica. El cambio de Classic BIG-IP a BIG-IP Next no es una mera actualización de versión; es una decapitación arquitectónica total del control plane, pasando de un sistema operativo monolítico basado en Linux a un motor nativo de Kubernetes impulsado por microservicios que finalmente elimina el 'bigip.conf' tal como lo conocemos.

La Realidad Post-TMOS: Por Qué Classic Está Muerto

Durante veinte años, los ingenieros de F5 vivieron y murieron con bigpipe y luego con tmsh. La arquitectura Classic de BIG-IP agrupaba el control plane, el management plane y el data plane en una única imagen fuertemente acoplada. Esto dificultaba la escalabilidad y hacía que las actualizaciones fueran peligrosas. A partir de 2026, la industria ha realizado la transición. BIG-IP Next bifurca completamente estas funciones. El data plane (TMM) ahora se ejecuta como un proceso en contenedores, mientras que el management plane se descarga a un controlador centralizado (BIG-IP Next Central Manager).

En los días de Classic, un CVE en la GUI de gestión significaba derribar todo tu motor de procesamiento de tráfico para aplicar el parche. En BIG-IP Next, el data plane está desacoplado. Ya no estás gestionando 'cajas'; estás gestionando instancias de tráfico de alto rendimiento cuyo ciclo de vida es administrado a través de Central Manager. Si no has visto las señales, mira las fechas de EOL para el iSeries y el cambio hacia el hardware VELOS y rSeries—estos son los puntos de aterrizaje finales para Classic antes del giro brusco hacia Next.

Análisis Profundo de la Arquitectura: Kubernetes como la Capa Inferior

Bajo el capó de BIG-IP Next, F5 finalmente ha adoptado el ecosistema de Kubernetes. Esto no es solo 'F5 en un contenedor'. Toda la orquestación del ciclo de vida de la instancia se maneja a través de primitivos de K8s. Cuando implementas una instancia de Next en una partición de VELOS o como un VE en ESXi, estás interactuando con un sistema que utiliza un enfoque API-first, tratando el balanceador de carga como un recurso efímero.

El Cambio a la Gestión Desacoplada

Classic BIG-IP usaba los procesos system-auth y mcpd para manejar el estado de la configuración. Este era el cuello de botella de cada despliegue a gran escala. BIG-IP Next mueve la 'fuente de verdad' al Central Manager. Tus instancias son esencialmente proxies sin estado. Esto permite una escalabilidad horizontal que antes era imposible. En 2026, estamos viendo despliegues empresariales donde un solo Central Manager controla más de 500 instancias de Next en múltiples clouds y clusters on-prem, una hazaña que habría requerido docenas de clusters BIG-IQ en el mundo antiguo.

Configuración: La Muerte de 'bigip.conf' y el Ascenso de AS3

Si todavía estás haciendo clic en la GUI para crear Virtual Servers, le estás fallando a tu organización. BIG-IP Next efectivamente exige la extensión Application Services 3 (AS3) o sus derivados evolucionados. Ya no hay un /config/bigip.conf para buscar. La configuración se almacena como JSON y se envía a través de una REST API.

{
    "class": "ADC",
    "schemaVersion": "3.0.0",
    "id": "NextMigration",
    "tenant1": {
        "class": "Tenant",
        "app1": {
            "class": "Application",
            "template": "http",
            "serviceMain": {
                "class": "Service_HTTP",
                "virtualAddresses": ["10.10.10.100"],
                "pool": "web_pool"
            },
            "web_pool": {
                "class": "Pool",
                "monitors": ["http"],
                "members": [{
                    "servicePort": 80,
                    "serverAddresses": ["192.168.1.10", "192.168.1.11"]
                }]
            }
        }
    }
}

Este cambio permite un verdadero GitOps. En 2026, el flujo de trabajo estándar es: el desarrollador envía un PR a un repositorio de GitHub -> el pipeline de CI/CD valida el JSON de AS3 -> Central Manager envía los cambios a las instancias de BIG-IP Next. Esto elimina la deriva manual de la configuración, que era la principal causa de interrupciones en la era Classic.

Brechas de Paridad: Lo Que Pierdes en la Transición

Seamos francos: BIG-IP Next no tiene una paridad de características del 100% con Classic, y probablemente nunca la tendrá. F5 está utilizando esta transición para deshacerse de la deuda técnica. Protocolos antiguos y características de nicho que estaban obstruyendo el kernel de TMOS han sido eliminados. Si dependes de conjuntos de comandos iRules oscuros de 2012, o de perfiles NTLM específicos heredados, te espera un mundo de problemas.

• Migración de iRules: F5 ofrece el "BIG-IP Next Migration Assistant", pero no es una varita mágica. Aproximadamente el 20% de los iRules complejos requieren una reescritura manual. Los iRules en Next son más eficientes pero más estrictos en sintaxis.
• AFM/ASM: Los módulos de seguridad han sido renombrados como 'BIG-IP Next WAF' y 'BIG-IP Next Access'. Los motores de políticas son más limpios, pero si vienes de una política ASM v15/v16 muy personalizada, la migración es un proceso de auditoría de varias semanas.
• Persistencia L7: Muchos métodos de persistencia heredados han sido deprecados en favor de la persistencia basada en cookies o la inspección universal a través de los estándares Modern TLS.

La Hoja de Ruta de Migración para 2026

Una migración deficiente fracasará. Recomendamos un enfoque de tres fases, que hemos documentado extensamente en nuestra guía de migración de F5 a SDN moderno.

Fase 1: Despliegue de Central Manager

No despliegues ni una sola instancia de Next hasta que tu Central Manager (CM) esté robustecido y tus integraciones con IPAM/DNS sean sólidas. El CM es el cerebro; trátalo con más reverencia de la que trataste al BIG-IQ. Asegúrate de tener un cluster de 3 nodos para el CM para alta disponibilidad.

Fase 2: Configuración Shadow y Conversión AS3

Toma tu configuración actual de Classic BIG-IP y pásala por el Migration Assistant. Para cada Virtual Server, genera la declaración AS3 correspondiente. Realiza pruebas de 'solo lectura' donde las implementes en una instancia de Next de laboratorio y verifiques que el comportamiento del data plane coincide con la salida del TMM legacy.

Fase 3: El Cambio de Tráfico

Usa la migración basada en DNS (GSLB/BIG-IP DNS) para transferir gradualmente el tráfico de las iSeries Classic a las instancias de Next. No intentes un reemplazo completo a nivel de dirección MAC. La pila de red subyacente en Next maneja ARP y enrutamiento de manera diferente, especialmente en entornos multi-tenant.

Rendimiento de Hardware: VELOS y rSeries en la Era Next

Ejecutar BIG-IP Next en hardware legacy es una receta para la frustración. Para aprovechar al máximo la arquitectura basada en K8s, necesitas la descarga asistida por FPGA que proporcionan los rSeries (por ejemplo, r5900 o r10900) o el chasis VELOS. Los rSeries proporcionan FPGAs dedicadas para la descarga de SSL/TLS que el data plane de Next aprovecha directamente a través de los drivers QuickAssist Technology (QAT).

En mis pruebas, una instancia de BIG-IP Next en un r10900 maneja un 40% más de TLS handshakes concurrentes que el software Classic v15 equivalente en el mismo hardware. ¿Por qué? Porque el data plane de Next está optimizado para la escalabilidad multi-core sin la sobrecarga de los procesos de gestión masivos que plagaban a Classic TMOS.

Costos Reales y Licenciamiento

F5 ha pasado completamente a un modelo basado en suscripción. Si todavía usas licencias perpetuas, 2026 es el año en que tus costos de mantenimiento se dispararán, ya que F5 incentiva el paso a F5 FlexPool o las suscripciones de BIG-IP Next. Espera pagar aproximadamente $15k-$25k al año por una instancia de Next de alto rendimiento (equivalente a una capa de throughput de 10Gbps), dependiendo de tus requisitos de WAF/Advanced Firewall.

Veredicto: ¿Deberías Moverte Ahora?

Si estás implementando una nueva infraestructura, no despliegues Classic. Solo estás construyendo un sistema legacy que tendrás que migrar en 24 meses. Si estás ejecutando cargas de trabajo estables en hardware iSeries, tienes hasta finales de 2026 para finalizar tu estrategia. Las ganancias de rendimiento en TLS 1.3 y la eficiencia operativa de AS3/GitOps hacen que la transición valga la pena el dolor inicial de la conversión de la configuración. Sin embargo, si tu equipo no está listo para la gestión API-first, quédate en Classic hasta que hayas contratado o capacitado para la realidad devops-centric de Next.

¿Listo para modernizar tu stack de ADC o necesitas una auditoría experta de tu entorno F5 actual? Consulta nuestros servicios de ingeniería y revisiones de arquitectura en techleague.io.