Optimiser le développement d’applications grâce à la technologie serverless

L’opportunité qu’offre l’optimisation du développement d’applications

Les innovations telles que les machines virtuelles (VM), les conteneurs et le Cloud public ont amélioré le développement d’applications à bien des égards. Cependant, elles laissent encore un certain nombre de décisions en matière de configuration, de maintenance et d’optimisation aux développeurs, plutôt qu’à la technologie elle-même.

Plus ces responsabilités sont confiées aux développeurs, moins ils ont de temps pour créer des produits et des applications internes. Malheureusement, de nombreuses technologies largement adoptées confient aux développeurs le soin de gérer l’optimisation des performances, l’évolutivité des applications, les correctifs de sécurité, l’équilibrage de la charge, etc. Ces responsabilités introduisent le risque de choix sous-optimaux ou d’erreurs susceptibles d’épuiser les budgets ou de causer des vulnérabilités et des temps d’arrêt.

Cette inefficacité a de graves conséquences. Fait alarmant, le temps consacré aux tâches hors codage coûte plus de 85 G$ chaque année aux entreprises.

Ainsi, éliminer la complexité du développement des applications permet d’améliorer l’expérience des développeurs, tout en permettant aux organisations de réaliser des économies considérables.

La transition vers la technologie serverless

La technologie serverless a été conçue pour résoudre ces problèmes et améliore notamment le développement des applications en réduisant la charge qui pèse sur les développeurs. Cependant, toutes les plateformes serverless ne se valent pas. Les premières itérations des plateformes serverless ont hérité d’un grand nombre des problèmes de configuration, d’évolutivité et de performance associés à la technologie sur laquelle elles ont été construites – les conteneurs, les régions et le Cloud public.

Par conséquent, la technologie « serverless » telle que nous la connaissons aujourd’hui n’est souvent qu’une abstraction perfectible, bâtie sur les fondations d’un modèle ancien.

L’évolution des plateformes serverless avancées a permis de résoudre ces problèmes en proposant améliorations architecturales importantes. Ces améliorations éliminent les décisions fastidieuses du processus de développement, permettant aux équipes de consacrer plus de temps à la création de produits et d’applications sensationnels.

S’appuyer sur les méthodes de développement précédentes

Avant l’approche serverless, il y avait les VM et les conteneurs. Les VM sont des ordinateurs logiciels qui existent dans le système d’exploitation d’un autre ordinateur, et les conteneurs sont des unités logicielles standard qui contiennent tous les éléments indispensables au fonctionnement d’une application.

Ces deux technologies permettent aux développeurs de se concentrer davantage sur leurs applications et moins sur la gestion du matériel. Cependant, les VM et les conteneurs imposent toujours aux développeurs des tâches de gestion et de configuration qui ralentissent le processus de développement global.

À des degrés divers, les VM et les conteneurs obligent les développeurs et les équipes informatiques et de sécurité partenaires à :

  • Gérer les correctifs de sécurité et les autorisations relatives à la gestion des identités et des accès (IAM)

  • Configurer l’équilibrage des charges et la connectivité réseau

  • Garantir la disponibilité et intégrer la redondance

Les systèmes d’orchestration de conteneurs tels que Kubernetes allègent de nombreuses exigences en matière de configuration associées aux conteneurs, notamment la gestion de l’étendue et de la redondance. Cependant, les équipes DevOps (Developer Operations), qui priorisent la résolution des problèmes de développement internes, plutôt que les problématiques affectant les clients, doivent posséder une connaissance experte de Kubernetes pour gérer efficacement ce système. En l’absence de Kubernetes et d’une équipe correctement formée, les restrictions des conteneurs perdurent.

Les VM et les conteneurs ne sont qu’une partie d’un tableau plus vaste. Ces deux technologies peuvent être utilisées dans le Cloud public, qui comporte ses propres limites.

Le Cloud public permet de simplifier différents aspects du développement, mais laisse toujours à l’organisation cliente certaines couches de configuration, telles que la sélection des régions, la gestion de la sécurité, l’élaboration de solutions de connectivité réseau et la garantie de la disponibilité. Le Cloud public nécessite également d’associer manuellement plusieurs services tels que les bases de données, les files d’attente de messages et le stockage. La configuration et la connexion manuelles de ces services demandent beaucoup de temps, ce qui augmente le délai global de déploiement.

Le développement serverless de première génération introduit certaines inefficacités

Le développement serverless a été conçu pour surmonter les défis associés aux VM, aux conteneurs et au Cloud public. Cependant, les premières méthodes serverless n’ont connu qu’un succès partiel.

