F5 BIG-IP Next vs. Classic: O Guia de Migração de Engenharia 2026

A era TMOS está terminando, e se você ainda estiver tratando seu load balancer como um appliance monolítico em 2026, você está sentado em uma bomba-relógio de débito técnico. A mudança do Classic BIG-IP para o BIG-IP Next não é uma mera atualização de versão; é uma decapitação arquitetônica total do control plane, migrando de um OS monolítico baseado em Linux para um engine nativo de Kubernetes, orientado a microsserviços, que finalmente mata o 'bigip.conf' como o conhecemos.

A Realidade Pós-TMOS: Por Que o Classic Está Morto

Por vinte anos, engenheiros da F5 viveram e morreram por bigpipe e depois por tmsh. A arquitetura Classic BIG-IP agrupava o control plane, management plane e data plane em uma única imagem, fortemente acoplada. Isso tornava o scaling difícil e as atualizações perigosas. A partir de 2026, a indústria fez a transição. O BIG-IP Next bifurca essas funções completamente. O data plane (TMM) agora roda como um processo conteinerizado, enquanto o management plane é descarregado para um controller centralizado (BIG-IP Next Central Manager).

Nos tempos do Classic, uma CVE na GUI de gerenciamento significava derrubar todo o seu mecanismo de processamento de tráfego para aplicar o patch. No BIG-IP Next, o data plane é desacoplado. Você não está mais gerenciando 'caixas'; você está gerenciando instâncias de tráfego de alto desempenho que são gerenciadas pelo ciclo de vida via Central Manager. Se você ainda não percebeu, olhe para as datas de EOL para a série iSeries e a mudança para o hardware VELOS e rSeries — esses são os pontos de chegada finais para o Classic antes da virada definitiva para o Next.

Análise Arquitetônica Aprofundada: Kubernetes como a Base

Por baixo do BIG-IP Next, a F5 finalmente abraçou o ecossistema Kubernetes. Isso não é apenas 'F5 em um container'. Toda a orquestração do ciclo de vida da instância é tratada via primitivos K8s. Quando você implanta uma instância Next em uma partição VELOS ou como um VE no ESXi, você está interagindo com um sistema que usa uma abordagem API-first, tratando o load balancer como um recurso efêmero.

A Mudança para a Gestão Desacoplada

O Classic BIG-IP usava os processos system-auth e mcpd para lidar com o estado da configuração. Este era o gargalo de todas as implantações em grande escala. O BIG-IP Next move a 'fonte da verdade' para o Central Manager. Suas instâncias são essencialmente proxies stateless. Isso permite um scaling horizontal que antes era impossível. Em 2026, estamos vendo implantações empresariais onde um único Central Manager controla mais de 500 instâncias Next em múltiplas clouds e clusters on-prem, um feito que teria exigido dezenas de clusters BIG-IQ no mundo antigo.

Configuração: A Morte do 'bigip.conf' e a Ascensão do AS3

Se você ainda está clicando na GUI para criar Virtual Servers, você está falhando com sua organização. O BIG-IP Next efetivamente exige o AS3 (Application Services 3 Extension) ou seus derivados evoluídos. Não há mais um /config/bigip.conf para pesquisar. A configuração é armazenada como JSON e enviada via 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"]
                }]
            }
        }
    }
}

Essa mudança permite um verdadeiro GitOps. Em 2026, o fluxo de trabalho padrão é: Desenvolvedor envia um PR para um repositório GitHub -> pipeline CI/CD valida o JSON AS3 -> Central Manager envia as alterações para as instâncias BIG-IP Next. Isso elimina o drift de configuração manual, que era a principal causa de interrupções na era Classic.

Lacunas de Paridade: O Que Você Perde na Transição

Sejamos francos: o BIG-IP Next não tem 100% de paridade de recursos com o Classic, e provavelmente nunca terá. A F5 está usando essa transição para se livrar de débito técnico. Protocolos antigos e recursos de nicho que estavam obstruindo o kernel do TMOS foram removidos. Se você está contando com conjuntos de comandos iRules obscuros de 2012, ou perfis NTLM legados específicos, você está em sérios apuros.

