Interruzione del lock-in Python di Google App Engine?

Ci sono delle linee guida per scrivere il codice Python Google App Engine che funzionerebbe senza l'infrastruttura di Google su altre piattaforme?Interruzione del lock-in Python di Google App Engine?

Esiste un tentativo noto di creare un framework open source in grado di eseguire applicazioni progettate per Google App Engine su altre piattaforme?

Edit:

Per chiarire, la domanda è in realtà:

Se io sviluppare un'applicazione su Google App Engine ora, sarò in grado di migrare verso un'altra piattaforma più tardi, o è un blocco in ?

fonte

2009-05-21 Alterlife

Ricordo di aver letto una volta su un tizio che ha installato l'SDK sul proprio server e usato per servire le applicazioni GAE. Non ricordo la pagina e comunque era solo una specie di esperimento. –

C'è un certo numero di componenti necessari per fare un app completamente portatile:

L'ambiente di runtime stesso. Questo può essere convertito in modo relativamente semplice, impostando un server CGI o FastCGI che emuli l'ambiente App Engine (che in sé è fondamentalmente un CGI leggermente migliorato). La maggior parte del codice per farlo è già presente nell'SDK. Sfortunatamente, non esiste ancora un pacchetto di strumenti preconfezionati per questo.
Il datastore. Di gran lunga l'API più complicata da portare. Sono in corso numerosi sforzi: AppScale eseguito su EC2/Eucalyptus/Xen e utilizza un backend HyperTable o HBase; è ancora molto di qualità beta e non distribuiscono il connettore dati separatamente (è l'inizio di una soluzione completa run-your-app-on-your-own-cloud). Jens sta/stava scrivendo un SQLite backend, e c'è il mio progetto, BDBDatastore, che usa BDB-JE come back-end, ed è completamente funzionale (anche se di qualità beta). AppDrop, che altri hanno menzionato, utilizza semplicemente il server di sviluppo come back-end e quindi non è adatto per l'uso di produzione.
L'API degli utenti deve essere sostituita con qualcos'altro, come un'API basata su OpenID. Ancora una volta, abbastanza semplice, ma non ancora soluzioni premade.
L'API Memcache richiede un back-end che utilizzi i backend di memcache C standard.
Le altre API hanno backend perfettamente funzionanti come parte dell'SDK, quindi non hanno realmente bisogno di porting.
Anche il supporto cron avrebbe bisogno di essere implementato, così come l'elaborazione in background, XMPP, ecc., Quando saranno disponibili.

Come potete vedere, c'è molto lavoro da fare, ma non vi sono barriere fondamentali per far funzionare l'app App Engine fuori dall'ambiente di Google. In effetti, se sei interessato, sei più che benvenuto a partecipare: io e altri abbiamo in programma di unire le soluzioni per i vari pezzi in un'unica soluzione "OpenEngine" per l'hosting delle tue app.

fonte

2009-05-21 19:09:25

+1, analisi eccellente e dettagliata oltre a utili indicazioni. –

In sintesi: nessuna soluzione esiste ora, ma molte persone stanno lavorando per raggiungerla :). Grazie. – Alterlife

Ci sono stati progressi significativi in questo sforzo dal maggio del 09? –

Il codice dovrebbe essere per lo più portatile (fanno un buon lavoro indicando quali moduli non è possibile utilizzare su AppEngine e quale codice specifico di AppEngine corrisponde a quali moduli vietati), ma l'intero punto di AppEngine è quello di ottenere accesso all'infrastruttura di Google. Non ha molto senso scrivere il codice sulle restrizioni AppEngine se non si sta utilizzando la propria infrastruttura.

fonte

2009-05-21 11:20:45

Per chiarire, la domanda è davvero: Se sviluppo su google app-engine ora, sarò in grado di migrare a un'altra piattaforma in seguito, o è un blocco? – Alterlife

In questo caso, diventareGuru probabilmente ha la risposta per te. –

Finora, ho trovato un host sperimentale chiamato app-drop che è in grado di ospitare progetti google app-engine. Questo dovrebbe significare che è possibile possibile per eseguire progetti di motori di app al di fuori dell'infrastruttura di google.

Tuttavia, questo non è chiaramente ancora adatto per la produzione.

fonte

2009-05-21 11:29:56 Alterlife

Potrei sbagliarmi, ma il mio istinto mi direbbe di non contare su questo come un'alternativa di produzione a questo punto. –

