Mehrere Instanzen für Anwendungen - Eine für jeden Kunden?

Question

Ich denke darüber nach, mein Produkt als Service anzubieten - online zugestellt. Derzeit ist es eine in sich geschlossene Software, die Benutzer auf ihre Server herunterladen und auf ihren Servern laufen lassen - wie fogbugz.

In meinem neuen Geschäftsmodell werde ich zwei Business-Modus anbieten, einer ist die traditionelle eingeschweißte Software, die Benutzer auf ihren Servern installieren - und alle Wartung, Upgrade-Sachen. Ein anderer ist der SaaS-Typ (Software as a Service), bei dem das Hosting auf meinen Servern erfolgt und Benutzern eine einzige URL zur Anmeldung zugewiesen wird. Natürlich hat jedes Kundenkonto eine eindeutige URL, beispielsweise companya.mysoft.com, companyb.mysoft.com.

Die Frage ist jetzt, da ich bereits eine vorhandene Codebasis habe, möchte ich minimale Änderung an meinem Code, so dass es zwei Geschäftsmodi unterstützt. Für den SaaS-Modus möchte ich mehrere Instanzen für die Anwendung erstellen - eine für jeden Kunden. Jeder Kunde hat also eigene Datenbanken, eigene Anwendungen. Alle Kundendatenbanken und Apps befinden sich auf meinem Server. Das Gute ist, dass ich meinen Code überhaupt nicht ändern muss. Das Schlimme ist, dass es eine Menge Redundanz gibt und möglicherweise nicht skalierbar ist.

Was denken Sie über diesen Multiple-Instance-One-for-Every-Customer? Oder muss ich meinen Code ändern, damit beide Modi unterstützt werden (einfach zu warten und für Upgrades)?

Edit: Die Download-Version ist benötigt, es gibt keine Möglichkeit, dies zu vermeiden.

Edit 2: Meine App ist eine PHP-App.

Answer 1

Eine vollständige Instanz pro Kunde erzeugt bei wachsendem Kundenstamm Wartungsalarme. Aber es könnte funktionieren, um Sie im SaaS-Geschäft zu beginnen. Seien Sie sich bewusst, dass der Erfolg wahrscheinlich bedeutet, dass die Re-Architecture der Anwendung besser skaliert werden muss.

Wichtige Details zu beachten sind:

Datentrennung, ist sehr wichtig, Pflege und Tausende von einzelnen Datenbanken erfordert eine Menge Aufwand aktualisieren. Ein häufiges Problem ist, dass Kunden sich sorgen werden, dass ihre Daten mit denen von jemand anderem gemischt werden und dass sie irgendwie weniger sicher sind. Ich habe für drei verschiedene Unternehmen gearbeitet, die ein SaaS-Modell angeboten haben, und das Mischen von Daten war nie ein Anliegen des Kunden. Am Ende des Tages haben Sie alle Daten und es wird oder wird nicht sicher sein, es ist nicht wirklich wichtig, wie viele dbs Sie verwenden. Sofern Sie nie mehr als ein paar Dutzend Kunden haben, empfehle ich dringend, mehrere Kunden in einer einzigen Datenbank zu konsolidieren und mehrere dbs zu unterstützen, was die Verwaltung der Datenbanken erheblich vereinfacht. Ich habe mit einem System mit mehreren PetaBytes Daten für über 80.000 Kunden gearbeitet, die auf ein paar Dutzend Datenbanken verteilt sind, und es war ziemlich überschaubar. Ich habe mit einem System mit ein paar TeraBytes Daten für mehrere Dutzend Kunden gearbeitet, jede mit ihrer eigenen DB und es hat ziemlich gut funktioniert. Dann bekamen wir eines Tages eine große Sache, die 300 Kunden auf einmal hinzufügte und die Verwaltung der Datenbanken wurde sehr umständlich.

Branding, ist jeder Kunde eine eigene Marke, oder teilen viele Kunden eine Marke, oder sind alle glücklich, die Marke Ihres Unternehmens zu verwenden. Im Idealfall können Sie Markenressourcen (css/images/etc.) Über URL oder Login oder wahrscheinlich beides finden. Wenn Sie nur eine Handvoll Marken benötigen, kann es sinnvoll sein, Server für jede Marke einzurichten.

