Révolution dans le cloud : AppFactor propulse les applications d’entreprise vers l’avenir grâce à l’automatisation !

La dette technique et le défi de la modernisation

La dette technique est souvent le méchant méconnu de l’entreprise, paralysant les entreprises qui cherchent à se moderniser lorsqu’elles réalisent à quel point leur pile technologique est « héritée ». Et comme pour la plupart des dettes, il y a généralement des intérêts à payer.

C’est quelque chose que la start-up britannique naissante AppFactor cherche à résoudre, avec une plateforme qui aide les entreprises à ré-architecturer automatiquement leurs applications héritées, les préparant ainsi pour un déploiement dans un nouvel environnement natif du cloud.

AppFactor a été officiellement constituée en 2021, mais le PDG et fondateur Keith Neilson ne travaille dessus à temps plein que depuis janvier, ayant récemment clôturé une levée de fonds préliminaire d’un montant supérieur à 1 million de livres sterling (1,3 million de dollars), selon lui.

En présentant aujourd’hui sur scène lors du Startup Battlefield de Toukiela Disrupt, Neilson a présenté la technologie d’AppFactor et exposé la mission de sa start-up dans un domaine propice au changement. Toukiela a rencontré Neilson en avance pour avoir un aperçu de l’ampleur du problème selon lui et de ce qu’AppFactor fait exactement pour y remédier.

La visibilité de la dette technique

Pour les personnes extérieures, certaines dettes techniques peuvent être évidentes grâce à l’exposition à des bugs ou à des systèmes lents. Ou peut-être grâce au temps qu’il faut à l’entreprise pour améliorer ses produits existants et introduire de nouvelles fonctionnalités.

En revanche, ceux qui sont à l’intérieur de l’entreprise ont une meilleure idée de leur dette technique lorsqu’ils constatent que leur budget informatique est disproportionnellement consacré à la maintenance plutôt qu’à la création de nouvelles choses. Les données du cabinet de conseil McKinsey suggèrent que la dette technique pourrait représenter jusqu’à 40 % du budget informatique total des entreprises, tandis qu’un rapport distinct de Stripe indique que les développeurs passent en moyenne un tiers de leur semaine de travail à résoudre des problèmes technologiques existants plutôt qu’à écrire du nouveau code.

Cependant, il n’est pas toujours facile d’avoir une image claire du niveau de dette technique d’une entreprise, car celle-ci peut être présente dans plusieurs domaines et domaines au sein d’une organisation. Cette face cachée peut inclure des choses comme un code excessivement complexe, des doublons ou simplement mauvais ; un manque de tests automatisés ; des vulnérabilités de sécurité ; et une mauvaise conception générale.

« Le grand défi des entreprises est qu’elles ont construit et conçu des applications de niveau entreprise à un moment donné, et les besoins et les processus métier modifient les environnements autour de ces applications, et les applications et leurs dépendances évoluent avec le temps », a déclaré Neilson.

Ainsi, selon McKinsey, la dette technique peut être considérée comme une sorte de « taxe » que les entreprises paient sur tous les développements internes axés sur la résolution de problèmes liés à des infrastructures technologiques héritées. Cela inclut l’intégration de nouvelles bibliothèques et frameworks, ou les points d’intégration et les changements de dépendances à mesure que les entreprises peaufinent leur pile technologique. Au final, cela crée un amas de complexité qui s’accumule au fil du temps pour créer un désordre difficile à gérer.

Un exemple typique d’une application héritée d’une entreprise pourrait impliquer une ancienne base de données Microsoft SQL, une couche intermédiaire et une interface utilisateur .NET, nécessitant un mélange d’infrastructures physiques et virtuelles pour fonctionner. Les processus en cours d’exécution, les bibliothèques, les dépendances et les composants généraux qui imprègnent l’application et l’infrastructure nécessiteraient un travail manuel important juste pour comprendre ce qui est quoi, lorsqu’ils tentent une transformation vers une forme plus adaptée au cloud.

Et c’est précisément ce qu’AppFactor propose. La plateforme scanne l’environnement informatique de l’entreprise pour identifier toutes ses applications et leurs dépendances respectives, « sépare » les applications virtuelles et hébergées physiquement de leur environnement actuel, et reconstruit chaque composant et couche d’application dans des conteneurs séparés prêts pour leur nouvel environnement – qu’il s’agisse d’une architecture cloud moderne comme Kubernetes ou d’un service de base de données géré.

« Tout cela est généré et piloté par le produit [AppFactor], vous pouvez donc déplacer rapidement vos applications existantes vers les dernières technologies cloud en quelques jours, pas en mois et années », explique Neilson.

La technologie d’AppFactor

