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 muss man keine eigenen redundantes DB-Setup oder Lastenausgleicher , da Amazon sie bereitstellt: vorgefertigt und professionell verwaltet.

Zumindest ist das die Theorie. Leider hat AWS jedes Mal, wenn ich einen AWS-Dienst über das einfache EC2-Hosting hinaus bewertet habe, nicht mithalten können. Am frustrierendsten ist vielleicht, dass ihre Dienste 95 % unserer Anforderungen abdecken. Aber ausnahmslos fehlt ihnen ein kleiner, aber entscheidender Teil der Funktionalität.

Betrachten Sie AWS elastischer Lastenausgleich (ELB) zum Beispiel. Es bietet eine einfache Möglichkeit, den Datenverkehr gerecht auf alle Ihre Front-End-Instanzen zu verteilen. Es kann automatisch die Weiterleitung von Anfragen an ausgefallene Instanzen stoppen und so Netzwerk- und Instanzfehler vollständig vor dem Benutzer verbergen. Der ELB kann sogar automatisch neue Instanzen als Reaktion auf Datenverkehrsspitzen starten. All dies selbst zu replizieren würde einiges an technischem Aufwand erfordern.

Leider ist es in vielen realen Implementierungen völlig unbrauchbar. Das Problem besteht darin, dass Amazon seinen Load Balancern keine statischen IPs zuweist. Stattdessen erhalten Sie einen Hostnamen und werden aufgefordert, CNAME-Einträge einzurichten, die www.yourdomain.com als Alias für den Namen des ELB verwenden. Dies hat drei schwerwiegende Probleme.

Erstens können Sie keinen CNAME für die Stammadresse einer Domäne verwenden. Dies liegt daran, dass ein CNAME-Eintrag nicht mit einem SOA-Eintrag an derselben Stelle in der DNS-Hierarchie koexistieren kann. Wenn Ihre Site also unter yourdomain.com gehostet wird, müssen Sie sie nach www.yourdomain.com verschieben. Selbst wenn Weiterleitungen auf der ursprünglichen Domäne vorhanden sind, wird diese Art der Markenänderung für viele Unternehmen natürlich inakzeptabel sein.

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

Schließlich haben Sie keinen Ausweg, wenn der ELB abstürzt, außer Sie passen Ihre DNS-Einträge an und warten, bis die zwischengespeicherten Einträge ablaufen. Das ist ein großes Problem für uns, 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 wenn der ELB abstürzt, könnten Sie einfach einen anderen bereitstellen und die IP neu zuordnen – es sind keine DNS-Änderungen erforderlich. Mir ist klar, dass die „keine statische IP“-Architektur von ELB wahrscheinlich eine tief verwurzelte Designentscheidung ist – aber leider ist ein LB ohne statische IP nicht wirklich nutzbar.