Voici quelques exemples des principaux défis que comportait le développement sur les plateformes serverless de première génération :

  • Latence et évolutivité. Un grand nombre de ces plateformes serverless s’exécutent dans le Cloud public, qui s’appuie sur des datacenters centralisés pour réduire les frais généraux. Ce modèle exige que les clients choisissent des régions de déploiement dans lesquelles leurs ressources seront physiquement situées. La centralisation des données introduit une latence, car le code est exécuté loin des utilisateurs finaux. En outre, l’évolutivité et le déploiement dans plusieurs régions sont possibles, mais leur configuration est complexe.

  • Démarrages à froid et limitation de la fréquence des processeurs. Les plateformes serverless construites sur des conteneurs sont affectées par les démarrages à froid et la limitation de fréquence des processeurs. Les démarrages à froid sont les délais de chargement constatés lorsqu’une fonctionnalité serverless est exécutée pour la première fois. Les démarrages à froid se produisent parce que le démarrage des conteneurs peut demander plusieurs secondes. D’autre part, la limitation de fréquence des processeurs se produit lorsqu’une plateforme atteint sa limite désignée d’instances serverless et retarde les requêtes.

  • Mauvaise expérience des développeurs. Les développeurs doivent souvent gérer des tâches fastidieuses telles que la mise en place des modèles d’orchestration, le dimensionnement de l’application et la détermination des niveaux de mémoire. Ces tâches introduisent la possibilité d’erreurs coûteuses et réduisent le temps que les développeurs consacrent au codage, ce qui représente, au fil du temps, un coût pour les organisations.

  • Observabilité limitée. De nombreuses plateformes de développement serverless sont difficiles à surveiller, car elles n’offrent pas une observabilité adéquate. L’observabilité est la mesure dans laquelle une organisation peut comprendre ce qu’il se passe dans un système distribué grâce aux indicateurs de performance, aux logs d’événements, etc. En l’absence d’observabilité adéquate, une organisation n’est pas en mesure de diagnostiquer et résoudre efficacement les problèmes d’une application serverless.

  • La nature sans état limite la fonctionnalité des applications. La première génération de plateformes serverless est effectivement sans état. La nature sans état facilite l’évolutivité, mais peut rendre difficile la création d’applications qui nécessitent une forte cohérence ou la coordination en direct de plusieurs clients, à l’image des chats interactifs, des jeux vidéo ou des outils d’édition collaborative.

  • Coût. De nombreuses plateformes de Cloud serverless comportent des coûts supplémentaires et souvent cachés, à l’image des frais de passerelle d’API ou des frais de « maintien à chaud » des conteneurs. Par conséquent, la création d’applications avec ces plateformes de première génération peut s’avérer coûteuse, surtout à grande échelle.

L’objectif du mouvement serverless a toujours été de faciliter le processus de développement d’applications ; cependant, les plateformes serverless qui s’exécutent dans le Cloud public centralisé n’honorent pas totalement cette promesse.

Repenser le modèle serverless : comment le modèle serverless a évolué

L’évolution de la nouvelle génération de plateformes de développement serverless a effacé les nombreuses lacunes des offres précédentes. En ne s’appuyant pas sur une infrastructure existante comme les conteneurs et le Cloud public, ces solutions offrent plusieurs améliorations et redonnent du temps aux développeurs.

