Django - Ich habe eine kleine App fertig, sollte ich auf private VPS oder Google App Engine gehen?

Question

Ich habe meine erste App, nicht so groß, aber es ist der erste Schritt. (nächste große auf dem Weg)

Jetzt, wenn ich es auf meinem eigenen Linode VPS setzen möchte, muss ich mod_python or mod_wsgi, sowie Memcache, Ngix, mySQL oder Postgresql, etc. zu konfigurieren, damit es funktioniert. Wenn ich es GAE sage, muss ich nur die Modelle konvertieren, um GAEs API zu verwenden.

Was ich an GAE mag, ist Skalierung. (Wenn sie es wirklich tun können)

Dann würde ich nur Sorgen über meine apps zu entwickeln und auf sie zu tun SEO-Arbeit statt sich Gedanken über Lastverteilung/Balance, Cache, db/IO Redundanz usw.

Ich möchte später nicht portieren. (Ich habe jetzt entscheiden, und bleiben Sie dabei)

Also, wenn Sie keine Erfahrung auf diesem haben, was Sie empfehlen:

1- Use VPS(s) for everthing 
2- Use VPS(s) plus Amazon S3 
3- Use VPS(s) plus Amazon S3 & SimpleDB 
4- Use GAE 

auch: Würde ich in der Lage sein, um wegzukommen mit nicht JOIN mit Rechte bei der Verwendung der BigTable?

Hinweis: Ich habe jetzt keine räumliche Notwendigkeit, aber für eine Standorttabelle könnte ich das später brauchen.

Ich würde gerne wissen, was meinst du?

Answer 1

Es besteht Geschäftsrisiko und technisches Risiko.

Geschäftsrisiko besteht darin, dass Sie Hosts später aus irgendeinem Grund externen zu bewegen haben könnte. VPS, EC2 usw. erfordern mehr Vorabinvestitionen, halten Sie aber unabhängig. Tools wie Chef können beim Konfigurationsaufwand helfen.

Technisches Risiko ist, dass Ihre Anwendung kann nicht einfach auf der Plattform implementiert werden. Da die meisten VPS-Optionen die Installation beliebiger Software ermöglichen, minimieren sie dies, allerdings auf Kosten eines höheren Konfigurationsaufwands. AFAIK, die größte Beschränkung, die GAE auf dich ausübt, ist es, lange laufende Hintergrundaufgaben zu erledigen. (Arbeiten ohne JOIN und andere Aspekte der de-normalisierten Daten erfordern eine andere Denkweise, aber dieser Ansatz ist ziemlich häufig in Web-Anwendungen, egal wo sie laufen, wenn die SQL-Datenbank größer als ein einzelner Host unterstützen kann.)

Wenn Sie mit diesen beiden Risiken leben können, scheint GAE Ihnen eine Menge Aufwand zu ersparen. Wenn Sie mit diesen Risiken nicht leben können, sollten Sie Ihre eigene Umgebung anpassen.

Als Nebenwirkung, finde ich S3 wert, egal Ihre Umgebung zu sein. Es ist viel einfacher als sicherzustellen, dass der statische Dateispeicher Ihres lokalen Servers zuverlässig gesichert wird und Sie sich nie um die Kapazität kümmern müssen. Es ist am besten, wenn Sie es für Daten verwenden, die hochgeladen, aber selten überschrieben oder gelöscht werden (denken Sie an Facebook-Fotoalben).

Answer 2

Ich mag voreingenommen sein, aber wenn Sie mit GAE's Einschränkungen leben können, erspart Ihnen eine Menge Arbeit und Sorgen über Systemverwaltungsprobleme (und in gewissem Maße Skalierung) - und es ist kostenlos, solange Ihr Ressourcenverbrauch ist niedrig (was bedeutet, dass der Traffic niedrig ist).