• Migração de iRules: A F5 oferece o "BIG-IP Next Migration Assistant", mas não é uma varinha mágica. Aproximadamente 20% dos iRules complexos exigem reescrita manual. iRules no Next são mais performáticos, mas mais rigorosos na sintaxe.
• AFM/ASM: Os módulos de segurança foram renomeados como 'BIG-IP Next WAF' e 'BIG-IP Next Access'. Os engines de política são mais limpos, mas se você vem de uma política ASM v15/v16 fortemente customizada, a migração é um processo de auditoria de várias semanas.
• Persistência L7: Muitos métodos de persistência legados foram descontinuados em favor da persistência baseada em cookies ou inspeção universal via padrões Modern TLS.

O Roteiro de Migração para 2026

Uma migração ಅಸ್ಂ will fail. Recomendamos uma abordagem de três fases, que documentamos extensivamente em nosso guia de F5 para SDN moderno.

Fase 1: Implantação do Central Manager

Não implante uma única instância Next até que seu Central Manager (CM) esteja endurecido e suas integrações IPAM/DNS estejam sólidas. O CM é o cérebro; trate-o com mais reverência do que você tratou o BIG-IQ. Garanta que você tenha um cluster de 3 nós para o CM para alta disponibilidade.

Fase 2: Configuração Sombra e Conversão AS3

Pegue sua configuração Classic BIG-IP existente e execute-a através do Migration Assistant. Para cada Virtual Server, gere a declaração AS3 correspondente. Conduza testes 'somente leitura' onde você os implanta em uma instância Next de laboratório e verifica se o comportamento do data plane corresponde à saída legada do TMM.

Fase 3: A Virada do Tráfego

Use a migração baseada em DNS (GSLB/BIG-IP DNS) para transferir gradualmente o tráfego do Classic iSeries para as instâncias Next. Não tente uma troca abrupta no nível de MAC address. O stack de rede subjacente no Next lida com ARP e roteamento de forma diferente, especialmente em ambientes multi-tenant.

Performance de Hardware: VELOS e rSeries na Era Next

Executar o BIG-IP Next em hardware legado é uma receita para a frustração. Para aproveitar ao máximo a arquitetura baseada em K8s, você precisa do offloading assistido por FPGA fornecido pelo rSeries (ex: r5900 ou r10900) ou pelo chassi VELOS. A série rSeries oferece FPGAs dedicadas para offload SSL/TLS que o data plane do Next acessa diretamente via drivers QuickAssist Technology (QAT).

Nos meus testes, uma instância BIG-IP Next em um r10900 lida com 40% mais handshakes TLS concorrentes do que o software Classic v15 equivalente no mesmo hardware. Por quê? Porque o data plane do Next é otimizado para scaling multi-core sem a sobrecarga dos enormes processos de gerenciamento que afetavam o Classic TMOS.

Custos e Licenciamento no Mundo Real

A F5 migrou totalmente para um modelo baseado em assinatura. Se você ainda está com licenças perpétuas, 2026 é o ano em que seus custos de manutenção dispararão, já que a F5 incentiva a mudança para o F5 FlexPool ou assinaturas BIG-IP Next. Espere pagar aproximadamente US$ 15 mil a US$ 25 mil por ano por uma instância Next de alto desempenho (equivalente a um nível de throughput de 10Gbps), dependendo de seus requisitos de WAF/Advanced Firewall.

Veredito: Você Deve Migrar Agora?

Se você está montando uma nova infraestrutura, não implante o Classic. Você estará apenas construindo um sistema legado que terá que migrar em 24 meses. Se você está executando workloads estáveis em hardware iSeries, você tem até o final de 2026 para finalizar sua estratégia. Os ganhos de performance em TLS 1.3 e a eficiência operacional de AS3/GitOps fazem com que a transição valha a pena a dor inicial da conversão de configuração. No entanto, se sua equipe não está pronta para gerenciamento API-first, permaneça no Classic até que você tenha contratado ou treinado para a realidade centrada em devops do Next.

Pronto para modernizar seu stack ADC ou precisa de uma auditoria especializada do seu ambiente F5 atual? Confira nossos serviços de engenharia e revisões de arquitetura em techleague.io.