Les entreprises veulent de la rapidité. L’un des impacts de la transformation numérique – et de la pression associée pour réussir dans une économie d’applications – est le désir d’avancer rapidement. Près de la moitié (48 %) des organisations sont poussées par la transformation numérique à se déployer plus rapidement selon notre état des services application 2019 .
Mais tout n’est pas qu’une question de déploiement. Il s’agit également de développement et de réactivité face aux menaces et aux évolutions de la demande.
Les organisations souhaitent développer et livrer des applications plus rapidement. Ils souhaitent s’adapter plus rapidement aux changements imprévisibles des conditions commerciales. Ils veulent répondre plus rapidement aux attaques.
Alors comment vont-ils y parvenir ?
Un déploiement plus fréquent implique que vous développez d'abord plus rapidement. Cela signifie souvent l’adoption de méthodologies Agile axées sur la vitesse. Rapport mondial des développeurs 2019 de GitLab : DevSecOps a constaté que la majorité (54 %) choisit Scrum, tandis que 37 % optent pour Kanban.
Mais les méthodologies ne suffisent pas si les architectures application ne sont pas bien adaptées aux styles de développement. Les équipes plus petites et concentrées qui se précipitent vers des versions fréquentes ne sont pas vraiment adaptées au développement de nouvelles fonctionnalités ou de correctifs pour les applications traditionnelles et monolithiques. La componentisation via l’adoption de microservices et de formes d’architecture plus distribuées s’adapte plus naturellement aux principes architecturaux et opérationnels modernes. Il n’est pas surprenant qu’en moyenne, plus de 80 % d’une application moderne soit constituée de composants tiers, fortement orientés vers l’open source.
L’adoption des API n’est pas non plus une surprise pour ceux qui recherchent un développement plus rapide grâce à des architectures application à composants. Les API dissocient l'implémentation de l'interface et permettent aux équipes d'apporter des modifications au traitement sans affecter l'utilisation des API d'autres composants ou applications. Il s’agit d’un modèle courant, avec un impressionnant 64 % d’organisations créant aujourd’hui des API destinées à être utilisées dans des cas d’utilisation internes ou externes. Près de 50 % de ces organisations s'appuient sur les API pour commercialiser leurs idées plus rapidement, selon le rapport State of API Integration 2018 de Jitterbit.
Le pipeline de build doit également suivre le rythme si l'on veut atteindre fréquemment les objectifs de déploiement. Cela signifie des outils CI/CD qui déplacent de manière transparente le code de la validation au test puis à la publication. Les outils de CI et de build les plus populaires dans l'enquête de GitLab étaient, sans surprise, GitLab (61 %), suivi de Jenkins (36 %) et Travis CI (12 %). Notamment, nos propres recherches révèlent que Jenkins est également utilisé par 16 % des entreprises pour l'automatisation du réseau - un résultat prometteur si les organisations cherchent à étendre DevOps au-delà de la livraison jusqu'au déploiement.
Développer plus rapidement ne permet pas de commercialiser plus rapidement les idées. Cela nécessite un déploiement. Alors que les entreprises technologiques nées dans le cloud ont maîtrisé facilement la fracture entre livraison et déploiement, de nombreuses entreprises établies trouvent cette transition difficile. Les structures organisationnelles existantes ainsi que le besoin continu de prendre en charge des applications traditionnelles et monolithiques introduisent des conflits qui peuvent être difficiles à intégrer aux exigences opérationnelles modernes. Mais il ne fait aucun doute que les organisations doivent surmonter ces défis pour les applications nécessitant des déploiements plus rapides et plus fréquents.
Ne vous laissez pas tromper : les organisations établies adoptent l’automatisation et l’appliquent au pipeline de déploiement. Le problème est souvent que les structures informatiques traditionnelles introduisent des efforts d’automatisation et de libre-service incohérents. Nous constatons ce phénomène dans nos propres recherches, où les structures d’équipe fortement cloisonnées continuent d’avoir un impact sur les efforts d’automatisation dans l’ensemble de l’informatique.
Les structures d’équipe sont importantes et les organisations dont la boussole est pointée vers les pipelines automatisés devront aborder les aspects culturels du déploiement continu si elles veulent déployer systématiquement plus rapidement.
Traditionnellement, l’incapacité à réaliser un déploiement continu a poussé les développeurs et les propriétaires d’applications à se tourner vers le cloud public, car il élimine les obstacles sur le chemin de déploiement plus lent de l’entreprise. La disparité des opinions sur la fréquence des déploiements contribue en partie au problème. Notre enquête NetOps / DevOps 2018 a révélé que si 55 % des DevOps et 52 % des architectes Cloud estimaient que leur organisation ne déployait pas assez fréquemment, seuls 30 % des NetOps et le même pourcentage des Opérations étaient du même avis.
Mais ce n’est pas le seul moteur. La transformation numérique est certainement un facteur ; 33 % des répondants à notre étude sur l’état des services application ont indiqué qu’ils envisageaient de proposer intentionnellement des applications à partir du cloud public en raison de l’adoption d’initiatives de transformation numérique . La possibilité d’intégrer facilement des services application et d’automatiser ensuite les opérations constitue un atout considérable pour les organisations à la recherche d’une voie plus rapide vers un déploiement fréquent.
Dans le cloud, mais également sur site, le déploiement continu nécessite souvent la capacité d'adopter des pipelines par application et des services application qui prennent en charge le modèle. De plus en plus, les organisations se tournent vers les conteneurs en raison de leur capacité à prendre en charge des mises à jour rapides et à fonctionner de manière transparente dans des environnements très volatils. Nous constatons que les conteneurs sont demandés non seulement pour prendre en charge les architectures application modernes telles que le cloud natif (le principal cas d'utilisation de conteneur pour 33 % des personnes interrogées dans le cadre du Container Adoption Benchmark 2019 de Diamanti ), mais également pour l'infrastructure. Selon nos propres recherches, la demande de services application sur site dans des conteneurs a constamment augmenté d’année en année, passant de seulement 4 % en 2017 à 15 % en 2019.
Tout n’est pas une question de livraison et de déploiement. Les organisations ont également besoin de rapidité en matière de sécurité et d’opérations. Dans le monde d'aujourd'hui, où plus de la moitié de toutes les interactions avec les applications sont effectuées par des robots, il est important pour les organisations de répondre rapidement avec un message de « rejet » pour éviter d'être la proie d'exploits ou d'infections.
L’une des façons dont les organisations cherchent à accélérer leur capacité à répondre aux attaques est d’adopter des analyses de menaces en temps réel. La « sécurité » restant une priorité absolue et un défi constant, il n'est pas surprenant de voir cette catégorie grimper dans le top cinq des tendances stratégiques et technologiques en 2019, avec 41 % des répondants la citant.
La disponibilité des services application de sécurité « intelligents » va s’accélérer à mesure que l’apprentissage automatique et l’automatisation continueront d’appliquer leurs capacités considérables au problème de l’identification plus rapide du trafic problématique.
L’apprentissage automatique n’est pas le seul moyen par lequel les infrastructures et les services application deviennent plus intelligents. À mesure que le besoin de réponses plus rapides en termes de capacité et de traitement augmente avec les utilisateurs, les services d'infrastructure et application évoluent pour inclure l'orchestration comme une capacité de base plutôt que comme un module complémentaire. Les plates-formes de services application avec couches d'orchestration intégrées offriront des services évolutifs en fonction de la demande, à la demande. Bien que de telles capacités existent aujourd’hui (elles font en effet partie intégrante du cloud et des conteneurs), les capacités d’augmentation et de réduction automatiques en fonction des exigences définies par application et l’utilisateur ne sont pas natives dans la plupart des systèmes actuels. Mais ils le seront.
Enfin, les organisations doivent lutter contre les robots pour des raisons commerciales et de sécurité. Que les organisations aient besoin de mettre un terme au scraping - une véritable menace pour les entreprises - ou d'empêcher les robots de rechercher des vulnérabilités, il est aujourd'hui essentiel d'identifier plus rapidement les mauvais acteurs de robots. Cocher une case (je ne suis pas un robot) ne suffit plus aujourd'hui car les robots deviennent de plus en plus intelligents et sont capables de déjouer ces techniques primitives .
Les organisations se tournent vers des services de défense contre les robots capables d’appliquer des techniques plus modernes et plus efficaces pour identifier et bloquer rapidement les robots malveillants. Nous avons constaté que l’ utilisation des services de défense contre les robots augmentait trimestre après trimestre en réponse à ce besoin, et nous prévoyons que cette tendance se poursuivra.
Lorsqu'il s'agit de répondre aux besoins de rapidité des entreprises d'aujourd'hui, nous finissons par examiner les processus. Les processus de développement sont automatisés pour gagner en rapidité avec le CI/CD. Les processus de déploiement sont automatisés pour gagner en rapidité avec le déploiement continu et le cloud. Les processus de mise à l’échelle et de sécurité sont automatisés par les systèmes et l’introduction de l’orchestration en tant que fonctionnalité native des plateformes de services application .
Il s'avère que la rapidité dépend de la capacité d'une organisation à automatiser les processus de développement, de déploiement et de sécurité.