cloud hosting vs hosting gestito

Question

Sembra che l'hype su cloud computing non può essere evitato, ma l'effettiva transizione alla nuova piattaforma che è soggetto a molte discussioni ...

Dal punto di vista teorico, si può dire quanto segue :

cloud:

• cambiamento architettonico (si potrebbe non installare tutto quello che vuoi)
• curva di apprendimento (a causa di quanto sopra)
• alcun failover (dal guasto è preso cura di)
• costo granulare (pay per Ghz o Gbyte)
• scalabilità istantanea (non così istantaneo, ma almeno trasparente?)? minore latenza

Gestito:

• failover (dipende dal provider)
• scalabilità manuale (richiede manutenzione)
• costo statico (si paga il pacchetto, se lo si utilizza in tutto o in meno)
• più a basso costo (solo per i pacchetti entry-)
• dati proprietà (si fa)
• libertà (lo fai)? latenza inferiore (dipende dal provider)

Supponendo che quanto sopra sia corretto o no; Tuttavia, una posizione logica è "dipende ..." dall'applicazione stessa. Ora arriva la domanda nascosta: come configureresti la tua app j2ee per determinare se si tratta di un candidato al cloud o meno; sapendo che è

• una abbastanza grande applicazione in serie di servizi/funzioni (ie; servlet)
• si basa su un database complesso (cioè num tavoli..)
• non ha bisogno di risorse multimediali , principalmente testo

Answer 1

Di quale servizio Cloud stai parlando? IaaS, PaaS, Daas?

cambiamento architettonico (si potrebbe non installare tutto quello che vuoi)

Dipende: passaggio da un "server gestito" ad una piattaforma (ad esempio GAE) potrebbe essere.

curva di apprendimento (a causa di quanto sopra)

Amazon EC2 potrebbe non essere un grande curva di apprendimento se siete abituati a eseguire il proprio server

alcun failover (dal momento che il fallimento è preso cura di)

Dipende: EC2 -> si deve rotolare il proprio

scalabilità istantanea (non così istantanea, ma almeno trasparente?)? minore latenza Dipende: EC2 -> è necessario pianificare per questo/utilizzare un servizio aggiunto

Answer 2

"Adesso viene la domanda nascosta: come si dovrebbe profilo tua J2EE app per stabilire se si tratta di un candidato al cloud o no , sapendo che è "

Come parte, fai quella domanda esplicita. Rendilo il TITOLO di questa domanda. Mettilo all'inizio della domanda. Se possibile, elimina tutte le tue ipotesi e concentrati sulla domanda.

Ecco cosa facciamo.

1. Chiama alcuni fornitori per la disposizione "cloud" o "servizio gestito". Non troppi. Uno o due di ciascuno.

2. Chiedi loro cosa supportano. Ancora più importante, ciò che sono non supportano.

3. Quindi, dato un breve elenco di funzionalità che non sono supportate, guarda il tuo codice per quelle caratteristiche. Se non supportano le cose che ti servono, devi fare del lavoro di architettura. Oppure cancellali dalla lista dei tuoi fornitori preferiti.

4. Per i buoni venditori, scrivere un contratto pilota che consente l'accesso gratuito (o economico) per alcuni mesi per l'installazione e il test. Se non funziona, non hai pagato molto.

"Ma perché passare attraverso le spese di provare ad ospitarlo quando potrebbe non funzionare?"

Quale spesa? Puoi passare mesi a "studiare" il tuo codice. Oppure puoi provare ad ospitarlo. Di solito, il "provate ad ospitarlo" farà apparire una risposta entro pochi giorni. È meno fatica a farlo.

Answer 3

ci sono numerosi fornitori di cloud e, per quanto ho visto ci sono due tipi principali di loro:

• Quelli che sostengono una piattaforma di cloud computing (ad esempio Amazon E2C, MS Azure)
• virtuale provider di istanze che forniscono la possibilità di creare numerose istanze in esecuzione (ad es. RightScale)

Per quanto riguarda le piattaforme, tenere presente che il supporto del database relazionale è ancora piuttosto scarso e la curva di apprendimento è piuttosto lunga.

Per quanto riguarda i provider di istanze virtuali, la curva di apprendimento è davvero minima (devi solo attivare le istanze), ma le istanze devono sincronizzarsi ... per un'applicazione complessa potrebbe non funzionare.

Per quanto riguarda la tua domanda iniziale: non penso che ci sia un modo standard in cui potresti profilare se un'applicazione dovrebbe/potrebbe essere spostata nel cloud. Probabilmente hai bisogno di familiarizzare con le opzioni, restringere il campo a pochi provider e vedere se i benefici che otterresti sarebbero di qualche vantaggio significativo sull'hosting gestito (che probabilmente stai facendo attualmente).

Answer 4

Credo che i punti bisogna concentrarsi sono:

granular cost (pay per Ghz or Gbyte) 
instantaneous scalability (not so instantaneous, but at least transparent?) ? lower latency 

Modifica l'applicazione per funzionare su una nuvola avrà una buona quantità di tempo, ma non sarà davvero importa se la nube non abbassare i tuoi costi e/o non hai realmente bisogno di scalabilità istantanea/rapida (il classico esempio è l'app eCommerce)

Dopo aver considerato questi 2 punti. L'IMO che dovresti prendere in considerazione è relies on a complex database (ie. num. tables), poiché in base alla sua "confusione", passare a un ambiente cloud può essere davvero problematico.

Answer 5

In alcuni casi, confrontare il motore di app di google (gae) e amazon ec2 è come confrontare mele e arance.

Con ec2 si ottiene un sistema operativo, con o senza software server installato (tomcat, database, ecc., A scelta, a seconda di quale ami si sceglie). Con ec2 è necessario un (o essere un) amministratore di sistema per mantenere le cose senza intoppi. Il bilanciamento del carico su ec2 è qualcosa che dovrai capire e implementare; Non ho mai fatto quella parte. Il grande vantaggio di ec2 è che è possibile avviare e chiudere nuove istanze in modo programmatico e, rispetto a un normale server web, pagano solo quando l'istanza è attiva e funzionante. Si utilizza questo "auto spin up/down" per implementare il bilanciamento del carico e il failover. Ma devi fare l'implementazione (di nuovo, non ho esperienza con questa parte).

Con google app engine (gae), tutta l'amministrazione del sistema si prende cura di voi. Inoltre, si adatta automaticamente in base alle esigenze, sia sul lato dell'app che sul lato del database. Paghi anche solo ciò che usi; un'app inattiva che non riceve colpi non comporta costi. Gli svantaggi di Gae sono che sei limitato nelle lingue che puoi usare; python e java (o cose che girano su jvm, come jruby). Uno svantaggio ancora più grande è che il database non è sql (non lo chiamano un database, lo chiamano il datastore) e probabilmente richiederà rielaborare il tuo ddl se hai un database esistente; è un costo definito nel tempo del programmatore per capire come funziona e come usarlo efficacemente.

Quindi se stai partendo da zero (o sei disposto a riscrivere) e hai le risorse e il tempo per imparare i suoi modi, gae potrebbe essere la strada da percorrere. Se disponi di un amministratore di sistema o di sysadmin e hai il tempo o sai come configurare il bilanciamento del carico e il failover, ec2 potrebbe essere la soluzione giusta. Se la tua app sarà inattiva molto, ec2 è costoso; l'ultima volta che ho controllato era qualcosa come $ 70 al mese per lasciare una piccola istanza in su.