En tant que PDG et cofondateur d'IOpipe, Adam Johnson travaille avec des développeurs individuels et des équipes d'ingénierie d'entreprises mondiales pour obtenir une visibilité en temps réel sur les comportements détaillés de leurs applications sans serveur.

Selon Le livre électronique 2018 de The New Stack L'adoption du sans serveur a augmenté de 75 % depuis 2017, mais les développeurs continuent de citer des préoccupations concernant les performances, les risques et la surveillance des applications comme des inconvénients à la construction d'une architecture sans serveur.

Malgré les progrès réalisés l'année dernière en matière d'outils d'observabilité, les alertes en cas d'anomalies de performance et de perturbations utilisateur constituent un élément crucial, mais encore négligé, permettant aux équipes d'ingénierie de déployer des applications sans serveur en toute confiance. Dans ce contexte, Adam a partagé certains des défis auxquels il a été confronté dans ce secteur, ainsi que les meilleures pratiques et des conseils techniques dans cette séance de questions-réponses.

Q : En quoi la surveillance diffère-t-elle pour les applications sans serveur par rapport aux architectures traditionnelles ?

UN: La principale différence avec la surveillance sans serveur réside dans l'accent mis sur la logique métier qui traverse le système, au détriment de l'infrastructure. Avec les architectures sans serveur, les problèmes d'infrastructure échappent largement à votre contrôle et sont gérés par les fournisseurs de cloud qui exploitent la plateforme FaaS (Fonctionnalité en tant que service). Les entreprises peuvent ainsi se concentrer sur l'impact de leurs activités.

Par exemple, certaines des principales marques de commerce électronique utilisant IOpipe créent des alertes en fonction des volumes de commandes attendus. Ainsi, lorsqu'il y a une baisse (ou un pic) inattendue des commandes, elles peuvent être averties en quelques secondes si quelque chose sort de l'ordinaire.

Bien que le développement sans serveur offre des avantages en termes de rapidité et de coût, de nombreux développeurs peinent encore à observer le comportement de leurs applications sans serveur. Par exemple, comment tracer des millions d'appels pour identifier les utilisateurs impactés par un problème de performance ? En cas de problème, comment isoler rapidement la ou les fonctions responsables afin de minimiser les perturbations de l'activité ?

La surveillance traditionnelle n'est pas nécessairement configurée pour gérer les différents défis des architectures sans serveur ou maximiser les chances des développeurs et des équipes DevOps de traduire les mesures d'infrastructure en informations commerciales lorsqu'ils transfèrent les charges de performance et de mise à l'échelle aux fournisseurs de cloud.

Q : Quels sont les avantages et les inconvénients des applications sans serveur par rapport aux applications monolithiques ?

UN: Le principal avantage du sans serveur par rapport aux applications monolithiques est qu'il permet aux développeurs de se concentrer entièrement sur la création et la livraison de la logique métier. Les entreprises peuvent ainsi offrir de la valeur à leurs clients plus rapidement. Les développeurs n'ont plus besoin de consacrer du temps au codage et à la configuration de l'infrastructure pour planifier les évolutions. La mise à l'échelle est prise en charge immédiatement. Outre une livraison plus rapide, vous ne payez que ce que vous utilisez en sans serveur. Les avantages financiers sont donc généralement significatifs, les entreprises signalant des économies allant jusqu'à 90 % en abandonnant les machines virtuelles et les conteneurs.

Le principal inconvénient est que, sauf si vous définissez le niveau de concurrence à 1, vous utilisez un système distribué. Cela peut engendrer de nouveaux défis, notamment pour l'observabilité de ces systèmes. Heureusement, il existe une multitude d'outils de nouvelle génération qui fournissent des informations détaillées sur les applications sans serveur, améliorant même la visibilité par rapport aux applications monolithiques existantes.

Q : Quels sont les principaux problèmes de performances sur une architecture sans serveur ?

UN: L’un des problèmes les plus discutés autour des performances sans serveur concerne démarrages à froid , ce qui se produit lorsqu'il y a un léger retard dans le lancement d'un nouveau conteneur. Heureusement, pour des langages comme Node.js et Python, l'impact des démarrages à froid a été considérablement réduit, atteignant quelques millisecondes dans AWS Lambda. Pour d'autres langages comme Java, les démarrages à froid peuvent néanmoins avoir un impact significatif sur les performances.

Cependant, des outils d'observabilité sans serveur comme IOpipe peuvent offrir une visibilité sur les performances des démarrages à froid. Cela permet aux utilisateurs de comprendre l'impact réel et de déterminer s'il est nécessaire d'optimiser l'opération.

Q : Pour une entreprise ou un développeur novice en matière de solutions sans serveur, quelles sont les alertes standard qu'ils devraient implémenter dès le départ ?

UN: La première alerte que les clients IOpipe configurent généralement concerne les défaillances d'applications. Nombre d'entre eux configurent des alertes sur le taux d'erreur de leurs applications sans serveur afin d'être avertis dès que le taux d'erreur dépasse leur seuil de tolérance.

Une autre alerte fortement recommandée est l'invocation spontanée des fonctions devant s'exécuter un certain nombre de fois par période. Ainsi, si une fonction doit s'exécuter au moins une fois par jour, il est conseillé de configurer une alerte pour être averti lorsque la fonction ne s'exécute pas ce jour-là.

Pour les applications sans serveur qui traitent un flux ou des lots de données dont le volume est assez prévisible, la configuration d'alertes sur les seuils supérieurs et inférieurs du nombre d'appels est un moyen utile d'identifier quand il y a un problème dans le pipeline de données.

Q : Comment les développeurs ou les équipes DevOps doivent-ils gérer le débogage face au volume accru de journaux de fonctions inhérent au sans serveur ?

UN: Investir du temps dans l'instrumentation des applications sans serveur avec des journaux et des étiquettes structurés peut éliminer complètement le besoin de fouiller dans les fichiers journaux. Un petit effort initial peut vous faire gagner des heures, voire des jours, de précieux temps de débogage en cas de problème.

Q : Comment les développeurs intègrent-ils la surveillance sans serveur à leur compte PagerDuty existant ?

UN: IOpipe offre une intégration native avec PagerDuty. En quelques clics, les développeurs peuvent être avertis via PagerDuty dès que leurs alertes sont déclenchées.

En partenariat avec PagerDuty et en fournissant une observabilité et une surveillance sans serveur pour des organisations comme Rackspace, Matson et Comic Relief, IOpipe a récemment publié une refonte de ses fonctionnalités d'alertes sans serveur pour les environnements d'exécution Python, Node.JS, Go et Java sur AWS Lambda.

Vous souhaitez en savoir plus ? Consultez le PagerDuty – Guide d'intégration IOpipe.