È possibile creare applicazioni AppEngine utilizzando il framework Python di Django (sebbene la versione supportata sia un po 'indietro rispetto alla più recente versione di Django). Dove perdi la portabilità (almeno adesso) è quando usi GQL/BigTable per la persistenza. Questa è la piattaforma di database proprietaria di Google. Come ha detto Hank, questo è uno dei più grandi motivi per utilizzare effettivamente AppEngine, ma è anche il singolo punto di blocco più grande.

Qui ci sono un paio di link per Django supporto in AppEngine e GQL/BigTable:

fonte

2009-05-21 11:33:44

Usare un quadro di alto livello che funziona su AppEngine. In questo modo puoi trasferire il tuo codice ad altri server quando vuoi.

django è stato modificato e portato per funzionare nel progetto Appengine patch ed è il FW più utilizzato su appengine.

Si consiglia di consultare questo passo dopo passo intro di running a django app on App engine

Per quanto riguarda le infrastrutture in parallelo per eseguire un'applicazione App Engine è interessato, è ancora modo di gran lunga. App Engine non è diventato così popolare come la gente ci credeva e google voleva che fosse. Inoltre, è più difficile da sviluppare sulla struttura WebApp integrata che su django.

È piuttosto improbabile che venga visualizzata un'infrastruttura parallela per l'esecuzione dell'applicazione del motore di app, almeno per gli anni a venire. Piuttosto è probabile che il django e altri framework popolari funzionino fuori dagli schemi del motore delle app e il lavoro su questo è attualmente in corso nel progetto indicato.

fonte

2009-05-21 11:34:51

L'unico problema che osserverò con app-engine-patch è che non usa i modelli Django; invece espone direttamente i modelli GAE allo sviluppatore. Non è necessariamente una brutta cosa; ci sono alcune cose che puoi fare con i modelli Django che semplicemente non funzioneranno con GAE, e un'astrazione sarebbe molto dispersiva. Ma questo significa che dovrai riscrivere i tuoi modelli al minimo durante il porting da GAE a Django in modo nativo, e toccherai ogni query a causa delle differenze di sintassi: non una cosa banale su un grande progetto. – esm

Sono d'accordo con esm, lo stack di base è wsgiapp, cache, datastore e tutto ciò non ha importanza. Wsgiapp e la cache sono uno storage standard e persistente con caratteristiche bigtable che stanno arrivando velocemente (mongo, tokyo, memcachedb). –

"App Engine non è diventato così popolare come la gente ci credeva e google voleva che fosse, inoltre è più difficile svilupparlo sulla struttura WebApp integrata che su django." - Non sono d'accordo con entrambe le affermazioni. E le persone stanno lavorando sull'infrastruttura open source mentre parliamo - vedi AppScale, per esempio. –

AppDrop è una porta di prova di AppEngine su Amazon Web Services/Elastic Computing completata nell'aprile 2008. Utilizza un file flat anziché BigTable e viene eseguita in una singola istanza, pertanto sono presenti problemi di ridimensionamento; ma lo sviluppatore dice che gli ci sono voluti solo quattro giorni e forse queste limitazioni possono essere risolte da altri.

fonte

2009-05-21 11:35:57

In realtà non è una porta: è una versione modificata di dev_appserver. –

Ho eseguito la migrazione inversa da vanilla Unix al motore di app di recente molto facilmente utilizzando le risorse WHIFF. In pratica, configura qualsiasi cosa che sia dipendente dalla piattaforma come una risorsa e poi scambia/sostituisci le risorse su diverse configurazioni.

http://piopio.appspot.com/W1000_1000.resources

vedi anche

http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki

per un esempio dettagliato di risorsa scambio/configurazione. (nota: i collegamenti possono andare via alla fine, l'app è sperimentale.)

fonte

2009-07-21 14:13:47

Check out typhoonae. è in versione beta, ma abbastanza utilizzabile: abbiamo spostato una delle nostre app sul server interno che esegue questo stack.

fonte

2010-05-09 17:48:12

AppScale è l'implementazione open source più matura di Google App Engine. È in sviluppo dal 2008 e attualmente supporta tutte e quattro le lingue: Python, Java, Go e PHP. Oggi gli utenti eseguono la loro applicazione in produzione.

La FAQ spiega che cosa sono supportate le API e ciò che manca: https://github.com/AppScale/appscale/wiki/FAQs

(Disclaimer: io lavoro sul progetto)

fonte

2014-02-17 20:48:14

Interruzione del lock-in Python di Google App Engine?

risposta

Problemi correlati