Nous hébergeons PagerDuty sur AWS depuis environ un an. L'un des plus grands attraits de la plateforme pour nous était la promesse de composants prêts à l'emploi : sur AWS, il n'est pas nécessaire d'exécuter votre propre configuration de base de données redondante ou équilibreur de charge , car Amazon les fournit : pré-construits et gérés par des professionnels.

Enfin, c'est la théorie. Malheureusement, chaque fois que j'ai évalué un service AWS au-delà de leur simple hébergement EC2, AWS s'est révélé insuffisant. Le plus frustrant est peut-être que leurs services couvrent 95 % de ce dont nous avons besoin. Mais il leur manque toujours une petite fonctionnalité essentielle.

Considérez AWS équilibreur de charge élastique (ELB), par exemple. Il fournit un moyen simple de répartir le trafic de manière équitable sur toutes vos instances frontales. Il peut automatiquement arrêter le routage des requêtes vers les instances défaillantes, masquant ainsi complètement les échecs du réseau et des instances à l'utilisateur. L'ELB peut même lancer automatiquement de nouvelles instances en réponse aux pics de trafic. Tout cela nécessiterait un sérieux effort d'ingénierie pour être répliqué par vous-même.

Malheureusement, cette fonction est totalement inutilisable dans de nombreux déploiements réels. Le problème est qu'Amazon n'attribue pas d'adresses IP statiques à ses équilibreurs de charge. Au lieu de cela, vous obtenez un nom d'hôte et il vous est demandé de configurer des enregistrements CNAME en aliasant www.yourdomain.com avec le nom de l'ELB. Cela pose trois problèmes sérieux.

Tout d'abord, vous ne pouvez pas utiliser un CNAME pour la racine d'un domaine. En effet, un enregistrement CNAME ne peut pas coexister avec un enregistrement SOA au même point dans la hiérarchie DNS. Par conséquent, si votre site est hébergé sur votredomaine.com, vous devrez le déplacer vers www.votredomaine.com. Bien entendu, même avec des redirections en place sur le domaine d'origine, ce type de changement de marque sera inacceptable pour de nombreuses entreprises.

Deuxièmement, vous ne pouvez pas accepter correctement les e-mails envoyés à un domaine hébergé par un ELB. Cela est également dû à une limitation DNS : vous ne pouvez pas avoir un enregistrement MX et CNAME au même point dans la hiérarchie DNS. Même si vous pourrez peut-être accepter du courrier si vous exécutez un serveur SMTP sur les machines derrière l'ELB, cette configuration est loin d'être typique. Chez PagerDuty, c'est un véritable casse-tête, car nous devons être capables à la fois d'héberger un site et d'accepter le courrier sur votresous-domaine.pagerduty.com.

Enfin, vous n'avez aucune « solution » si l'ELB explose, à moins d'ajuster vos enregistrements DNS et d'attendre que les enregistrements mis en cache expirent. C'est un gros problème pour nous, car nous sommes très réticents à introduire dans l'infrastructure de PagerDuty des composants que nous ne pouvons pas remplacer rapidement en cas de problème.

La solution à ce problème est simple : il devrait être possible de mapper une adresse IP Amazon Elastic à un ELB. Étant donné que l'ELB aurait désormais une adresse IP statique, les problèmes DNS seraient résolus. Et si l'ELB explosait, vous pourriez simplement en provisionner un autre et remapper l'adresse IP, sans avoir à modifier le DNS. Je me rends compte que l'architecture « sans adresse IP statique » de l'ELB est probablement une décision de conception profondément ancrée, mais malheureusement, un LB sans adresse IP statique n'est pas vraiment utilisable.