Pour gagner en visibilité sur vos applications, il faut éliminer les silos opérationnels

J'en suis maintenant à ma cinquième semaine de travail à domicile pour #arrêterlapropagation du COVID-19. Chaque jour révèle une nouvelle tragédie et apporte un nouveau chagrin à mesure que la crise humanitaire se déroule. Chaque jour, je suis également inspiré par le dévouement, le professionnalisme et l’altruisme de ceux qui combattent le virus en première ligne dans les hôpitaux, les cliniques et les établissements de soins, ainsi que de ceux qui travaillent pour maintenir la disponibilité des services essentiels. Mes sincères remerciements vont à ces héros.

Cette crise a également fait émerger des héros au sein des services informatiques des organisations du monde entier. Notre dépendance aux services numériques a considérablement augmenté au cours du mois dernier, tout comme l’engagement, l’ingéniosité et le travail acharné des individus des équipes chargées des opérations réseau, de DevOps, de la sécurité et du développement pour faire évoluer ces services de manière efficace et sécurisée. Ils travaillent de longues heures dans des conditions loin d’être idéales pour assurer le bon fonctionnement de tout, depuis le maintien de la connexion des travailleurs à distance, jusqu’aux applications de livraison apportant des articles essentiels à notre porte, en passant par les solutions de télémédecine activant de grandes armées de professionnels de la santé qualifiés.

Certains analystes du marché ont estimé que ces travaux pourraient faire progresser les stratégies numériques des entreprises jusqu’à une décennie. Ils devront cependant relever un certain nombre de défis pour y parvenir. Dans mon dernier blog , j’ai évoqué le plus important de ces défis : le manque de visibilité sur leurs applications.

L’une des raisons pour lesquelles la visibilité au niveau des applications reste si difficile à atteindre est que les chemins de données des applications sont complexes et n’ont généralement pas été construits pour une visibilité de bout en bout. Un chemin de données d'application est le chemin par lequel circule le trafic d'une application, depuis le serveur sur lequel la logique métier de l'application est hébergée, jusqu'à l'utilisateur final qui tente d'accéder à l'application. La plupart des applications disposent de plusieurs technologies ou services tout au long du chemin de données. Selon la façon dont vous les comptez, il existe au moins sept à neuf de ces différents services le long du chemin de données d'une application moderne, couvrant tout, de l'environnement d'exécution au réseau de distribution périphérique.

Chacun de ces services le long du chemin de données de l’application peut être fourni par plusieurs fournisseurs. Et pour chaque architecture d'application différente (par exemple, monolithique, client-serveur, à 3 niveaux, microservices, mobile) et chaque environnement d'infrastructure (par exemple, sur site, Amazon Web Services, Microsoft Azure, RedHat OpenShift, Pivotal Cloud Foundry, etc.), il existe davantage de fournisseurs. Les fournisseurs et outils que nos clients sélectionnent pour leurs applications monolithiques et à trois niveaux ne sont généralement pas ceux qui servent leurs applications de microservices. Et ils disposent souvent d’une chaîne d’outils entièrement différente pour leurs différents chemins de données d’application de cloud public.

Cela représente beaucoup de fournisseurs et beaucoup d’outils.

La plupart de nos clients se sont également structurés en interne autour de tous ces fournisseurs et outils. Historiquement, cela avait du sens car chaque rôle et chaque outil nécessitent souvent sa propre base de connaissances, ses propres compétences et ses propres processus de gestion. L’équipe qui gère les applications Azure est souvent distincte de celle qui gère les applications AWS, qui est distincte de l’équipe responsable des applications sur site héritées. Il en va de même pour les différentes disciplines et rôles impliqués. Les développeurs d'applications, les équipes SecOps, les équipes NetOps, etc., utilisent chacun les ensembles d'outils les plus adaptés à leurs tâches spécifiques pour fournir et sécuriser chaque application.

