Wir hosten PagerDuty auf AWS seit etwa einem Jahr. Einer der größten Vorteile der Plattform war für uns das Versprechen vorgefertigter Komponenten – auf AWS müssen Sie keine eigenen redundantes DB-Setup oder Lastenausgleich , da Amazon sie bereitstellt: vorgefertigt und professionell verwaltet.

Soweit die Theorie. Leider hat AWS jedes Mal, wenn ich einen AWS-Dienst über das einfache EC2-Hosting hinaus evaluiert habe, enttäuscht. Am frustrierendsten ist vielleicht, dass die Dienste 95 % unserer Anforderungen abdecken. Aber es fehlt immer eine kleine, aber wichtige Funktion.

Betrachten Sie AWS elastischer Lastenausgleich (ELB) beispielsweise. Es bietet eine einfache Möglichkeit, den Datenverkehr gleichmäßig auf alle Front-End-Instanzen zu verteilen. Es kann die Weiterleitung von Anfragen an ausgefallene Instanzen automatisch stoppen und so Netzwerk- und Instanzausfälle vollständig vor dem Benutzer verbergen. Der ELB kann bei Datenverkehrsspitzen sogar automatisch neue Instanzen starten. All dies selbst zu replizieren, würde einen erheblichen technischen Aufwand erfordern.

Leider ist es in vielen realen Implementierungen völlig unbrauchbar. Das Problem ist, dass Amazon seinen Load Balancern keine statischen IPs zuweist. Stattdessen erhält man einen Hostnamen und wird aufgefordert, CNAME-Einträge einzurichten, die www.yourdomain.com als Alias für den ELB-Namen verwenden. Dies birgt drei gravierende Probleme.

Erstens können Sie keinen CNAME für die Stammdomäne verwenden. Dies liegt daran, dass ein CNAME-Eintrag nicht gleichzeitig mit einem SOA-Eintrag an derselben Stelle in der DNS-Hierarchie existieren kann. Wenn Ihre Website also unter yourdomain.com gehostet wird, müssen Sie sie nach www.yourdomain.com verschieben. Selbst mit Weiterleitungen auf der ursprünglichen Domäne ist eine solche Markenänderung für viele Unternehmen natürlich inakzeptabel.

Zweitens können Sie E-Mails an eine von einem ELB gehostete Domäne nicht ordnungsgemäß annehmen. Auch dies liegt an einer DNS-Einschränkung – Sie können einen MX- ​​und einen CNAME-Eintrag nicht an derselben Stelle in der DNS-Hierarchie haben. Zwar können Sie möglicherweise E-Mails annehmen, wenn Sie auf den Maschinen hinter dem ELB einen SMTP-Server betreiben, aber dies ist alles andere als eine typische Konfiguration. Bei PagerDuty ist dies ein echter Knackpunkt, da wir sowohl eine Site hosten als auch E-Mails unter yoursubdomain.pagerduty.com annehmen müssen.

Und schließlich gibt es keinen Ausweg, wenn der ELB ausfällt, außer die Anpassung Ihrer DNS-Einträge und das Warten auf das Ablaufen der zwischengespeicherten Einträge. Das ist für uns ein großes Problem, da wir sehr zögern, Komponenten in die Infrastruktur von PagerDuty einzuführen, die wir im Problemfall nicht schnell austauschen können.

Die Lösung für dieses Problem ist einfach: Es sollte möglich sein, eine Amazon Elastic IP einem ELB zuzuordnen. Da der ELB nun eine statische IP hätte, wären die DNS-Probleme gelöst. Und falls der ELB ausfällt, könnte man einfach einen anderen bereitstellen und die IP neu zuordnen – ohne DNS-Änderungen. Mir ist bewusst, dass die ELB-Architektur ohne statische IP wahrscheinlich eine tief verwurzelte Designentscheidung ist – aber leider ist ein LB ohne statische IP nicht wirklich nutzbar.