Versionierung, ist es sinnvoll, alle Kunden zur gleichen Zeit zu "erzwingen". Ich rate Ihnen dringend, alles in Ihrer Macht Stehende zu tun, um alle Kunden auf der gleichen Version zu halten. Die Unterstützung mehrerer Releases wird Ihre Supportkosten erheblich erhöhen. Im Allgemeinen ist es einfach, die "Sie haben immer die neueste und beste" Facette zu drehen, aber einige Kunden sind wirklich ungern zu ändern.Kunden, die möglicherweise zurückgelassen werden müssen, müssen sich in separaten Instanzen befinden.

Anpassung, es klingt nicht wie Sie haben dieses Problem, aber wenn Sie derzeit benutzerdefinierte Builds an einige Kunden versenden, benötigen Sie separate Instanzen für jeden Build, bis Sie einen universellen Build erstellen können, der für alle funktioniert.

Answer 2

Hängt von der Anzahl der Kunden ab. Zunächst können Sie wahrscheinlich eine Instanz pro VM ausführen, aber sie ist nicht so skalierbar wie die Verarbeitung mehrerer Kunden pro Instanz.

Wenn es zu einer Haupteinnahmequelle wird, sollten Sie definitiv zu diesem Modell wechseln. Auf jeden Fall lohnt es sich zu testen, wenn eine große Nachfrage danach besteht, bevor man sich an die Arbeit macht.

Answer 3

Es ist schwer, diese Frage ohne weitere Informationen zu beantworten, aber mit dieser Art von Branding/Multi-Homing Fragen, die eine entscheidende Frage zu stellen, ist dies:

Diese Seiten sind (für die verschiedenen Kunden) immer ähnlicher als anders?

Jetzt ist das eine subjektive Frage. Wie viel sind zwei Standorte gleich? Können Sie das quantifizieren? Nicht wirklich.

Aber wenn die Antwort "sie sind fast völlig gleich" oder sogar "sie sind die gleichen" (Branding-Probleme ungeachtet) dann tun Sie sich einen Gefallen und Host nur eine Version des Codes und beide Seiten zeigen auf es.

Sie können einfach feststellen, welcher Server aufgerufen wurde, und Ihre Logik entsprechend ändern.

Branding ist das andere Problem, aber wenn Sie Ihre Anwendung richtig gemacht haben, sollte dies weitgehend ein Problem sein, Ihre CSS-Includes zu ändern, möglicherweise Ihr Javascript enthält (zB jQuery Styling) und (hoffentlich im schlimmsten Fall) Ihre Header ändern und Fußzeilen (Sie haben globale Kopf- und Fußzeilen richtig?).

Grundsätzlich, wenn die Websites sehr ähnlich sind, dann teilen Sie den Code und haben nur Ausnahmen für das, was anders ist. Wenn sie völlig anders sind, dann mache das Gegenteil. Cater für die häufigsten Szenarien.

Answer 4

DRY sagt nein. Fügen Sie Ihrer App einen rollenbasierten Geschmack hinzu, damit Sie Kunden 2, 3, 4 usw. leichter hinzufügen können.

Ich würde einige Zeit damit verbringen, darüber nachzudenken, was sich für Kunden in Ihrer App ändert und die App gestaltet daten- oder konfigurationsgesteuert sein.

Answer 5

Dies ist immer eine schwierige Entscheidung, und Sie haben festgestellt, dass die Installation einer neuen Instanz für jeden Kunden auf Ihrem Server zu großen Problemen führt. Es skaliert nicht so gut und es ist fast unmöglich, leicht zu aktualisieren. Plus es ist nicht sehr SaaS, da Sie im Grunde nur die Software N-mal installieren.

Allerdings gibt es eine Alternative. Halten Sie Ihre Datenbank gleich und installieren Sie für jeden Kunden eine neue Instanz der Datenbank. Aber ändern Sie Ihr Frontend, so dass es mehrere URLs verarbeiten kann. Auf diese Weise muss nur eine Instanz der Anwendung abhängig von der URL für mehrere Datenbanken ausgeführt werden.

