Nous avons hébergé PagerDuty sur AWS Depuis environ un an. L'un des principaux attraits de la plateforme pour nous était la promesse de composants prêts à l'emploi : sur AWS, nul besoin d'exécuter vos propres composants. 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 son simple hébergement EC2, AWS s'est montré insuffisant. Le plus frustrant est peut-être que leurs services couvrent 95 % de nos besoins. Mais il leur manque systématiquement une fonctionnalité, certes minime mais essentielle.

Considérez AWS équilibreur de charge élastique (ELB), par exemple. Il permet de répartir facilement le trafic équitablement sur toutes vos instances front-end. Il peut automatiquement interrompre le routage des requêtes vers les instances défaillantes, masquant ainsi complètement les défaillances du réseau et des instances. L'ELB peut même lancer automatiquement de nouvelles instances en cas de pics de trafic. Répliquer tout cela par vos propres moyens nécessiterait un important effort d'ingénierie.

Malheureusement, cette fonctionnalité 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. À la place, vous obtenez un nom d'hôte et devez configurer des enregistrements CNAME avec un alias www.votredomaine.com pour le nom de l'ELB. Cela pose trois problèmes majeurs.

Premièrement, 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 sûr, 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, il est impossible d'accepter correctement les e-mails d'un domaine hébergé par un ELB. Cela est également dû à une limitation DNS : il est impossible d'avoir un enregistrement MX et un enregistrement CNAME au même point dans la hiérarchie DNS. Bien qu'il soit possible d'accepter les e-mails en exécutant un serveur SMTP sur les machines derrière l'ELB, cette configuration est loin d'être courante. Chez PagerDuty, c'est un véritable casse-tête, car nous devons pouvoir héberger un site et accepter les e-mails sur votresous-domaine.pagerduty.com.

Enfin, vous n'avez aucune solution de rechange en cas de panne de l'ELB, à moins d'ajuster vos enregistrements DNS et d'attendre l'expiration des enregistrements en cache. C'est un problème majeur pour nous, car nous hésitons beaucoup à 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. Puisque l'ELB aurait désormais une adresse IP statique, les problèmes DNS seraient résolus. Et si l'ELB explosait, il suffirait d'en provisionner un autre et de remapper l'adresse IP ; aucune modification DNS n'était nécessaire. Je suis conscient que l'architecture « sans adresse IP statique » de l'ELB est probablement un choix de conception bien ancré, mais malheureusement, un ELB sans adresse IP statique n'est pas vraiment utilisable.