Come progettare applicazioni per il cloud computing in cui potrebbero essere coinvolti più cloud

Question

Ho appena finito di esaminare questa domanda: https://stackoverflow.com / domande / 753.122 / che-cloud-computing piattaforma dovrei-i-scegliere

Ma non sono sicuro di cosa dovrei fare nella progettazione di un'applicazione per gli ingegneri della sicurezza, quindi è importante un elevato tempo di attività.

Quindi, se la mia applicazione è scritta in ASP.NET, usando SQL Server, sembrerebbe che la mia scommessa migliore sia progettare per Azure, ma la soluzione di Amazon sarebbe una buona scelta? Come deciderei se dovessi avere tutto sullo stesso sistema o avere i dati sul cloud di Amazon e ASP.NET su Azure?

Ho un'altra applicazione su cui sto lavorando che si occupa di informazioni di utilità, per acqua ed elettricità, quindi ci sono informazioni sull'utilizzo e sulla fatturazione, ed è stato scritto in PHP usando SQL Server. Sarebbe forse una buona applicazione per il cloud computing? Sembrerebbe che la soluzione di Amazon sarebbe la migliore soluzione per PHP, quindi la mia unica opzione, ma come decidi quali parti delle loro offerte usare?

Fondamentalmente la mia domanda è sull'architettura dell'applicazione. Progettare per l'hosting è semplice ma il cloud computing aggiunge nuove sfide.

La mia preoccupazione principale riguarda esclusivamente il design della mia applicazione.

Se decido la lingua, questo mi blocca in una soluzione cloud?

Quando vorrei che il database si trovasse in un cloud diverso rispetto all'applicazione?

Se volessi usare il framework LIFT (scritto in Scala), qualcuno di loro mi permetterebbe di installare tutto ciò di cui ho bisogno?

Answer 1

Eseguiamo servizi finanziari SaaS abbastanza ampi su Amazon AWS.

Ci sono due problemi generali qui in gioco: Architettura delle applicazioni e Servizi della piattaforma cloud.

Ho scoperto che la nostra architettura applicativa è sostanzialmente la stessa di quella che sarebbe se si stesse distribuendo su macchine virtuali interne o hardware reale. Abbiamo creato un'applicazione n-Tier abbastanza standard utilizzando principalmente strumenti open source (Java, Spring, Hibernate, MySQL, Terracotta, ...). Ci sono alcune considerazioni quando si tratta di un database ad alta disponibilità / tollerante agli errori (poiché le opzioni basate sull'hardware non sono disponibili) ma a parte questo, in realtà non "target". un'implementazione cloud specifica.

I servizi della piattaforma cloud sono completamente un'altra questione. Con questo intendo cose come:

• Avvio / arresto / monitoraggio / gestione / ridimensionamento delle istanze
• Disponibilità / ridondanza (ad es. Amazon ha zone di disponibilità)
• Distribuzione / inizializzazione / configurazione delle istanze
• Backup / ripristino dei file
• Sicurezza (ad es. controllo del firewall)

C'è poca o nessuna standardizzazione in quell'area, sebbene questa sia un'area di interesse attivo.

In termini generali, probabilmente vorrai progettare la tua applicazione in modo neutrale rispetto al cloud, ma creerai procedure operative molto specifiche.

Per quanto riguarda la suddivisione della presentazione e del DB tra diversi provider, non lo suggerirei perché:

• Se uno dei due provider non funziona, sei inattivo
• Il trasferimento di dati su Internet è più lento, più costoso e meno sicuro del trasferimento di dati all'interno di un provider cloud.

Un migliore utilizzo di più fornitori di cloud sarebbe quello di distribuire intere copie della tua applicazione su due o più, bilanciando il carico tra i due o possibilmente averne uno in hot standby nel caso in cui il primario non funzionasse. Se si acquisiscono dati transazionali, tuttavia, sarebbe necessaria una strategia per riconciliare i dati acquisiti nell'ambiente di standby. Ciò può o meno essere praticabile, a seconda della natura della tua domanda.

In genere puoi installare qualsiasi software che ti piace nei tuoi server virtuali, anche se non ho esperienza specifica con Azure. Se usi AWS o servizi simili, l'installazione di LIFT non sarà un problema.

Answer 2

Decidere una lingua non ti blocca in un provider; tuttavia, la progettazione per l'esecuzione su Windows lo fa. La virtualizzazione di Windows è un mercato molto più ristretto della virtualizzazione di Linux; Xen, la tecnologia Linode, Slicehost e così via, non virtualizzerà Windows più di una volta.

Con le tue applicazioni destinate a Windows, le tue scelte sono decisamente più sottili. Nel mio mercato, so che Amazon si rivolge a Windows (come fa Azure, ovviamente). Tuttavia, soluzioni più convenienti come la nostra e quella di Slicehost no: Windows ti costerà un premio.

Per quanto riguarda la segregazione cloud: il motivo principale per segmentare l'applicazione in più "cloud" è fornire affidabilità dell'applicazione. Le nuvole si abbassano - è vero, raramente - e avere tutte le uova nello stesso paniere ti costerà per un'applicazione che richiede alta disponibilità. Con il tuo database in un cloud separato dalla tua applicazione, tuttavia, subirai la latenza per l'esecuzione di SQL su Internet (oltre a richiedere un'architettura per proteggere quel traffico, come un tunnel SSH o la crittografia a livello di protocollo che SQL Server potrebbe offrire [non sono sicuro, sono un ragazzo PostgreSQL]).

Non cadere nella trappola di pensare che l'hosting cloud sia così diverso dall'hosting. In realtà, sono quasi gli stessi. Nella mia azienda abbiamo l'opinione che il cloud hosting sia solo un nuovo modo di pensare allo stesso 'ole hosting. Non è niente di magico.

Per progettare l'hosting cloud, l'applicazione deve solo avere funzionalità di sharding ed essere consapevole che i nodi potrebbero essere aggiunti o rimossi in qualsiasi momento. Non è tremendamente difficile da spiegare a seconda di come lo si progetta; di solito, solo un'applicazione di bilanciamento del carico è persino a conoscenza della semantica specifica del cloud.

Answer 3

È l'alba di " Cloud Computing " e come con qualsiasi insorgenza del genere, i concorrenti pongono le loro "trappole per mouse" sperando di catturarne il maggior numero possibile. Ci vorrà del tempo prima che i giocatori arrivino a definire un terreno comune (cioè standard in una forma o nell'altra) e fino ad allora, le loro armi di "differenziazione". ci costringerà a scegliere le parti.

Suppongo che anche questo sia "orientato al business" e verrà votato verso il basso .. ma hey, penso agli aspetti del business prima della tecnologia / lingua. Alla fine, si tratta di fare soldi.

Se qualcuno pensa a non essere bloccato a un fornitore di Cloud Computing (i tipi SaaS / PaaS mentre i fornitori di tipo IaaS sono più avanti) all'inizio del gioco, beh, sei pronto per grandi sorprese. Spara via!

DISCLAIMER: non rappresento un fornitore di Cloud Computing di alcun tipo (SaaS, PaaS, IaaS). Le persone che mi hanno votato non vogliono che identificino la loro fedeltà?