Chacun de ces outils et fournisseurs tout au long du chemin de données de l’application est généralement doté de son propre cadre de gestion centrale et d’automatisation. Cela laisse au client le soin d'assembler le tout. Pour ajouter une dimension à cela, l'étude F5 révèle que les entreprises ont en moyenne environ 800 applications dans leur portefeuille, réparties sur environ 4 architectures d'application et environ 3 environnements d'infrastructure (c'est-à-dire sur site et 2+ clouds publics). De plus, chacune de ces applications dispose de sept à neuf services le long du chemin de données. Il n’est pas facile d’automatiser et d’orchestrer un chemin de données d’application unique, sans parler de résoudre le problème du portefeuille hétérogène d’une entreprise typique.

Ce qui résulte en fin de compte de tout cela – dans lequel nous nous sommes tous retrouvés – ce sont des silos. Il existe plusieurs silos opérationnels le long du chemin de données pour une seule application, et encore plus de silos opérationnels pour chacune des architectures d'application et des environnements d'infrastructure utilisés dans toute architecture multicloud.

Et là où il y a des silos, la visibilité est limitée. Lorsqu'un problème survient sur le chemin des données de l'application, il faut parfois des semaines ou des mois pour comprendre exactement ce qui s'est passé. Peu importe le réglage pour des performances optimales de bout en bout lorsque tout va bien.

Et c’est dans cette situation que se trouvent la plupart de nos clients aujourd’hui. D’une part, ils disposent de portefeuilles d’applications tentaculaires comprenant des applications traditionnelles, essentielles au fonctionnement actuel de l’entreprise, et des applications modernes, essentielles à la création de valeur future de l’entreprise. D’autre part, ils ont un modèle opérationnel immature pour ce portefeuille d’applications, renforcé par des silos organisationnels et des outils fragmentés, perpétuant ainsi l’existence d’angles morts et de risques considérables.

Pour aider nos clients à réaliser et sécuriser la pleine valeur de leurs applications, F5 prône un nouveau paradigme pour la livraison et la sécurité des applications, fondamentalement orienté autour de l'application. Contrairement au paradigme traditionnel qui optimise autour d'un sous-ensemble des capacités du chemin de données de l'application et s'étend jusqu'à la couche d'infrastructure (nous appelons cela « l'approche verticalement intégrée »), cette nouvelle approche se concentre sur la rationalisation du chemin de données de l'application de bout en bout et sur l'abstraction de cette couche de l'infrastructure sous-jacente. Cette approche présente plusieurs avantages :

1. Obtenez la portabilité des applications et évitez le verrouillage de l'infrastructure
   
   
2. Bénéficiez d'une visibilité de bout en bout pour améliorer la disponibilité et la sécurité des applications
   
   
3. Orchestrez et automatisez la distribution d'applications pour des expériences exceptionnelles de manière cohérente sur l'ensemble du portefeuille d'applications, quelle que soit l'architecture ou l'infrastructure de l'application

Il existe plusieurs raisons pour lesquelles F5 est idéalement placé pour tenir cette promesse envers nos clients. Tout d’abord, entre F5 BIG-IP, NGINX, F5 Cloud Services, Silverline et désormais Shape, F5 dispose de l’ensemble de fonctionnalités le plus complet tout au long du chemin de données d’application (serveurs Web, contrôleurs d’entrée, équilibreurs de charge et sécurité des applications) de tous les fournisseurs de solutions au monde. Et nous proposons ces capacités dans une variété de modèles de consommation et de déploiement.

Nous disposons également du seul ensemble d’éléments de chemin de données véritablement multicloud (c’est-à-dire indépendant de la plate-forme). Cela signifie que vous pouvez exécuter des éléments de chemin de données F5 (nous les appelons « services d’application ») n’importe où. Vous pouvez les exécuter dans des environnements de conteneurs. En fait, NGINX est spécifiquement optimisé pour les environnements natifs de conteneurs. Nos services applicatifs fonctionnent dans le cloud public. Ils fonctionnent également sur des machines virtuelles, sur du matériel commercial disponible dans le commerce et sur notre propre matériel spécialement conçu.

Et entre nos intégrations d’écosystèmes existantes et les API déclaratives de classe mondiale qui permettent à nos clients et partenaires d’intégrer et d’orchestrer les technologies F5 avec des technologies tierces, nous offrons également l’architecture la plus ouverte de tous les fournisseurs de solutions. Cela donne le choix à nos clients. Ils peuvent choisir les meilleures technologies qu’ils souhaitent utiliser tout au long du chemin des données de l’application et ailleurs.

Et maintenant, avec NGINX Controller et F5 Beacon , nous proposons des solutions packagées pour aider à assembler le tout d'une manière qui permet non seulement aux technologies d'interopérer, mais qui permet également à tous ces groupes humains de collaborer.

Notre vision à long terme est de développer ces services puissants et de fournir davantage d’informations via la télémétrie et l’analyse. Et à partir de là, nous nous concentrerons sur la transformation de ces informations en valeur commerciale tangible pour nos clients dans tous les secteurs, ce que nous appelons l'entreprise assistée par l'IA .

Nous constatons déjà que nos clients obtiennent des résultats impressionnants à mesure que nous commençons à concrétiser cette vision, et nous partagerons davantage sur ces résultats et sur les prochaines étapes que nous entreprendrons dans les semaines et les mois à venir.