La fracture entre configurabilité et opérabilité
Nous avons publié plusieurs articles sur la distinction entre la livraison (développement d'applications) et le déploiement (production), suite à notre récente acquisition de NGINX . L'un d'entre eux a brièvement évoqué un concept que nous allons explorer aujourd'hui : la simplicité opérationnelle .
Derrière l’expression « simplicité opérationnelle » se cache un clivage entre configurabilité et opérabilité. Les deux sont en contraste frappant. D’un côté, il y a la configurabilité. Il s’agit de la capacité à manipuler les caractéristiques des services d’application au niveau des couches réseau, plateforme et service d’application. C'est ce qui vous donne la possibilité d'activer et de désactiver l'algorithme de Nagle et de modifier les paramètres qui ont un impact sur les performances et l'efficacité des protocoles.
D’autre part, il y a l’opérabilité. C'est la capacité de déployer, de gérer et de surveiller rapidement les services d'application. L’attente en matière d’opérabilité est la connaissance du service d’application, et rien de plus. Il n’est pas nécessaire que les opérateurs soient des experts des couches de plateforme ou de réseau. Pour y parvenir, les boutons et les molettes qui existent au niveau de la couche de service d’application peuvent être restreints. L’objectif principal est de rendre le service d’application facile à déployer et à exploiter.
L’une d’entre elles introduit de la complexité. On le réduit. Il faut une connaissance approfondie et étendue de l’ensemble de la pile. L'autre non. Chacun joue un rôle dans la livraison sécurisée des applications.
Répartition des tâches
La raison pour laquelle cette division est importante est que le cloud et les conteneurs exercent une pression sur l’infrastructure des services d’application pour évoluer vers un modèle plus simple. Un certain nombre de services d’application sont consommés par des conteneurs. L'équilibrage de charge, le contrôle des entrées, la surveillance, les passerelles API et la sécurité des API sont considérés comme des composants nécessaires à une stratégie de conteneurisation réussie. Essentiellement, la transformation des architectures consiste à diviser les services applicatifs eux-mêmes. Certains sont mieux adaptés au déploiement dans le chemin de données et d’autres dans le cadre de l’architecture de l’application.
Cela signifie que ce sont de plus en plus les opérations, en particulier DevOps, qui consomment des services applicatifs sur site et dans le cloud public. Cela a un impact profond sur ces services d’application, car les attentes de DevOps incluent l’opérabilité plutôt que la configurabilité. Les DevOps ne s’intéressent pas particulièrement au réglage des piles TCP ; ils s’intéressent aux déploiements rapides et fréquents et au maintien de la disponibilité des applications.
Cela est en grande partie dû à l’accent mis sur le délai de rentabilisation qui exige une plus grande vitesse de livraison et de déploiement. Personne n’a le temps de s’occuper des infrastructures, ils ont des applications à commercialiser.
Mais cela ne signifie pas que la configurabilité n’est pas importante. C’est le cas, surtout en matière de sécurité et de performances. Une pile de réseau et de plateforme standardisée n’est optimisée pour rien. Il n'est pas capable de s'ajuster pour optimiser le mobile en même temps qu'il s'optimise pour le bureau. Il n'est pas optimisé pour votre réseau, qu'il soit dans le cloud ou sur site.
Et que nous aimions l’admettre ou non, la performance est une mesure composée. Si votre réseau est lent, votre application est encore plus lente. La nécessité d’optimiser les couches réseau et plateforme est un élément essentiel pour garantir non seulement la disponibilité mais aussi les performances . La configurabilité doit donc être accessible à ceux qui peuvent en profiter.
Pas un choix binaire
La configurabilité reste aussi importante que l’opérabilité. Ce n’est pas vraiment un choix binaire car la consommation de services d’application n’est pas binaire. Aujourd’hui, NetOps et DevOps consomment tous deux des services applicatifs ; la différence réside dans leurs attentes en matière de déploiement et de gestion de ces services applicatifs. NetOps a besoin de configurabilité. DevOps nécessite une opérabilité.
L'entreprise a besoin des deux, car la rapidité de livraison sur le marché ne sera d'aucune aide si votre application n'est pas également rapide et fiable.
Cette fracture existe parce que la technologie est dans un état de transition entre un monde où la configurabilité était la règle et un état futur où l’opérabilité est attendue. Aujourd’hui, il faut trouver un moyen de combler le fossé entre les deux, avec des services applicatifs qui répondent aux attentes opérationnelles de leurs opérateurs. C’est pourquoi la combinaison de F5 et NGINX est si passionnante aujourd’hui.
Mais je vois un avenir où vous pourrez avoir à la fois configurabilité et opérabilité. C’est pourquoi la combinaison de F5 et NGINX est si prometteuse pour demain. Et si vous êtes particulièrement intéressé par la manière dont F5 et NGINX offriront une gestion moderne des API, inscrivez-vous au prochain webinaire .