Points faibles de la production et services applicatifs qui les soulagent

• Les développeurs interrogés par RisingStack citent des difficultés de performance, de sécurité et de déploiement dans les environnements de production
• La sécurité et les performances ne sont pas toutes le résultat d’un « mauvais code ». Les plateformes et les implémentations de protocoles sont le plus souvent à l’origine du problème.
• Les services d'application peuvent résoudre à la fois les problèmes de sécurité et de performances
• L'automatisation et les services en libre-service peuvent atténuer les problèmes de déploiement

Pendant des années, on nous a dit : « Il existe une application pour ça ». Et jusqu’à présent, j’ai constaté que c’était en grande partie vrai. J’ai des applications pour des choses pour lesquelles je n’aurais jamais pensé avoir besoin d’une application. Mais quand je l'ai fait et que j'ai commencé à chercher, c'était là, comme par magie.

Aujourd’hui, personne ne dit « il existe un service d’application pour cela », mais peut-être devraient-ils le dire. Au moins dans les limites de l’informatique. Car tout comme il existe souvent une application pour ce que j’ai besoin de faire, il existe souvent un service d’application pour ce qu’un développeur doit faire – ou traiter – dans les environnements de production.

Prenons l’exemple de la sécurité. Il s'agissait du principal problème de production selon les développeurs dans une enquête RisingStack.

POINT DOULOUREUX : SÉCURITÉ

L’enquête n’entre pas dans les détails concernant les points sensibles en matière de sécurité (même si je suis sûr que si on nous le demandait, nous obtiendrions une grande variété de réponses). Ce que je sais, c'est que 38 % des personnes interrogées dans un rôle d'application (développeurs) dans notre enquête sur l'état de la distribution d'applications de 2018 ont indiqué que « la sophistication croissante des attaques » était leur principal défi de sécurité pour l'année prochaine. 26 % ont fait état d'un manque de compétences informatiques en matière de sécurité et 23 % ont fait état de difficultés à sécuriser les applications, en particulier les applications Web, contre les attaques.

Si nous considérons le problème sous cet angle (et comme c'est mon blog, je vais le faire), il existe un service d'application pour cela. Plusieurs, en fait. Même si l’objectif est de corriger virtuellement ou d’empêcher qu’une vulnérabilité existante soit exploitée.

Et il y en a beaucoup comme ça. Le problème est que chaque violation, chaque accès non autorisé, chaque élément de données qui fuit a tendance à être imputé à un développeur – même lorsque la vulnérabilité se trouvait dans une bibliothèque tierce ou cachée au plus profond des paquets d’un protocole ou dans une plateforme utilisée par des millions (littéralement) d’autres sites sur Internet. Mais Lori, vous pensez que les 79 % d’une application constituée de bibliothèques ne représentent que 2 % des vulnérabilités connues après une inspection minutieuse.

Et pourtant, certaines des violations et pertes de données les plus médiatisées sont dues à ces 2 % – des vulnérabilités dans les plateformes et les bibliothèques communes partagées par des millions de personnes.

Un pare-feu d’application Web (l’un des trente services d’application que nous suivons dans notre enquête annuelle) répond à ces deux besoins – ainsi qu’au portefeuille croissant que les attaquants utilisent pour accéder, drainer des ressources ou voler des données. Le contrôle d'accès aux applications fournit également une couche de protection pour les informations d'identification (elles-mêmes précieuses) ainsi que pour l'application et ses données. Il convient de noter que 75 % de tous les répondants à notre enquête annuelle ont indiqué qu'ils utilisent le contrôle d'accès aux applications pour protéger les applications sur site et dans le cloud public.

POINT DOULOUREUX : PERFORMANCE

De même, les performances ne sont pas quelque chose qu’un développeur peut toujours contrôler. Les normes de code, qui privilégient la durabilité à long terme, ont un impact sur les performances des applications. Parfois, vous ne pouvez pas utiliser la structure de données ou la syntaxe la plus efficace. Vous devez garder à l’esprit que quelqu’un d’autre doit maintenir et modifier ce code par la suite. Parfois, c’est l’impact de variables indépendantes de votre volonté : la capacité, la demande, les conditions du réseau et ce client qui refuse d’abandonner ce PC vieux de dix ans fonctionnant sous Windows ME.

Il existe également un service d’application (plusieurs, en fait) pour répondre à ce problème. Une véritable pléthore d'options allant de l'optimisation TCP à la mise en cache en passant par la compression et le déchargement de traitements cryptographiques coûteux. Tous ces services applicatifs peuvent améliorer les performances et ravir les utilisateurs.

Un bon nombre de personnes utilisent déjà ces services pour rendre leurs applications plus rapides et plus sûres, en s'attaquant à la fois aux problèmes de performances et de sécurité.

POINT DOULOUREUX : DÉPLOIEMENT

Mais les développeurs ont indiqué que ce ne sont pas seulement les problèmes de sécurité ou de performances qui leur posent problème en production, mais aussi le déploiement, qui se concentre sur la manière dont ces applications et services d'application s'exécutent en production.

Il s’agit d’un problème plus vaste qui ne peut pas être résolu par un seul service d’application, ni même par une chaîne de services d’application. Pour résoudre le problème du déploiement, il faut une initiative plus stratégique autour de l’automatisation et de l’orchestration et adopter des idées DevOps telles que l’infrastructure en tant que code.

Il faut un effort concerté pour faire évoluer les NetOps traditionnels afin d’adopter les principes et les méthodologies de DevOps pour codifier les processus nécessaires au déploiement des changements nécessaires en production pour soutenir les développeurs.

Cela signifie que les fournisseurs d’infrastructure doivent fournir une infrastructure compatible API et prendre en charge la capacité de fonctionner dans un modèle plus déclaratif qui s’appuie sur des modèles et des artefacts de déploiement plutôt que sur des CLI.

Parmi les trois problèmes relevés par les développeurs, le déploiement est le plus difficile à résoudre, car il n’existe pas d’outil ou de technologie unique capable de le résoudre. Il faut une collaboration et un effort concerté pour transformer l’informatique d’un modèle de déploiement manuel vers l’approche de chaîne de montage automatisée du futur.

Indépendamment de la facilité ou de la difficulté à résoudre les problèmes des développeurs, le fait est que les trois peuvent être résolus par NetOps en production. Que ce soit avec une aide généreuse en services applicatifs ou un effort plus dédié à la transformation numérique interne, NetOps peut faire du passage à la production une expérience moins douloureuse – et plus réussie – pour tout le monde.