Wenn Sie Produkte unter Zeitdruck verkaufen (Tickets, Drop-Verkaufsaktionen, Buchungen, limitierte Bestände), haben Sie sicher schon einmal darüber gesprochen, wie man die Website skalierbar macht. Das endet in der Regel auf eine von zwei Arten: Entweder wechselt man die Plattform oder man fügt etwas hinzu und hofft das Beste.
Beides ist keine richtige Lösung. Das eine ist teuer, langsam und riskant. Das andere ist ein Sammelsurium von Einzellösungen, die unter Zeitdruck installiert werden – meist in der Woche vor dem Verkaufsstart.
Es gibt noch eine dritte Option, die schon die ganze Zeit in unserem Produkt enthalten war. Wir haben sie überarbeitet, und sie ist ab heute in Ihrem Kontrollpanel verfügbar.
Wir haben mit einem Reverse-Proxy angefangen. Dann haben wir zugesehen, wie er still und leise den Sieg davongetragen hat.
Der erste CrowdHandler war ein Reverse-Proxy. Man musste ihn lediglich auf eine beliebige Website verweisen, und schon erhielt man eine Warteschlange, die sich nicht umgehen ließ – ganz ohne Code-Integration. Kein Plugin. Kein SDK. Nur DNS.
Als wir 2021 als Self-Service-SaaS neu starteten, wirkte das wie die alte Vorgehensweise. Immer mehr Kunden betrieben ihre eigenen CDNs, und wenn bereits ein Edge-Server vorhanden ist, ist es besser, einen Worker dort einzusetzen, als einen weiteren Proxy davor zu schalten. Also haben wir eine Reihe von Edge- und SDK-Integrationen auf den Markt gebracht und den Kunden die Wahl gelassen, was am besten zu ihrem Stack passt. Die DNS-Implementierung blieb im Angebot für alle, die eine schnelle und nicht umgehbare Lösung wollten.
Dann hat es sich still und leise zu einer unserer zuverlässigsten Lösungen entwickelt. Es befindet sich vor Ihrer Infrastruktur und nicht darin, sodass Ihr Server niemals die Kosten für die Überprüfung und Weiterleitung von Nutzern tragen muss, und unsere jahrelangen Erfahrungen mit Skalierbarkeit fließen in unsere Ebene ein statt in Ihren Code. Für die meisten WordPress-Seiten ist dies eine bessere Integration als unser WordPress-Plugin. Uns ist bewusst, wie das klingt.
Das Setup geht nun davon aus, dass Sie bereits etwas vor sich haben.
Das Onboarding erfolgt in drei Schritten: Zertifikat ausgestellt, Herkunft festgelegt, CrowdHandler aktiviert.
Wir haben die Lösung außerdem für einen Fall überarbeitet, der sich als sehr häufig herausgestellt hat – nämlich den Betrieb unserer DNS-Implementierung hinter einem weiteren Reverse-Proxy, in den meisten Fällen Imperva. Wenn Sie unsere Lösung auf einer bestehenden WAF oder Sicherheitsschicht aufsetzen, erkennt das Setup dies bereits auf dem ersten Bildschirm und nicht erst nach dem dritten Support-Ticket.
Das Fenster zwischenspeichern. Die Kasse in die Warteschlange stellen.
Das ist das Entscheidende.
Jede Website besteht eigentlich aus zwei Websites. Ihre Marketinginhalte sind für jeden Besucher identisch und lassen sich, sobald sie zwischengespeichert sind, nahezu kostenlos skalieren. Ihr Transaktionsprozess – Warenkorb, Kasse, Buchung – ist für jeden Nutzer individuell, datenbankintensiv und niemals wirklich skalierbar. Behandelt man beide als Einheit, übernimmt man die schlechtesten Eigenschaften beider.
Mit Appcelerator können Sie diese Grenze nun auf URL-Ebene über das Control Panel festlegen. Legen Sie eine Verhaltensregel fest, und Ihre Landingpage wird vom AWS-Standort aus bereitgestellt, der dem Besucher am nächsten liegt. Keine Warteschlangenprüfung. Keine Wartezeit. Kein Hin- und Rückweg zu Ihrem Ursprungsserver. Für die meisten Nutzer wird die Seite schneller geladen, als es Ihr eigener Server jemals könnte.
Sobald Sie einen Kauf- oder Buchungsvorgang starten, werden Sie in die Warteschlange eingereiht, und diese Seiten werden – wie es sein muss – ohne Zwischenspeicherung bereitgestellt.
Es klingt einfach. Die Trennung von Marketing- und Transaktionsaspekten ist das A und O einer skalierbaren Webarchitektur, und die meisten Teams lernen das auf die harte Tour – während eines Verkaufs, um zehn Uhr morgens. Der Unterschied besteht hier darin, dass man dies nachträglich – auf eine Website, die ursprünglich nicht so konzipiert wurde – über einen Reverse-Proxy und ein Control Panel umsetzen kann, anstatt ein komplettes Plattformwechselprojekt durchzuführen.
Die Warteschlange ist das sichtbare Merkmal. Die Skalierbarkeit ist das Produkt.
Wenn man uns als die „Warteschlangen-Leute“ betrachtet, scheint Appcelerator eine einfachere Möglichkeit zu sein, eine Warteschlange zu installieren. Genau das ist es auch.
Aber schauen Sie sich einmal an, was es an einem ganz normalen Tag leistet – ohne Sonderangebote und ohne Warteschlangen. Es stellt Ihre zwischenspeicherbaren Inhalte von AWS-Edge-Standorten weltweit bereit, von denen jeder näher an Ihren Nutzern liegt als Ihr Ursprungsserver. Es fängt Datenverkehr ab, den Ihr Server gar nicht erst zu sehen bekommt. Es liefert ein Echtzeitbild der Leistung Ihrer Website. Und es ist bereit, den Zugriff auf Ihre Transaktionspfade zu drosseln, sobald diese unter Druck geraten.
Da alles über eine einzige Ebene läuft, greifen die Komponenten gegenseitig aufeinander zu. Der Cache verringert die Last, die auf Ihren Ursprungsserver wirkt. Ein entlasteter Ursprungsserver ermöglicht eine höhere Transaktionsrate. Eine höhere Transaktionsrate bedeutet, dass die Warteschlange Nutzer schneller aufnimmt, was kürzere Wartezeiten zur Folge hat – oder an ruhigen Tagen gar keine Warteschlange. Gleichzeitig überwacht dieselbe Ebene die Antwortzeiten auf den entscheidenden Pfaden. Wenn also die Nachfrage sprunghaft ansteigt, spiegelt die Zulassungsrate wider, was Ihre Website tatsächlich gerade bewältigen kann – und nicht eine Zahl, die jemand in einer Planungssitzung geschätzt hat.
Was Sie tatsächlich einschalten
Eine nicht umgehbare Warteschlange. Caching auf CDN-Niveau für Inhalte, die zwischengespeichert werden sollen. Durch eine Warteschlange geschützte Transaktionen für die Pfade, bei denen dies erforderlich ist. Kontinuierliche Leistungsmessung. Keine Code-Integration.
Richten Sie Ihre DNS-Einstellungen auf uns aus, und die Architektur, die Sie eigentlich hätten haben sollen, wird vor derjenigen angewendet, die Sie tatsächlich haben. Ihr Ursprungsserver muss davon nichts mitbekommen. Ihr CMS benötigt kein Plugin. Ihre Entwickler müssen sich nur um die Genehmigung der DNS-Änderung kümmern, sonst sind sie nicht weiter involviert.
Heute geht es los
Appcelerator finden Sie jetzt in Ihrem Kontrollpanel unter den Bereitstellungseinstellungen Ihrer Domain.
Wenn Sie unser WordPress-Plugin nutzen oder eine ordentliche Integration bisher aufgeschoben haben, weil es Ihnen wie ein technisches Großprojekt erschien, lohnt es sich, sich zehn Minuten Zeit dafür zu nehmen. Und wenn Sie Hilfe dabei benötigen, herauszufinden, welche Ihrer URLs auf welche Seite der Cache-/Warteschlangen-Grenze gehören, sprechen Sie uns an – das ist ein Thema, über das wir gerne sprechen.
Steht bei euch ein Sonderverkauf, ein Drop oder eine Kampagne an, bei der sich all das unter Beweis stellen könnte? Meldet euch kostenlos bei CrowdHandler an.