AppFactor se compose de trois composants principaux, dont un scanner/analyseur qui est déployé sur les serveurs pour collecter les données nécessaires pour découvrir les applications et leurs dépendances ; un « orchestrateur » qui contrôle essentiellement le comportement du scanner/analyseur, y compris la plage IP et les systèmes cibles ; et la plateforme SaaS globale d’AppFactor qui gère toutes les analyses de données, les processus d’apprentissage automatique (ML) et les services qui génèrent des cartographies visuelles, des tâches de conteneurisation, etc.

L’entreprise affirme travailler avec certains clients commerciaux, dont l’entreprise britannique de logiciels d’entreprise Civica. À ce jour, seule la facette « découverte et évaluation » de sa plateforme est commercialement disponible. Cependant, l’entreprise se prépare également à lancer son module de « modernisation des applications » en novembre. Cela signifie que les clients auront non seulement la possibilité de trouver des candidats appropriés pour la modernisation, en fournissant tous les rapports et analyses pertinents, mais également d’effectuer eux-mêmes la transformation.

L’une des fonctionnalités les plus intéressantes de la plateforme – du moins d’un point de vue esthétique – est un outil qui permet aux utilisateurs de visualiser les dépendances des applications grâce à un moteur de visualisation 3D. À terme, cela pourrait être utilisé pour visualiser des environnements entiers.

« Actuellement, cela offre une vue plus globale de l’infrastructure et des processus, mais il est évident qu’il est possible d’aller plus en profondeur, ce que nous prévoyons de faire », explique Neilson.

Fait curieux, AppFactor rend également cette fonctionnalité disponible pour les casques de réalité virtuelle (VR), la société ayant présenté cette fonctionnalité via un Oculus sur son stand TC Disrupt.

« L’une des activités les plus difficiles dès le départ pour aider à minimiser les changements [d’application] consiste à pouvoir prendre en compte, visualiser et comprendre les dépendances, que ce soit au niveau de l’infrastructure, de l’architecture ou du code », explique Neilson. « Cette visualisation permet de voir et d’interagir avec la structure et l’anatomie de nos ensembles d’applications de manière granulaire et puissante. Certains de ces systèmes sont incroyablement complexes, avec des communications, des bibliothèques, des fichiers, des services, des processus et bien plus encore se produisant dans de nombreux endroits, dans plusieurs environnements. C’est donc une manière extrêmement puissante de comprendre de manière intuitive, de valider et de confirmer les connaissances, ce qui permet toute évolution future de l’application et de ses attributs. »

L’état des lieux

Les outils de modernisation des applications actuels sont essentiellement manuels et donc consommateurs de ressources. Ils peuvent impliquer l’utilisation d’un outil en ligne de commande comme Docker, qui nécessite des tests continus importants, et même dans ce cas, il se peut qu’il ne couvre pas tous les types de dépendances en raison du caractère manuel de l’exécution de l’outil. Et des outils comme Migrate for Anthos de Google, qui résulte de son acquisition de Velostrata il y a cinq ans, et App2Container d’AWS, simplifient quelque peu la conversion des machines virtuelles (VM) en conteneurs. Cependant, ces outils sont encore très manuels et basés sur la ligne de commande, ne fournissent pas nécessairement une visibilité étendue des dépendances et ne prennent pas en charge les applications basées sur une infrastructure physique.

Il existe d’autres services similaires axés sur l’aide aux entreprises pour passer d’un logiciel monolithique à des microservices, comme Vfunction soutenu par des investisseurs.

L’objectif ultime de chacun de ces services est d’aider les entreprises à réduire leur dette technique et à « se mettre à jour », bien que chaque service adopte des approches légèrement différentes.

« Nous pensons qu’il existe quatre piliers de la dette technique – l’infrastructure, l’architecture, le code et les dépendances », explique Neilson. « Nous pensons également qu’il existe de nombreuses applications qui ne conviennent pas aux microservices, donc notre vision est de permettre aux attributs d’une application d’entreprise de dicter le modèle d’architecture optimal. »

Le facteur IA

Pour y parvenir, AppFactor affirme développer des classifications d’apprentissage automatique pour aider à générer les modèles nécessaires à la transformation d’applications complexes et multi-hébergées. Il s’agit essentiellement de créer des techniques de « dactylographie » pour identifier la composition des applications complexes ou personnalisées.

« Nous utilisons un modèle de données entraîné pour construire cela, et il utilise un certain nombre d’attributs et de points de données qui peuvent aider à identifier les modèles d’application », explique Neilson.

En outre, Neilson a déclaré qu’ils expérimentaient un certain nombre d’autres cas d’utilisation de l’IA, notamment des modèles linguistiques de grande envergure (LLMs) pour générer le YAML (un langage de sérialisation de données lisible par l’homme pour créer des fichiers de configuration) pour les déploiements Kubernetes.

« Nous avons d’autres cas d’utilisation futurs autour de la génération de code, mais nous n’en sommes pas encore là », ajoute Neilson.