Dies skaliert auch sehr gut, und ich denke, das ist das FogBugz-Modell? Dann, wenn Ihre Kunden es installieren möchten, gibt es wirklich keine Änderung, weil sie nur eine URL haben, die auf eine Datenbank verweist. Und auf Ihrer Seite haben Sie mehrere URLs, die auf mehrere Datenbanken zeigen, nur die Software wird nur einmal ausgeführt, um all diese Anfragen zu bearbeiten.

Auch als ein nettes zu haben, möchten Sie möglicherweise benutzerdefinierte Domänen berücksichtigen. Anstelle von companya.mysoft.com erlauben Sie companya.com. Das erfordert keine wirklichen Änderungen in der URL-Verarbeitung, die Compoany muss lediglich einen CNAME-Datensatz einrichten und auf Ihren Server verweisen.

Good Luck

Answer 6

„Das Schlimme ist, dass es eine Menge von Redundanz ist und nicht skalierbar sein.“

Wirklich? Wo ist die Redundanz?

Wenn Sie eine Reihe von Tools verwendet haben, kann Ihre SaaS-Installation eine Codebasis haben, die von mehreren Client-Sites verwendet wird.

Es funktioniert so.

• In einigen Baseline-Verzeichnis (wir verwenden Verzeichnisse wie /opt/theApp) Sie die Software haben.

• In einigen Arbeitsverzeichnissen (wir verwenden Verzeichnisse Beispiel /var/www/cust1, /var/www/cust2) haben Sie einige Konfigurationsdateien, die auf den Code verweisen.

Eine Codebasis, mehrere Installationen. In Django (und vielen anderen Web-Frameworks) ist dies relativ einfach.

Wenn Sie Ihre Tools schlecht gewählt haben, dann eine Website == eine vollständige Kopie des Codes und Sie haben ein potenzielles Problem. Dies sind jedoch die Links für. Sie haben die kundenspezifische "Kopie" mit Softlinks zur Grundkopie versehen.

Nachdem Sie sich bemüht haben, "kundenspezifische Funktionen" von "Web-Installation" und "Baseline-Code" zu trennen, werden Sie feststellen, dass Sie QA gut machen und kundenspezifische Funktionen und Erweiterungen bereitstellen können.

Mehrere Instanzen sind mehr skalierbar.Sie können Ihre SaaS-Umgebungen ohne große Schwierigkeiten auf mehrere gleichzeitige Prozessoren verteilen. Jede kundenspezifische Instanz bedient die Kundendaten und hält die Kunden sauber getrennt. Sie können (wenn Sie dies richtig angehen) alle eine gemeinsame Codebasis teilen, die auf einem (und nur einem) Server installiert ist.

Separate Installationen pro Kunde (mit einer gemeinsamen Codebasis) sind sehr angenehm, um den Kunden zu versichern, dass ihre Daten nicht zufällig mit den Daten ihrer Mitbewerber vermischt werden.

Answer 7

Aus dem DB-Winkel würde ich definitiv mit der einen DB pro Kundenmodell gehen. Der Vorteil, die Daten jedes Kunden unabhängig verwalten zu können, ist ein Muss. Mit diesem Ansatz können Sie skalieren, indem Sie bei wachsendem Geschäft verschiedene Kundendaten auf verschiedene Server legen.

Auch Ihr Web-/Anwendungsserver sollte in der Lage sein, mehrere Instanzen Ihrer App für verschiedene Benutzer und Kunden direkt aus der Box zu verwalten. Es sollte eine einzelne Kopie des Codes und mehrere Datensegmente aussortieren (angenommen, dass das Modell noch immer 20 Jahre hält). Auch das ist skalierbar - bewegen Sie sich zu einer Webfarm, und alles funktioniert immer noch - vorausgesetzt, Sie können Ihre Sitzungen sortiert bekommen.

So erhalten Sie eine Win/Win, Ihre Code-Basis bleibt ziemlich gleich, und Sie erhalten Skalierbarkeit wie von der Umgebung, die Sie verwenden. Sie können auch verschiedene Versionen einrichten, die Kunden testen können - wir haben oft mehrere Versionen der gleichen Website parallel laufen lassen, so dass wir einen Rollback durchführen können, wenn ein schwerwiegender Fehler uns bei einer neuen Version trifft.

Der Schlüssel, um dies funktioniert gut zu sehen ist, um die HTTP-Header zu sehen und die Config verknüpfen dh - welche DB und Software-Version, um darauf basierend zu zeigen.