F5 BIG-IP Next vs. Classique : Le guide de migration technique 2026

L'ère TMOS touche à sa fin, et si vous traitez toujours votre load balancer comme un appareil monolithique en 2026, vous êtes assis sur une bombe à retardement de dette technique. Le passage de BIG-IP Classique à BIG-IP Next n'est pas une simple mise à jour de version ; c'est une décapitation architecturale totale du control plane, passant d'un OS monolithique basé sur Linux à un moteur Kubernetes-native, basé sur des microservices, qui met enfin à mort le 'bigip.conf' tel que nous le connaissons.

La réalité post-TMOS : pourquoi le Classique est mort

Pendant vingt ans, les ingénieurs F5 ont vécu et sont morts par bigpipe puis tmsh. L'architecture BIG-IP Classique regroupait le control plane, le management plane et le data plane en une seule image étroitement couplée. Cela rendait la mise à l'échelle difficile et les mises à niveau périlleuses. En 2026, l'industrie a opéré une transition. BIG-IP Next bifurque entièrement ces fonctions. Le data plane (TMM) fonctionne désormais comme un processus conteneurisé, tandis que le management plane est déchargé vers un contrôleur centralisé (BIG-IP Next Central Manager).

À l'époque Classique, une CVE dans l'interface graphique de gestion signifiait l'arrêt de l'ensemble de votre moteur de traitement du trafic pour patcher. Dans BIG-IP Next, le data plane est découplé. Vous ne gérez plus des 'boîtes' ; vous gérez des instances de trafic haute performance dont le cycle de vie est géré via le Central Manager. Si vous n'avez pas vu les signes avant-coureurs, examinez les dates EOL pour l'iSeries et le passage vers les matériels VELOS et rSeries – ce sont les points d'atterrissage finaux pour le Classique avant le pivotage définitif vers Next.

Plongée architecturale : Kubernetes comme sous-couche

Sous le capot de BIG-IP Next, F5 a finalement adopté l'écosystème Kubernetes. Il ne s'agit pas seulement de 'F5 dans un conteneur'. Toute l'orchestration du cycle de vie de l'instance est gérée via des primitives K8s. Lorsque vous déployez une instance Next sur une partition VELOS ou en tant que VE sur ESXi, vous interagissez avec un système qui utilise une approche API-first, traitant le load balancer comme une ressource éphémère.

Le passage à une gestion découplée

BIG-IP Classique utilisait les processus system-auth et mcpd pour gérer l'état de la configuration. C'était le goulot d'étranglement de chaque déploiement à grande échelle. BIG-IP Next déplace la 'source de vérité' vers le Central Manager. Vos instances sont essentiellement des proxys stateless. Cela permet une mise à l'échelle horizontale qui était auparavant impossible. En 2026, nous observons des déploiements en entreprise où un seul Central Manager contrôle plus de 500 instances Next à travers plusieurs clouds et clusters on-prem, un exploit qui aurait nécessité des dizaines de clusters BIG-IQ dans l'ancien monde.

Configuration : la mort de 'bigip.conf' et l'avènement d'AS3

Si vous continuez à cliquer dans l'interface graphique pour créer des Virtual Servers, vous échouez à votre organisation. BIG-IP Next impose de fait l'Application Services 3 Extension (AS3) ou ses dérivés évolués. Il n'y a plus de /config/bigip.conf à rechercher. La configuration est stockée au format JSON et poussée via API REST.

{
    "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"]
                }]
            }
        }
    }
}

Ce changement permet une vraie approche GitOps. En 2026, le workflow standard est le suivant : le développeur soumet une PR à un dépôt GitHub -> le pipeline CI/CD valide le JSON AS3 -> le Central Manager pousse les changements vers les instances BIG-IP Next. Cela élimine la dérive de configuration manuelle, qui était la principale cause de pannes à l'ère Classique.

Lacunes de parité : ce que vous perdez dans la transition

Soyons clairs : BIG-IP Next n'est pas à 100 % de parité fonctionnelle avec le Classique, et il ne le sera probablement jamais. F5 utilise cette transition pour se débarrasser de la dette technique. Les protocoles anciens et les fonctionnalités de niche qui engorgeaient le kernel TMOS ont été supprimés. Si vous comptez sur des ensembles de commandes iRules obscures datant de 2012, ou sur des profils NTLM hérités spécifiques, vous allez rencontrer de sérieuses difficultés.

