Ceci est le deuxième article de notre série sur la façon dont vous, un développeur, pouvez créer ou améliorer le meilleur système de notification pour votre entreprise. Dans cet article, nous allons en apprendre davantage sur l’évolutivité et la fiabilité.
Lisez la première partie ici : Guide du développeur pour la création de systèmes de notification : partie 1 – Exigences de l’utilisateur.
L’application Web moderne s’appuie sur les notifications pour connecter un produit à ses utilisateurs. Les types de notification incluent push, SMS, e-mail et messages directs. Il existe de nombreux outils utiles pour créer un système de notification, mais ce n’est pas une tâche facile, surtout lorsque la fiabilité et l’évolutivité doivent être prises en compte.
Pour qu’une entreprise se développe, elle devra éventuellement décider entre le coût de construction et de maintenance de son propre système, ou opter pour la fonctionnalité et la fiabilité éprouvée d’un produit tiers. C’est ce qu’on appelle la décision classique de construction contre achat. Bien que le coût d’achat d’une solution puisse être clair, le coût de construction de la vôtre peut être difficile à calculer. Dans ce guide, nous couvrons en détail la création d’un système de notification évolutif et fiable pour vous donner une idée de l’effort requis.
Évolutivité et fiabilité : les clés du succès
L’évolutivité et la fiabilité sont deux aspects distincts, mais interdépendants, au cœur d’un bon système de notification. Vous gagnez en fiabilité lorsque votre client reçoit toutes vos notifications sans erreurs ni doublons. Cela signifie atteindre votre client de manière cohérente et à temps. L’évolutivité est l’endroit où votre application peut gérer des volumes de notification plus élevés en raison de la croissance de votre produit.
Améliorer la fiabilité d’un système de notification coûte du temps et de l’argent. Si vous êtes toujours à la recherche d’une adéquation produit-marché, il n’est peut-être pas judicieux d’un point de vue financier de donner la priorité à la fiabilité alors que vos ressources pourraient être mieux affectées ailleurs.
Une fois que vous aurez trouvé l’adéquation avec le marché des produits et élargi votre base d’utilisateurs, votre volume de notifications augmentera rapidement. Si votre croissance est rapide, vous pouvez choisir d’investir davantage dans la réparation d’autres parties critiques de votre application SaaS au lieu d’améliorer la fiabilité de votre système de notification. Mais vous pourriez compromettre la croissance de votre produit si vos clients ne reçoivent pas vos notifications en raison d’erreurs, de délais d’attente ou de retards. Si un système de notification problématique commence à avoir un impact sur l’expérience utilisateur, il est tout aussi susceptible d’avoir un impact sur vos résultats.
L’évolutivité et la fiabilité sont deux considérations clés pour toute décision de construction contre achat. Par exemple, lorsque la plate-forme de gestion des fonctionnalités LaunchDarkly prenait sa propre décision de construction contre achat, elle devait considérer ses SLA, SLO et SLI dans le cadre de son investissement dans un système de notification. Il avait récemment clôturé son financement de série D, et le volume et la charge substantiels, la conformité, la fiabilité et la stabilité étaient tous des facteurs clés dans le processus de prise de décision.
Pas d’évolutivité ou de fiabilité, pas de croissance
L’évolutivité et la fiabilité sont deux aspects différents. Mais les deux deviennent des préoccupations si vous voulez que votre entreprise suive une clientèle croissante. S’il vous manque l’un ou l’autre, vous rencontrerez probablement des problèmes en cours de route.
Si vos notifications manquent de fiabilité, l’impact de votre marque risque de perdre. Pour un produit comme Slack, une notification push différée n’a pas beaucoup d’utilité. Dans le cas de Slack, la rapidité est cruciale pour créer une conversation en temps réel entre les membres de l’équipe.
Mais même si vous n’êtes pas Slack, perdre la confiance des premiers utilisateurs dans votre système de notification peut ralentir la croissance. Il est peu probable que vos premiers utilisateurs recommandent votre produit s’ils ne font pas confiance à son fonctionnement. Les notifications en double représentent un autre scénario qui peut être un frein pour les premiers utilisateurs. La réception de doublons de notifications suggère fréquemment aux utilisateurs que le produit n’est pas suffisamment stable pour être utilisé, de sorte que les premiers utilisateurs peuvent hésiter à partager le produit avec leurs amis ou collègues.
Alors, quelle est la source la plus courante de problèmes d’évolutivité et de fiabilité dans un système de notification ?
D’après notre expérience, c’est le fait que les notifications sont rarement réparties uniformément dans le temps. La réalité des pics de volume imprévisibles nécessite de comprendre comment faire évoluer l’infrastructure pour gérer des volumes élevés à un coût raisonnable. Si un système ne s’adapte pas bien aux pics, les notifications finiront par être traitées et envoyées au-delà de leur fenêtre de pertinence. Dans le pire des cas, une file d’attente de messages surchargée peut entraîner une panne du système. Bref, si vous constatez que votre service se développe et que votre système de notification n’est pas équipé pour le gérer, vous prenez des risques considérables.
De plus, une application de notification doit rester disponible pour ses utilisateurs pendant le remplacement de son code. Si vous avez conçu votre application sans garder cela à l’esprit, vous risquez un temps d’arrêt prolongé pendant que vous travaillez dessus. Les temps d’arrêt signifient que vos utilisateurs ne recevront pas de notifications et ne seront pas intéressés par votre produit. En fin de compte, la conception de votre système de notification pour réduire les temps d’arrêt vous permet d’économiser du temps et de l’argent.
Un système construit sans à la fois l’évolutivité et la fiabilité de ses modèles de conception risque également de frustrer et de surcharger votre équipe d’ingénieurs. Les ingénieurs de garde risquent de s’épuiser s’ils doivent constamment répondre aux alertes du système de notification. De plus, si l’équipe d’ingénierie doit s’occuper à plusieurs reprises des problèmes de notification, elle peut manquer des priorités de produit importantes telles que l’ajout de nouvelles fonctionnalités, l’amélioration de l’expérience utilisateur et la création d’intégrations.
Pour construire un bon système de notification, il faut savoir mesurer sa fiabilité.
Mesurer la fiabilité d’un système de notification
L’ingénierie de la fiabilité du site est un moyen de gérer le fonctionnement de grands systèmes logiciels. Les principaux outils de l’ingénierie de fiabilité des sites sont les SLI (Service-Level Indicators), les SLO (Service-Level Objectives) et les SLA (Service-Level Agreements). Ce sont des normes qui forment des accords entre les utilisateurs et les fournisseurs de services, qui précisent les détails de la façon dont un produit est proposé et les conséquences si certaines dispositions ne sont pas respectées.
L’élément clé de toute mesure de fiabilité est la façon dont vos clients perçoivent votre produit. Par exemple:
- Quels niveaux de latence dans votre API vos utilisateurs associent-ils à une application qui fonctionne correctement ?
- Combien de temps un client attendrait-il que l’interface utilisateur se charge avant de décider qu’elle est en panne ?
- En combien de temps les tâches asynchrones doivent-elles se terminer pour que vos clients puissent continuer leur journée ?
Les SLA, SLO et SLI sont des outils pour représenter des réponses numériques à des questions comme celles-ci. Un SLI est une métrique qui établit les normes selon lesquelles un service doit être fourni à l’utilisateur. Un indicateur de niveau de service peut être la vitesse d’une opération de base de données ou la taille d’une file d’attente de notification. Ce sont les métriques réelles que vous afficheriez dans un outil comme AWS CloudWatch ou Datadog. Le SLI, en tant que mesure, est ce qui établit la base d’un SLO.
Un objectif de niveau de service est l’objectif récapitulatif que vous, en tant que fournisseur, souhaitez atteindre. Un exemple serait une latence spécifique d’un point de terminaison de notification, y compris les latences du middleware, des files d’attente ou des bases de données sous-jacentes. Ici, vous aurez particulièrement besoin de comprendre quelles mesures comptent réellement pour le client et d’adapter vos objectifs de produit dans cette direction.
La dernière couche est le SLA. Votre accord de niveau de service est un contrat juridiquement contraignant avec vos utilisateurs. Il est basé sur le SLO et les métriques fournies dans les SLI. Les SLA reflètent généralement les cibles définies dans la couche SLO. Un exemple serait un point de terminaison disponible et renvoyé dans un délai d’une seconde pendant 99,9 % du temps. Si votre produit est en retard par rapport à l’objectif, un client peut avoir le droit de demander un remboursement pour votre service. Les SLA lient donc les objectifs de service aux pertes financières directes lorsque les objectifs ne sont pas atteints.
Ces composants fonctionnent tous ensemble pour fournir une gamme spécifique de mesures dans lesquelles votre produit fonctionne correctement. Porter une attention particulière aux SLI et SLO, qui doivent être adaptés au client, peut aider à identifier les problèmes avant vos clients. Les choses iront mal, mais la façon dont vous réagirez à chaque situation fera une grande différence.
Les notifications seront un élément fondamental de votre fonctionnalité. Un exemple de SLI pourrait être la taille de la file d’attente de notification, et un SLO pourrait être la latence de traitement d’une notification depuis sa création jusqu’à son envoi à l’utilisateur.
Bien que la plupart des entreprises ne couvrent pas leurs notifications dans le cadre d’un SLA, cela peut toujours être nécessaire dans certaines circonstances. Par exemple, une application CRM B2B où les notifications doivent être utilisées comme rappels des appels clients à venir inclura probablement des normes liées aux notifications dans le cadre d’un SLA. Si votre produit nécessite la couverture des notifications dans le cadre d’un SLA, veillez à ce que les métriques et objectifs de votre produit soient alignés sur vos accords afin d’éviter les problèmes juridiques excessifs et conséquents. L’idée de devoir utiliser une API de fournisseur comme Mailgun ou SendGrid pour envoyer des e-mails, ou interagir avec un service de notification push comme Firebase Cloud Messaging pour les notifications iOS et Android, peut être un problème de fiabilité.
Si vous ne savez pas comment l’utilisation d’un fournisseur tiers aurait un impact sur vos mesures de fiabilité, lisez la suite ci-dessous.
L’utilisation d’API de fournisseurs tiers est-elle un problème de fiabilité ?
En considérant la portée de la création d’une solution de notification, vous pourriez vous sentir réticent à ajouter des API de fournisseur dans le mélange et donc vous concentrer sur la gestion de toutes les notifications en interne. Au lieu d’utiliser un fournisseur comme SendGrid ou Twilio, vous pourriez envisager de configurer une infrastructure de messagerie ou de SMS en interne.
Mais l’utilisation d’API de fournisseur est-elle un problème de fiabilité ?
Courier, par exemple, est une API HTTP. Il est vrai que les requêtes HTTP peuvent échouer en raison de problèmes de connectivité, d’erreurs SSL ou de retards inattendus. Peut-être que le client ne reçoit pas du tout de réponse HTTP à sa requête API. Vous pouvez essayer de rendre ces défaillances moins courantes en ne vous fiant qu’aux services qui résident dans votre espace réseau, mais en raison de la complexité des réseaux actuels, il ne sera pas possible d’éliminer complètement ces problèmes.
D’après notre expérience, la réponse n’est pas d’éviter complètement d’utiliser les API, mais de créer des mécanismes pour atténuer les échecs de demande d’API. Nous avons construit des mécanismes pour éviter de nombreux problèmes d’API HTTP. Par exemple, nous utilisons des clés d’idempotency pour réessayer en toute sécurité les messages sans envois en double au client. L’intégration de l’idempotency et d’autres processus tolérants aux pannes est un élément essentiel de la création d’un système de notification fiable.
Maintenant que nous avons couvert les concepts de base, discutons de suggestions spécifiques pour créer un système de notification évolutif et fiable pour les utilisateurs AWS.
Conseils pour créer un système de notification sur AWS
Si vous utilisez AWS, il existe de nombreux outils pour vous aider à créer un système de notification évolutif. DynamoDB et AWS Lambda font partie des services AWS que nous utilisons chez Courier, et les applications créées à l’aide de ces services peuvent être facilement évolutives et rentables à exécuter, tout en nécessitant peu ou pas d’entretien.
Néanmoins, vous devez veiller à éviter les goulots d’étranglement des performances, même lorsque vous utilisez des services tels que Lambda et DynamoDB. Ci-dessous, nous partagerons quelques conseils basés sur notre expérience d’utilisation des services AWS.
Suggestions pour l’évolutivité avec DynamoDB
La façon dont vous construisez pour l’évolutivité dépend des outils que vous choisissez, du moins en termes de la façon dont ils accèdent à vos données. Un système est évolutif lorsqu’il peut encore fonctionner dans les limites de ses objectifs de niveau de service, même avec une augmentation du volume….