Optimiser le développement d'applications avec le modèle serverless
Les opportunités offertes par 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 des applications à bien des égards. Cependant, elles laissent encore un certain nombre de décisions en matière de configuration, de maintenance et d'optimisation entre les mains des développeurs, plutôt qu'entre celles de la technologie elle-même.
Plus ces responsabilités incombent aux développeurs, moins ils disposent de temps pour créer des produits et des applications internes. Malheureusement, de nombreuses technologies largement adoptées laissent 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 un risque de choix médiocres ou d'erreurs susceptibles d'épuiser les budgets ou d'entraîner des vulnérabilités et des interruptions de service.
Cette inefficacité présente de graves conséquences. Fait alarmant, le temps consacré par les développeurs aux tâches hors codage coûte plus de 85 milliards de dollars chaque année aux entreprises.
Ainsi, l'élimination des complexités au sein du processus de développement des applications améliore d'autant l'expérience des développeurs et permet aux entreprises 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. Toutes les plateformes serverless ne se valent cependant 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 performances associés à la technologie sur laquelle elles ont été construites, c'est-à-dire les conteneurs, les régions et le cloud public.
Par conséquent, la technologie « serverless » telle que nous la connaissons aujourd'hui ne constitue 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 grâce à d'importantes améliorations architecturales. Ces améliorations évitent la perte de temps liée aux prises de décisions lors du processus de développement, soit autant de temps gagné que les équipes peuvent consacrer à la création de fantastiques produits et applications.
S'appuyer sur les méthodes de développement précédentes
Avant le serverless se trouvaient 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 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. Toutefois, avec les VM et les conteneurs, les tâches de gestion et de configuration qui ralentissent le processus de développement global continuent d'incomber aux développeurs.
À des degrés divers, les VM et les conteneurs contraignent les développeurs, de même que leurs équipes informatiques et de sécurité, à :
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, comme Kubernetes, allègent de nombreuses exigences de configuration associées aux conteneurs, notamment la gestion de l'échelle et de la redondance. Les équipes DevOps (Developer Operations), qui se concentrent sur la résolution des problèmes de développement internes plutôt que sur ceux qui affectent les services utilisés par les clients, doivent toutefois faire preuve d'une connaissance experte de Kubernetes pour gérer efficacement ces systèmes. Sans Kubernetes ni équipe correctement formée, les limitations affectant les conteneurs perdurent.
Les VM et les conteneurs ne constituent qu'une partie d'un ensemble 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'entreprise cliente certaines couches de configuration, comme la sélection des régions, la gestion de la sécurité, la conception de solutions de connectivité réseau et la garantie de la disponibilité. L'utilisation d'un cloud public nécessite également d'associer manuellement plusieurs services, comme les bases de données, les files d'attente de messagerie et le stockage. La procédure manuelle de configuration et de connexion de ces services allonge le délai global de déploiement, car elle se révèle particulièrement gourmande en temps.
Le développement serverless de première génération s'accompagne de ses propres inefficacités
Le développement serverless a été conçu pour surmonter les difficultés associées aux VM, aux conteneurs et au cloud public. Toutefois, les premières méthodes serverless n'ont connu qu'un succès partiel.
Vous trouverez ci-dessous quelques exemples des principaux défis entraînés par le développement serverless de première génération :
Latence et évolutivité. Bon nombre de ces plateformes serverless s'exécutent dans le cloud public, qui s'appuie sur des datacenters centralisés afin de 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. De surcroît, si l'évolutivité et le déploiement au sein de plusieurs régions s'avèrent possibles, leur configuration se révèle complexe.
Démarrages à froid et limitation du processeur. Les plateformes serverless bâties sur des conteneurs éprouvent des difficultés avec les démarrages à froid et la limitation du processeur. Les démarrages à froid correspondent aux retards de chargement constatés lorsqu'une fonctionnalité serverless s'exécute pour la première fois. Ces événements découlent du fait que la mise en route des conteneurs peut demander plusieurs secondes. La limitation du processeur survient, quant à elle, lorsqu'une plateforme atteint la limite d'instances serverless définie pour elle et retarde donc les requêtes.
Expérience médiocre pour les développeurs. Les développeurs doivent souvent assumer diverses tâches fastidieuses, telles que la mise en place de modèles d'orchestration, le dimensionnement de l'application et la définition des niveaux de mémoire. Ces tâches introduisent la possibilité d'erreurs coûteuses et réduisent le temps que les développeurs peuvent consacrer au codage. Ces petits aléas engendrent, au fil du temps, un certain coût pour les entreprises.
Observabilité limitée. De nombreuses plateformes de développement serverless s'avèrent difficiles à surveiller, car elles ne font pas preuve d'une observabilité adéquate. L'observabilité représente la possibilité pour une entreprise de comprendre les événements qui ont lieu dans un système décentralisé par le biais d'indicateurs de performance, de journaux d'événements, etc. Faute d'observabilité adéquate, une entreprise n'est pas en mesure de diagnostiquer ni de résoudre efficacement les problèmes survenant au sein d'une application serverless.
Le caractère sans état limite la fonctionnalité des applications. La première génération de plateformes serverless est effectivement sans état. Le caractère sans état facilite l'évolutivité, mais peut compliquer la création d'applications nécessitant une forte cohérence ou la coordination en direct de plusieurs clients, à l'instar des applications de chat interactif, des jeux vidéo ou des outils d'édition collaborative.
Coût. De nombreuses plateformes de cloud serverless sont soumises à des coûts supplémentaires et souvent dissimulés, comme les frais de passerelle d'API ou les frais de « maintien à chaud » des conteneurs. Le développement d'applications sur ces plateformes de première génération peut par conséquent s'avérer coûteux, notamment à grande échelle.
L'objectif du mouvement serverless a toujours été de faciliter le processus de développement d'applications. Toutefois, les plateformes serverless qui s'exécutent dans le cloud public centralisé n'honorent pas totalement cette promesse.
Repenser le serverless : l'évolution du modèle serverless
La nouvelle génération de plateformes de développement serverless a évolué de manière à combler les nombreuses lacunes des offres précédentes. En supprimant la dépendance envers des infrastructures existantes, comme les conteneurs et le cloud public, ces solutions proposent plusieurs améliorations et libèrent du temps pour les développeurs.
Ces améliorations comprennent les suivantes :
Exécution à la périphérie du réseau. Les plateformes serverless les plus avancées s'exécutent « en périphérie », c'est-à-dire au sein d'un réseau décentralisé composé de nombreux datacenters. Plus le réseau est vaste, mieux il répond aux problèmes de performances et d'évolutivité. En effet, sur les réseaux périphériques, les calculs s'effectuent dans le point de présence le plus proche de l'utilisateur final. Cette approche distribuée permet de réduire la latence et se révèle fondamentalement différente des modèles reposant sur des régions centralisées dans le cloud public. Le déploiement de code sur un réseau composé de centaines de datacenters offrira ainsi de meilleures performances que le déploiement sur un réseau constitué de 20 datacenters. Les plateformes périphériques les plus avancées offrent de longues durées de traitement processeur, un avantage permettant l'élaboration de charges de travail complexes.
Utilisation d'isolats plutôt que de conteneurs. Cette méthode permet d'éliminer les problèmes liés à l'architecture reposant sur des conteneurs (démarrages à froid et limitation du processeur), dont l'atténuation s'avère 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 du processeur.
Un nombre de décisions préalables plus faible. Certaines plateformes serverless périphériques récentes optimisent automatiquement les applications pour plus de performances et de sécurité. Les solutions reposant sur des réseaux périphériques mondiaux n'obligent 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 situés sur leur réseau. La suppression de ces tâches fastidieuses permet ainsi d'améliorer l'expérience des développeurs.
Analyses et journalisation détaillées. Si les premières plateformes serverless n'offraient pas un grand nombre de fonctionnalités en termes d'analyse, de débogage ou de journalisation, les plateformes serverless avancées présentent une observabilité accrue. Les analyses détaillées et la journalisation permettent aux équipes de développement de recueillir plus facilement les informations nécessaires au dépannage des problèmes. En outre, certaines plateformes intègrent des outils de surveillance plus sophistiqués, susceptibles d'être exigés par certaines applications plus complexes.
Coordination et stockage intégrés. Cette fonctionnalité permet l'intégration d'une architecture avec état au sein d'une approche serverless. L'architecture avec état nécessite un stockage de données cohérent, contrairement aux applications sans état, dans lesquelles les données sont transitoires. La création d'applications interactives en temps réel s'avère impossible en l'absence d'une architecture avec état.
Rentabilité. Les plateformes serverless périphériques légères et reposant sur des isolats se montrent moins coûteuses que les modèles précédents, à base de conteneurs. L'architecture fondée sur les isolats apporte tous les avantages associés au cloud en termes d'évolutivité et de flexibilité, sans les frais cachés ni les soudaines hausses de coûts.
Grâce à 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 permettent aux développeurs de se consacrer à l'essentiel, tout en réduisant les coûts pour l'entreprise.
Optimiser le développement d'applications avec Workers
Une plateforme serverless performante supprime les limitations en termes d'évolutivité, tout en soulageant les développeurs et en améliorant l'efficacité globale du processus de développement d'applications. Notre plateforme serverless périphérique Cloudflare Workers s'appuie sur une infrastructure intelligente pour soulager les développeurs de nombreuses décisions initiales. Grâce à l'infrastructure de Cloudflare, les applications conçues 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 de Cloudflare, qui s'étend à plus de 330 villes dans plus de 120 pays. Le code est automatiquement déployé dans toutes les régions, sans coût ni configuration supplémentaire. La solution Workers Unbound permet aux équipes de développement de créer des applications avancées, nécessitant de longues durées de traitement processeur, à la périphérie du réseau. Puisque la plateforme Workers s'exécute sur des isolats, plutôt que dans des conteneurs, elle permet d'éviter les phénomènes de démarrage à froid et de limitation du processeur. Workers propose une observabilité incorporée à son modèle 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, Command Line Interface) de Workers. La solution Durable Objects apporte à 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 aux clients de réaliser des économies en supprimant les frais cachés et en proposant une tarification inégalée dans ce secteur de 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. La solution améliore ainsi l'expérience des développeurs et s'avère financièrement bénéfique pour l'entreprise au fil du temps.
Cet article fait partie de notre série consacrée aux nouvelles tendances et évolutions susceptibles d'affecter les décideurs en matière de technologies d'aujourd'hui.
Points clés
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 des plateformes serverless de nouvelle génération
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 (plateformes de fonction en tant que service).