• Migration des iRules : F5 propose le « BIG-IP Next Migration Assistant », mais ce n'est pas une baguette magique. Environ 20 % des iRules complexes nécessitent une réécriture manuelle. Les iRules sur Next sont plus performants mais plus stricts sur la syntaxe.
• AFM/ASM : Les modules de sécurité ont été renommés 'BIG-IP Next WAF' et 'BIG-IP Next Access'. Les moteurs de politique sont plus clairs, mais si vous venez d'une politique ASM v15/v16 fortement personnalisée, la migration est un processus d'audit de plusieurs semaines.
• Persistance L7 : De nombreuses méthodes de persistance héritées ont été dépréciées au profit de la persistance basée sur les cookies ou de l'inspection universelle via les standards TLS modernes.

La feuille de route de migration pour 2026

Une migration désordonnée échouera. Nous recommandons une approche en trois phases, que nous avons largement documentée dans notre guide de migration F5 vers SDN moderne.

Phase 1 : Déploiement du Central Manager

Ne déployez pas une seule instance Next tant que votre Central Manager (CM) n'est pas durci et que vos intégrations IPAM/DNS ne sont pas solides. Le CM est le cerveau ; traitez-le avec plus de respect que vous ne traitiez le BIG-IQ. Assurez-vous d'avoir un cluster de 3 nœuds pour le CM afin de garantir une haute disponibilité.

Phase 2 : Shadow Configuration et Conversion AS3

Prenez votre configuration BIG-IP Classique existante et exécutez-la via le Migration Assistant. Pour chaque Virtual Server, générez la déclaration AS3 correspondante. Effectuez des tests en 'lecture seule' où vous les déployez sur une instance Next de laboratoire et vérifiez que le comportement du data plane correspond à la sortie TMM héritée.

Phase 3 : Le basculement du trafic

Utilisez la migration basée sur DNS (GSLB/BIG-IP DNS) pour basculer progressivement le trafic des iSeries Classiques vers les instances Next. N'essayez pas un basculement complet au niveau de l'adresse MAC. Le réseau sous-jacent dans Next gère l'ARP et le routage différemment, en particulier dans les environnements multi-tenant.

Performances matérielles : VELOS et rSeries à l'ère Next

Exécuter BIG-IP Next sur du matériel hérité est une recette pour la frustration. Pour tirer le meilleur parti de l'architecture basée sur K8s, vous avez besoin du déchargement assisté par FPGA fourni par les rSeries (par exemple, r5900 ou r10900) ou le châssis VELOS. Les rSeries offrent des FPGA dédiés pour le déchargement SSL/TLS que le data plane Next utilise directement via les drivers QuickAssist Technology (QAT).

Dans mes tests, une instance BIG-IP Next sur un r10900 gère 40 % plus de handshakes TLS concurrents que le logiciel Classique v15 équivalent sur le même matériel. Pourquoi ? Parce que le data plane Next est optimisé pour la mise à l'échelle multi-cœur sans la surcharge des processus de gestion massifs qui affligeaient le TMOS Classique.

Coûts réels et licences

F5 est entièrement passé à un modèle basé sur l'abonnement. Si vous êtes toujours sur des licences perpétuelles, 2026 est l'année où vos coûts de maintenance monteront en flèche, car F5 incite au passage aux abonnements F5 FlexPool ou BIG-IP Next. Prévoyez de payer environ 15 000 $ à 25 000 $ par an pour une instance Next haute performance (équivalent à un niveau de débit de 10 Gbit/s), selon vos besoins en WAF/Firewall avancé.

Verdict : Faut-il migrer maintenant ?

Si vous mettez en place une nouvelle infrastructure, ne déployez pas le Classique. Vous ne faites que construire un système hérité que vous devrez migrer dans 24 mois. Si vous exécutez des charges de travail stables sur du matériel iSeries, vous avez jusqu'à la fin de 2026 pour finaliser votre stratégie. Les gains de performance en TLS 1.3 et l'efficacité opérationnelle d'AS3/GitOps justifient la douleur initiale de la conversion de configuration. Cependant, si votre équipe n'est pas prête pour la gestion API-first, restez sur le Classique jusqu'à ce que vous ayez embauché ou formé pour la réalité centrée sur les devops de Next.

Prêt à moderniser votre pile ADC ou besoin d'un audit expert de votre environnement F5 actuel ? Découvrez nos services d'ingénierie et nos revues d'architecture sur techleague.io.