Ces améliorations incluent notamment :

  • Exécution à la périphérie du réseau. Les plateformes serverless les plus avancées s’exécutent à la « périphérie », c’est-à-dire sur un réseau distribué formé par nombreux datacenters. Plus le réseau est vaste, mieux il répond aux problèmes de performance et d’évolutivité. En effet, sur les réseaux périphériques, le calcul s’effectue sur le point de présence le plus proche de l’utilisateur final. Cette approche distribuée réduit la latence et est fondamentalement différente des régions centralisées dans le Cloud public. Ainsi, le déploiement de code sur un réseau formé de centaines de datacenters offrira de meilleures performances qu’un réseau constitué de 20 datacenters. Les plateformes périphériques les plus avancées offrent de longs temps de traitement processeur, permettant la construction de charges de travail complexes.

  • Utilisation d’isolats, plutôt que de conteneurs. Cette approche permet d’éliminer les problèmes liés à l’architecture des conteneurs (démarrages à froid et limitation de la fréquence des processeurs), dont l’atténuation est coûteuse. Contrairement aux conteneurs, les isolats n’ont pas besoin de « maintien à chaud » ; les démarrages à froid ne constituent donc pas un problème. Les isolats consomment également moins de mémoire, réduisant ainsi les problèmes de surcharge et de limitation de la fréquence des processeurs.

  • Moins de décisions initiales. Certaines plateformes serverless périphériques récentes optimisent automatiquement les applications pour les performances et la sécurité. Les solutions reposant sur des réseaux périphériques mondiaux ne contraignent pas non plus les développeurs à choisir les régions dans lesquelles ils souhaitent héberger leur charge de travail, car elles déploient le code dans tous les datacenters sur leur réseau. La suppression de ces tâches fastidieuses améliore l’expérience des développeurs.

  • Données analytiques et journalisation détaillées. Si les premières plateformes serverless ne fournissaient pas un grand nombre de fonctionnalités de données analytiques, de débogage ou de journalisation, les plateformes serverless avancées offrent une observabilité accrue. Les données analytiques et la journalisation détaillées permettent aux équipes de développement de collecter plus facilement les informations nécessaires à la résolution de problèmes. En outre, certaines plateformes intègrent des outils de surveillance plus sophistiqués, que peuvent exiger certaines applications plus complexes.

  • Coordination et stockage intégrés. Cette fonctionnalité permet l’intégration d’une architecture avec état à une approche serverless. L’architecture avec état nécessite un stockage de données cohérent, contrairement aux applications stateless, dans lesquelles les données sont transitoires. Il est impossible de créer des applications interactives en temps réel en l’absence d’une architecture avec état.

  • Rentabilité. Les plateformes serverless périphériques légères basées sur des isolats sont moins coûteuses que leurs prédécesseurs basés sur des conteneurs. L’architecture isolée apporte tous les avantages associés au Cloud en termes d’évolutivité et de flexibilité, toutefois sans les frais cachés et les pics de coûts.

Avec ces améliorations, les plateformes serverless de nouvelle génération optimisent le processus global de développement d’applications, éliminent les tâches fastidieuses et aident les développeurs à prioriser les tâches essentielles, tout en réduisant les coûts pour l’organisation.

Optimiser le développement d’applications avec Workers

Une plateforme serverless performante supprime les limites d’évolutivité, tout en soulageant les développeurs et en améliorant l’efficacité globale du processus de développement d’applications.Cloudflare Workers est une plateforme serverless périphérique, qui utilise une infrastructure intelligente pour soulager les développeurs de nombreuses décisions initiales. Grâce à l’infrastructure de Cloudflare, les applications construites sur Workers sont toujours optimisées en termes de sécurité, de performances et de fiabilité.

L’évolutivité n’est jamais un problème, car Workers s’exécute sur le réseau mondial Cloudflare, qui s’étend à plus de 200 villes dans plus de 100 pays. Le code est automatiquement déployé dans toutes les régions, sans coût ni configuration supplémentaire. Avec Workers Unbound, les équipes de développement peuvent créer des applications avancées, nécessitant de longs temps de traitement processeur, à la périphérie. Puisque la plateforme Workers s’exécute sur des isolats, plutôt que sur des conteneurs, elle évite les phénomènes de démarrage à froid et de limitation de la fréquence des processeurs. Workers offre une observabilité intégrée et s’intègre à des outils de surveillance plus avancés, tels que New Relic et Sentry, en plus des outils de débogage et de journalisation disponibles depuis l’interface de ligne de commande (CLI) de Workers.Durable Objects offre à la plateforme Workers une coordination à faible latence et un stockage cohérent, faisant des applications serverless avec état une réalité. Dans le même temps, Workers permet à ses clients de réaliser des économies en supprimant les frais cachés et en proposant une tarification inégalée dans l’industrie.

Workers permet aux équipes de développement de se concentrer sur la création de produits, plutôt que sur la maintenance et la configuration, ce qui améliore l’expérience des développeurs et offre un avantage financier aux entreprises au fil du temps.

Cet article fait partie de notre série consacrée aux dernières tendances et évolutions susceptibles d'affecter les décideurs en matière de technologies d'aujourd'hui.

Principales conclusions

Cet article vous permettra de comprendre les points suivants :

  • Les implications d’une architecture de développement inefficace

  • Comment les méthodes de développement ont évolué pour nous mener à l’approche serverless

  • Pourquoi les premières itérations des plateformes serverless n’ont pas réussi à simplifier le développement d’applications

  • Les principales différences avec les plateformes serverless de nouvelle génération et les avantages qu’elles offrent aux entreprises

RESSOURCES ASSOCIÉES


Approfondir le sujet

Apprenez-en davantage sur les plateformes serverless telles que Workers dans le rapport The Forrester New Wave : Function-as-a-Service Platforms.

Consulter le rapport