Quand avez-vous déménagé pour la dernière fois dans une nouvelle maison ?
Quand vous l'avez fait, vous êtes-vous débarrassé de vos meubles ? Des décorations ? Des photos ? Des tapis ? Probablement pas. Vous avez peut-être profité de l’occasion pour remplacer vos vieux biens usés par des neufs, mais la majeure partie de votre ménage a déménagé avec vous.
Il s’avère que les portefeuilles d’applications d’entreprise sont comme les éléments qui composent votre foyer. Lorsque les organisations adoptent de nouvelles architectures et développent de nouvelles applications, elles ne jettent pas celles qui existent déjà. Même si le portefeuille est toujours réduit au fil du temps, il est généralement vrai que les applications mises en service il y a des années à l'aide d'architectures traditionnelles sont toujours en service, à condition qu'elles continuent d'offrir une valeur commerciale.
Pendant des années, cela a été affirmé comme un fait, même si peu de données permettaient d’étayer cette affirmation. Personne ne conteste la véracité de cette hypothèse, mais il est agréable de disposer enfin de données empiriques pour la soutenir.
Dans notre étude sur l’état des services d’applications , nous interrogeons sur les tendances et les technologies qui, selon nous, auront un impact sur l’avenir des services d’applications. Le nuage est un. L’automatisation et l’orchestration en sont une autre. Mais l’impact le plus important sur les services d’application vient peut-être naturellement des applications que ces fonctions intermédiaires fournissent et sécurisent.
Nous avons donc posé des questions sur les architectures d’application utilisées et sur la composition du portefeuille d’applications d’entreprise.
Les résultats ne surprendront probablement personne, même si l’adoption rapide des architectures modernes, en particulier des microservices, peut s’avérer plus que passablement intéressante.
Vous savez, d’après un article précédent, que l’architecture d’application la plus répandue dans les portefeuilles d’entreprise aujourd’hui est une architecture traditionnelle : l’application Web à trois niveaux (36 %). Mais juste derrière se trouve son prédécesseur : le client-serveur (34 %). Les mainframes et les monolithes représentent encore 11 % des portefeuilles d'applications, mais les architectures modernes (définies ici comme mobiles et microservices) les ont dépassés, avec respectivement 14 % et 15 % du portefeuille d'applications.
C'est intéressant, mais le décomposer en architectures « traditionnelles » et « modernes » est encore plus fascinant. Aux fins de cette analyse, nous définissons les architectures « traditionnelles » comme incluant les monolithes, les applications client-serveur et les applications Web à trois niveaux. Les architectures « modernes » sont mobiles et basées sur des microservices.
En utilisant ces catégories, nous constatons que la plupart (76 %) utilisent un mélange des deux.
Les 24 % restants penchent largement du côté des architectures traditionnelles, 21 % utilisant uniquement des architectures traditionnelles pour leur portefeuille d'applications. Le reste, nous pourrions le qualifier d'aventureux et nous fier uniquement aux architectures modernes. Bien que le nombre moyen d'architectures d'applications dans un portefeuille d'applications d'entreprise soit de trois, la longévité de certaines entreprises est attestée par les 18 % d'organisations qui exploitent des applications dans chaque architecture. Tous les cinq.
Ce qui est encore plus intéressant, c’est que 11 % des organisations n’utilisent qu’UNE seule architecture.
Les organisations maintiennent des portefeuilles d’applications hétérogènes. À mesure qu’ils adoptent des architectures modernes, ils continuent d’utiliser et d’intégrer des applications qui appartiennent à la catégorie d’architecture traditionnelle. Bien que nous nous attendions à voir la composition du portefeuille d’applications évoluer au fil du temps, à mesure que les applications atteignent la fin de leur vie et sont remplacées par des équivalents modernes, ce changement prend du temps. Dans certains cas, beaucoup de temps.
Je m’attendrais à voir un déclin du client-serveur avant un déclin significatif du Web à trois niveaux, avec une croissance consommée des applications basées sur les microservices. Mais je ne m’attends pas à une mort dramatique du mainframe et des monolithes dans un avenir proche, étant donné le couplage étroit entre les activités et les applications fournies via de telles architectures. La réalité est que la transformation numérique entraîne une intégration plus étroite entre l’entreprise et la technologie, et les monolithes « anciens » qui vivent sur des mainframes présentent souvent déjà une telle intégration étroite.
En effet, alors que globalement moins d’un tiers (31 %) des répondants nous ont déclaré que leurs applications étaient essentielles à l’entreprise, pour ceux dont les monolithes représentent plus de la moitié de leur portefeuille d’applications, ce chiffre grimpe à 38 %. De toute évidence, les monolithes et les mainframes continuent de générer de la valeur commerciale, malgré leur âge potentiel.
Alors pourquoi un fournisseur de services et de sécurité d'applications se soucie-t-il des architectures d'applications en dehors de l'évidence selon laquelle « les applications doivent être évolutives, sécurisées et rapides » ?
Les architectures d’application ont toujours eu – et continueront d’avoir – un impact profond sur la manière dont les services d’application sont fournis. Les architectures traditionnelles, par exemple, sont bien adaptées aux mécanismes de distribution traditionnels basés sur des proxys tels que le contrôleur de distribution d'applications (ADC). Mais les applications modernes, qui s’appuient fortement sur des API et des modèles d’exécution distribués, introduisent de nouveaux mécanismes de livraison qui conviennent souvent mieux aux opérateurs de ces applications. Les options natives des conteneurs ainsi que les modèles « en tant que service » sont souvent associés aux applications modernes. De plus, les plugins Web et de serveur d'applications (à la manière des modules NGINX ) sont des mécanismes de distribution de plus en plus attrayants pour les services d'applications.
La réalité est que les microservices détruisent le réseau . Ce faisant, le centre de gravité des architectures de distribution est déplacé vers l'application. Cela rapproche certains services d'application critiques (disponibilité et sécurité, en particulier) de l'application, voire, dans certains cas, de celle-ci.
Cela va changer la façon dont nous, en tant qu'industrie, déployons et exploitons les services d'application et F5, en tant que fournisseur, les fournit.