Können Sie ohne Joins auskommen? Ich weiß es nicht, da ich deine App nicht kenne - ich bin ein SQL-Fanatiker, ich selbst, aber für einfache genug Bedürfnisse habe ich es nicht gefunden zu schwer zu adaptieren. Wie ich es sehe, ist die Hauptbeschränkung von nicht-relationalen DBs, dass sie nirgendwo so nett sind wie relationale für "Ad-hoc" -Abfragen ... Sie müssen normalerweise viel prozeduralen Code schreiben anstatt eines netten SELECT oder zwei :-(. Aber das ist eher ein "Data Mining später" -Problem als eines, das mit dem Servieren Ihrer Web-App verbunden ist - wahrscheinlich am besten gelöst, indem regelmäßig Daten aus dem Online-Speicher der Web-App in ein Data-Warehouse-Setup heruntergeladen werden Wie auch immer, auch wenn solch ein Speicher war in erster Linie relational ;-).

Answer 3

Bevor Sie sich entscheiden, sollten Sie eine schnelle Anpassung Ihrer App an GAE in Erwägung ziehen. Möglicherweise stoßen Sie auf Stopper, die die Entscheidung erzwingen. Mögliche Anschlag Themen sind

• Ihr Schema nicht den Übergang zu BigTable macht
• Sie auf einige C-basierte Bibliothek abhängig, die GAE nicht
• Sie haben ein paar lang laufende Anfragen unterstützt dass die Schwellenwerte überschreiten, die GAE

Answer 4

ich möchte nicht später jede Portierung tun auferlegt. (Ich muss jetzt entscheiden und bleibe dabei)

Wenn das der Fall ist, möchten Sie nicht lieber die Bereitstellung von Anfang an steuern?Es könnte ein großer Schmerz sein, Port zurück von von GAE später auf der Linie, wenn Sie seine Grenzen stoßen (ob sie technologische Grenzen oder einfach Geschäftsentscheidungen von Google sind, die gegen Ihre Pläne für die Zukunft Ihrer App laufen).

Auch die Konfiguration von mod_wsgi, die Installation von Postgres usw. ist nicht besonders schwierig, und Sie müssen sich noch lange nicht um Dinge wie Load Balancing und DB-Redundanz kümmern.

Wenn es nach mir ginge, würde ich die langfristige Sicherheit eines traditionellen Server über den schnellen Sieg von GAE bevorzugen. Es hängt jedoch alles von Ihrer Vision für die App ab.

Answer 5

Die Antwort hängt wirklich von der Komplexität und der Art Ihrer Modellschicht ab. Wenn es komplex oder fest an den Rest Ihres Codes gebunden ist, ist die Portierung wahrscheinlich ein erheblicher Aufwand. Wenn es ziemlich einfach ist, oder einfach ausreißen und ersetzen, würde ich sagen, gehen Sie dafür.

In diesen Tagen habe ich meist neuen Code für GAE schreiben, aber die Tatsache, dass ich einfach mit einem einzigen Befehl bereitstellen können abgesenkt wirklich die Barriere ich coole neue Apps zu schreiben fühlen. Sich um Bereitstellung und Hosting keine Sorgen zu machen, ist ziemlich befreiend.

Answer 6

Alles, was ich zu tun habe, ist, die Modelle um GAE API zu konvertieren.

Es tut mir leid, Sie sind völlig falsch.

Sie müssen auch alle views Code neu zu schreiben, die die ORM verwendet. Es gibt keine Joins. Sie müssen also mit viel prozeduralem Code umgehen und schreiben, anstatt mit dem raffinierten SQL, das Ihnen alles bietet, was Sie wollen.

Querying is slow. Sie müssen außer Kraft zu setzen speichern Methode für jedes Modell dieses Modell zusätzliche Informationen zu speichern, die viel Zeit in Anspruch nehmen kann, wenn Bedarf zu berechnen. Sie müssen auch an memcache arbeiten, um die Abfragen schnell genug zu machen.

Und dann hat Guido sagte Django 1.1 wird in einer zukünftigen Version von appengine aufgenommen werden.Ich hoffe, dass sie einen Out-of-the-Box generischen ORM zu BigTable Mapper haben werden.

Das heißt, wenn Ihre App einfach ist, ohne viele Joins benötigt, könnten Sie das Appengine Patch-Projekt verwenden, um die aktuelle Version von Django auf Appengine zu verwenden. Here is how.