Les fonctions sans serveur sont une pierre angulaire de l’informatique Cloud moderne, largement adoptée dans tous les secteurs pour leur capacité à simplifier le déploiement et la gestion des applications.
Les fonctions les plus récentes éliminent le besoin de provisionnement des serveurs ou de maintenance de l’infrastructure, laissant les développeurs se concentrer uniquement sur l’écriture et le déploiement du code.
Les principaux fournisseurs de cloud comme AWS, Microsoft et Google proposent des fonctions sans serveur, ce qui rend cette option accessible à un large public.
Les fonctions sans serveur sont particulièrement efficaces pour les tâches à petite échelle telles que l’analyse d’images ou le traitement d’événements provenant d’appareils IoT.
Les fonctions peuvent être déployées rapidement et mises à l’échelle sans effort en réponse à la demande, ce qui les rend idéales pour les scénarios dans lesquels les charges de travail sont imprévisibles ou varient considérablement au fil du temps.
Quand les fonctions sans serveur brillent et quand elles ne brillent pas.
Les fonctions sans serveur excellent dans les scénarios où les tâches sont simples, isolées et axées sur les événements.
Les fonctions sont bien adaptées aux applications ad hoc qui nécessitent un déploiement rapide et n’impliquent pas de traitement de données complexe ou de flux de travail de longue durée.
Les fonctions sans serveur sont idéales pour automatiser les réponses en temps réel, comme le traitement des données provenant de capteurs IoT ou la gestion de processus backend légers tels que l’authentification des utilisateurs et le redimensionnement des images.
Toutefois, leur adéquation aux flux de travail complexes est discutable.
Des problèmes se posent lorsque des fonctions sans serveur sont utilisées dans des scénarios impliquant des données persistantes et critiques, telles que les opérations des compagnies aériennes.
Les compagnies aériennes gèrent de grandes quantités de données relatives aux vols, aux passagers, aux bagages, à l’affectation des portes d’embarquement et à la planification des équipages, ce qui exige une grande fiabilité et la capacité de traiter rapidement et avec précision d’importants volumes d’événements.
Dans de tels environnements, les limites des fonctions sans serveur deviennent apparentes.
La nécessité d’accéder fréquemment aux données et de les mettre à jour à partir de bases de données externes peut entraîner des temps de latence, en particulier dans les flux de travail impliquant plusieurs processus interconnectés.
Les frais généraux associés à l’allocation dynamique des ressources dans les architectures sans serveur aggravent encore ces problèmes de latence, ce qui peut nuire aux performances.
Les défauts cachés et les limitations qui freinent les fonctions sans serveur.
L’un des défis fondamentaux des fonctions sans serveur est le surcoût encouru lorsque les ressources informatiques sont allouées à la demande.
Ce délai, connu sous le nom de latence de « démarrage à froid », peut être particulièrement problématique dans les applications sensibles au facteur temps.
En outre, les fonctions sans serveur sont sans état, ce qui nécessite que les données soient récupérées à partir de sources externes pour chaque invocation, ce qui exacerbe encore les problèmes de latence.
L’absence de mémoire cache locale oblige à récupérer les données sur le réseau, ce qui ralentit les temps de traitement.
À mesure que les applications évoluent, les fonctions sans serveur peuvent introduire des défis architecturaux qui entravent la maintenabilité à long terme.
La difficulté vient de l’application d’une séparation claire des préoccupations au sein de la base de code peut conduire à une duplication à travers de multiples fonctions, rendant le système plus complexe et plus difficile à gérer.
La nature sans état des fonctions sans serveur complique également la gestion de l’état partagé et de la cohérence des données, qui sont essentielles dans les flux de travail complexes impliquant plusieurs processus interdépendants.
Le côté obscur des fonctions sans serveur
Les fonctions sans serveur fonctionnent dans un environnement dynamique où les ressources sont provisionnées et déprovisionnées à la demande.
Cela peut conduire à des comportements imprévisibles, tels que des dépassements de délais et des limites de quotas, qui ne sont généralement pas rencontrés dans les architectures traditionnelles.
Les développeurs doivent mettre en œuvre des mécanismes complets de gestion des erreurs et de réessai pour atténuer ces problèmes, ce qui ajoute de la complexité au processus de développement de l’application.
Une approche plus intelligente, qui rapproche le code des données pour de meilleures performances
L’informatique en mémoire est une alternative qui rapproche le code des données, réduisant ainsi la nécessité d’extraire constamment des données de sources externes.
Il s’agit d’une approche qui utilise des grilles de données en mémoire évolutives, où les données sont stockées dans la mémoire primaire d’une grappe de serveurs, ce qui permet aux fonctions d’être exécutées directement sur les données sans le temps de latence introduit par les magasins de données externes.
L’informatique en mémoire offre également une grande évolutivité, avec la possibilité de gérer de très grandes charges de travail en ajoutant des nœuds à la grappe au fur et à mesure que la charge de travail augmente.
La nature distribuée des grilles de données en mémoire garantit que même les applications les plus exigeantes conservent des performances élevées au fur et à mesure de leur croissance.
La redondance assurée par la réplication des données sur plusieurs nœuds minimise le risque de perte de données et garantit un fonctionnement continu même en cas de défaillance d’un nœud.
L’informatique en mémoire est la sauce secrète pour les flux de travail complexes
L’informatique en mémoire permet non seulement d’améliorer les performances, mais aussi de relever les défis architecturaux associés aux fonctions sans serveur.
En combinant les forces des magasins de structures de données et des modèles d’acteurs, l’informatique en mémoire aide les développeurs à structurer leur code plus efficacement, en réduisant les doublons et en améliorant la maintenabilité.
L’un des principaux avantages de l’informatique en mémoire est sa capacité à restreindre le traitement des objets aux méthodes définies par leurs types de données.
Cela permet d’éviter la duplication du code qui se produit souvent lorsque plusieurs fonctions serverless sont créées pour différents aspects du même flux de travail.
En centralisant la logique dans la grille de données, l’informatique en mémoire simplifie le développement et réduit le risque d’erreurs.
En outre, elle élimine le besoin de verrouillage des objets, un problème courant dans les systèmes reposant sur des magasins de données persistants, en permettant aux données d’être traitées directement en mémoire.
AWS Lambda vs. ScaleOut Digital Twins en test réel
Dans la mise en œuvre sans serveur, un contrôleur d’événements déclenche une fonction Lambda pour chaque annulation de vol.
Par la suite, une fonction Lambda « passager » est invoquée pour gérer la réinscription des passagers.
Il s’agit d’une fonction qui met à jour les informations du passager, le supprime du vol initial et l’ajoute au nouveau vol, ce qui nécessite des mécanismes de verrouillage pour synchroniser l’accès aux objets de la base de données Dynamo.
Comment AWS Lambda gère les flux de travail
AWS Lambda gère le processus d’annulation et de re-réservation en le décomposant en fonctions discrètes qui sont déclenchées par des événements spécifiques.
Chaque fonction fonctionne indépendamment, récupérant et mettant à jour les données dans DynamoDB.
Bien que cette approche soit flexible et évolutive pour les petites charges de travail, elle introduit un temps de latence dû à la nécessité d’extraire les données et de les synchroniser entre les fonctions.
Zoom sur la stratégie de jumelage numérique en action
En revanche, l’implémentation de Digital Twins de ScaleOut crée dynamiquement des objets en mémoire pour les vols et les passagers au fur et à mesure qu’ils sont accédés à partir de DynamoDB.
Des messages sont envoyés entre ces objets pour gérer les processus d’annulation et de réinscription, chaque objet passager gérant de manière autonome sa réinscription.
Pourquoi les jumeaux numériques écrasent le serverless en termes de vitesse et d’évolutivité.
Les résultats de l’analyse comparative démontrent clairement la supériorité de l’informatique en mémoire pour ce type de flux de travail.
Les jumeaux numériques ScaleOut ont traité 25 annulations de vols avec 100 passagers par vol 11 fois plus vite qu’AWS Lambda.
Alors que l’approche sans serveur a eu du mal à évoluer au-delà de la charge de travail cible, à savoir l’annulation de 250 vols avec 250 passagers chacun, l’implémentation Digital Twin a traité le double de cette charge de travail (500 vols) sans difficulté.
Les résultats montrent clairement les limites des fonctions sans serveur pour les flux de travail complexes et à grande échelle.
En revanche, la capacité des Digital Twins de ScaleOut à traiter les données directement en mémoire sans nécessiter de synchronisation externe favorise un traitement plus efficace des charges de travail plus importantes.
Dernières réflexions
Si les fonctions sans serveur offrent des avantages pour les petites applications ad hoc, elles peuvent s’avérer insuffisantes lorsqu’il s’agit de gérer des flux de travail complexes impliquant de gros volumes de données qui nécessitent une grande évolutivité.
Les limites en matière de latence, de frais généraux et de complexité architecturale peuvent rendre les fonctions sans serveur moins adaptées aux opérations à fort enjeu.
L’informatique en mémoire, en rapprochant le code des données, offre une alternative convaincante qui répond à de nombreux défis associés aux architectures sans serveur.
En réduisant le mouvement des données, en améliorant la vitesse de traitement et en simplifiant l’architecture, l’informatique en mémoire offre une solution plus efficace et plus évolutive pour les flux de travail complexes.
Il est essentiel de comprendre ces compromis pour prendre des décisions éclairées sur les technologies à déployer lorsque les entreprises repoussent les limites de leurs applications.
