Avec les applications sans serveur, l’observabilité est essentielle à votre réussite. Découvrez pourquoi vous devez construire avec l’observabilité comme première pensée.
Lorsque j’ai commencé à créer ma première application sans serveur, j’étais super excité de voir à quelle vitesse elle a commencé à se mettre en place. Le sans serveur se prête très bien à un développement rapide, à des cycles d’itération plus courts et à la recherche du produit adapté au marché le plus rapidement possible.
Au fur et à mesure que mon équipe et moi construisions l’application, nous avons naturellement commencé à la mettre à l’épreuve. Nous avons adoré sa rapidité, son évolutivité et la rapidité avec laquelle nous sommes passés de l’idée à quelque chose de réel sur nos écrans.
Mais cette excitation n’a pas duré très longtemps.
Il y avait quelque part un bogue dans notre code qui nous empêchait de terminer un processus métier critique. On m’a donc dit de trouver ce que c’était et de le réparer. Je suis allé voir l’un des ingénieurs de mon équipe et nous avons commencé à résoudre le problème.
Nous avons finalement découvert que le problème provenait d’un consommateur d’un sujet SNS. Il ne fonctionnait tout simplement pas. Nous ne savions pas s’il s’agissait d’un problème de publication de l’événement ou s’il s’agissait d’une erreur du consommateur lui-même. Nous ne pouvions pas dire exactement où était le problème afin de le résoudre.
Inutile de dire que c’était une situation assez stressante pour moi. Nous construisions ce grand système distribué sur une architecture pilotée par les événements, mais nous ne savions pas comment suivre les données dans le système. Cela m’a inquiété que nous ayons fait le mauvais appel pour passer sans serveur.
L’observabilité est difficile, et c’est encore plus difficile si vous ne construisez pas avec cela à l’esprit. Revenir à l’observabilité une fois que votre application est opérationnelle est une tâche difficile.
J’ai eu l’occasion récemment de m’asseoir avec plusieurs plateformes d’observabilité différentes. J’ai rencontré Éclairage, Baselime, Logz.io, DataDoget quelques startups en phase de démarrage pour discuter de l’état actuel et futur de l’observabilité.
Discuter avec autant de fournisseurs différents m’a fait réaliser à quel point l’observabilité est vraiment importante dans un environnement sans serveur. Bien qu’il s’agisse de l’objectif principal de la pilier excellence opérationnelle du cadre bien architecturé pour le sans serveur, ça n’a jamais vraiment cliqué avec moi.
Ce n’est que lorsque j’ai eu une conversation avec Tomer Lévy que j’ai réalisé la vraie raison pour laquelle nous devrions mettre autant l’accent sur l’observabilité.
L’observabilité consiste à atteindre votre SLA.
Savoir quand les choses commencent à mal tourner, suivre les traces via des diagrammes d’architecture et agréger les données des journaux, tout cela revient à maintenir la disponibilité et la disponibilité de votre système. Si vous ne disposez pas d’outils qui vous indiquent où et quand il y a un problème, vous commencez rapidement à ne plus respecter votre SLA et à donner une mauvaise expérience à vos clients.
Maintenir une haute disponibilité constante et résoudre les problèmes de manière proactive n’est pas une fonctionnalité « agréable à avoir » dans le SaaS. C’est une partie comprise de la réussite.
Un composant ingrat du logiciel, personne ne remarque quand vous faites correctement l’observabilité et répondez aux problèmes avant qu’ils ne soient signalés. Mais si vous rencontrez un problème dans votre service, vous commencez rapidement à perdre non seulement vos clients, mais également votre crédibilité en tant que fournisseur SaaS fiable.
De nombreuses options sont à votre disposition pour vous lancer dans l’observabilité. Peu importe que vous utilisiez un outil de surveillance des performances des applications (APM) ou l’un des nouvelles fonctionnalités d’observabilité vient de sortir dans CloudWatch, l’important est que vous observiez votre charge de travail.
Il y a une raison pour laquelle tant d’entreprises ciblent spécifiquement l’APM et l’observabilité – c’est important! Il s’agit d’un élément essentiel de la création d’une application qui offre un haut degré de fiabilité aux consommateurs.
Maintes et maintes fois, je vois des applications sans serveur en cours de création qui ne tiennent pas compte de l’observabilité jusqu’à la toute fin. Le code est écrit puis les outils de monitoring sont mis en place par la suite.
Bien qu’il n’y ait rien de mal à cette approche (et nous l’avons tous fait), elle se prête à certains moins qu’idéal paradigmes de surveillance. Vous commencez à combattre les outils ou à modifier le code lorsque vous essayez de les intégrer après coup.
Lors de la création de votre application, traitez la surveillance et l’observabilité comme un « citoyen de première classe ». C’est une partie de votre architecture qui est tout aussi importante que n’importe quel autre composant.
Avoir de solides pratiques d’observabilité signifie que vous pouvez réagir aux événements en temps réel. La gestion des erreurs, la mise à l’échelle de l’infrastructure et le suivi des sagas distribuées sont tous des aspects essentiels de la protection de votre SLA de disponibilité. La haute disponibilité n’est plus une fonctionnalité intéressante dans une application – c’est un incontournable. Les bonnes pratiques d’observabilité peuvent vous aider à gérer les problèmes avant qu’ils ne deviennent des problèmes majeurs.
De nombreux éditeurs de logiciels proposent leur point de vue sur les meilleures pratiques d’observabilité. Comptez sur eux pour vous guider vers les bonnes choses à surveiller et comment réagir lorsque les choses tournent mal. Trouvez le bon outil qui correspond à vos besoins et aux compétences de votre équipe.
Si nous ne mettons pas un accent précoce sur l’observabilité, nous ne le réparerons jamais. Commencez à l’intégrer à vos workflows, conceptions et modèles. Comme on dit, le meilleur moment pour commencer était l’année dernière. Le deuxième meilleur temps est aujourd’hui.
Bon codage !