Architettura agnostica del cloud?

Question

Sto eseguendo alcuni lavori di architettura su una nuova soluzione che verrà inizialmente eseguita in Windows Azure. Comunque mi piacerebbe che la soluzione (o almeno l'architettura/design) fosse Cloud Agnostic (fino a che punto sia realistico). Qualcuno ha mai lavorato su questo fronte o ha visto dei buoni white paper/post sul blog?

La nostra architettura di alto livello consisterà in un payload inviato a un servizio Web (WCF per esempio), questo verrà scaricato su una coda (per ragioni) e un processo di lavoro attirerà i messaggi da questa coda e li procede. Ci sarà un database di informazioni sui clienti che preferiremmo tenere fuori dal cloud, tuttavia ci sono evidenti considerazioni sulle prestazioni.

Ansioso di ascoltare i pensieri altrui.

Acclamazioni Dave

Answer 1

Dopo aver postato in origine questa domanda 2,5 anni fa, abbiamo raggiunto la nostra soluzione. Recentemente ho scritto un post su Avoiding Cloud lock-in che parla di come definire un'architettura indipendente dal cloud. http://www.cloudycover.com/post/26549365156/avoiding-cloud-lock-in

L'azienda in questione è un fornitore di cloud-based piattaforma HPC che offre offload senza soluzione di continuità dei carichi di lavoro compute-intensive al cloud in cui si deve solo a pagare per millisecondi di tempo di calcolo consumati: http://www.greenbutton.com

Answer 2

direi che questo è un buon fiammifero per Java Enterprise Edition. Anche se questo significa che sarai bloccato con Java, almeno avrai molte soluzioni commerciali disponibili per la maggior parte dei servizi che descrivi.

Answer 3

Suppongo che agnostico del cloud intendi agnostico per la piattaforma particolare su cui stai lavorando, come GAE, Amazon EC2 o Azure e desideri scriverne uno, distribuire ovunque.

In teoria, ciò dovrebbe essere possibile se tutti i provider cloud supportano le stesse lingue. Per quanto ne so, GAE supporta Python e Java. Amazon EC2 può utilizzare praticamente qualsiasi cosa sul server stesso e Azure è una piattaforma interamente net. Pertanto, il lato dell'elaborazione reale delle cose, ovvero la scrittura del servizio Web in coda e delle unità di elaborazione potrebbe essere difficile.

Un'altra barriera è che non esiste un'API unificata comune per chiamare i servizi di cloud computing. Le implementazioni sono comunque diverse in GAE/Azure/EC2, quindi i metodi che espongono le API sono tutti diversi e, a tale scopo, il codice di prima linea dovrà conoscere il tipo di API che sta chiamando per controllare le risorse di cloud computing.

Tuttavia, per natura i servizi Web sono strettamente accoppiati. Il significato ti consente di estrapolare il controllo delle risorse in modo da poter creare un'istanza su qualsiasi cloud desideri, se la nuova istanza è un'altra unità che gestisce l'input/computazione di un servizio Web e il servizio Web esposto è lo stesso su GAE come EC2, ad esempio, non c'è nulla che impedisca ai due di parlare. Allo stesso modo, purché si utilizzi una qualche forma di servizio/protocollo web tra le istanze, si dovrebbe comunque essere in grado di parlare con altre istanze su Internet attraverso piattaforme informatiche. Detto questo, in questo modo esporresti i dati della tua applicazione interna al mondo in generale, introducendo così un rischio per la sicurezza.

Sono d'accordo con il disconoscimento: Java è un buon modo per andare. Ci sono un numero enorme di contenitori EJB là fuori e ancora più server di servizi web come Tomcat. Suppongo che EC2 lo supporti (beh, lo fa sicuramente, ma se eseguono Tomcat/Geromino piuttosto che le edizioni IBM e quali sono le accuse come non lo so). Suoni GAE limited based on this blog post - qualsiasi cosa Google stia facendo sul backend hanno progettato qualcosa di molto strano.

Answer 4

SOA è un modo perfetto per astrarre l'implementazione di un sottosistema. Finché le responsabilità del servizio sono chiaramente definite e l'interoperabilità è prioritaria, dovrebbe essere teoricamente possibile sostituire successivamente un'implementazione basata su cloud alternativa. EC2 supporta Windows in modo che l'implementazione di Azure sia altamente riutilizzabile. Tuttavia, App Engine è basato su Java/Python, il che significa che tutto ciò che può essere riutilizzato sono i tuoi contratti di messaggistica e RPC. Pertanto, un'implementazione di WCF deve essere schema-first contract-first.

quanto riguarda le prestazioni è interessato, il mio approccio standard è quello di

1. lavoro con il cliente business per definire le prestazioni accettabili,
2. implementare un prototipo di ciò che si crede di essere l'aspetto più prestazioni critiche (s) del sistema e
3. misurare le prestazioni.

Se le prestazioni non sono accettabili, diventa una decisione aziendale determinare il rischio maggiore: non essere in grado di passare a un altro provider cloud o affrontare potenziali problemi di prestazioni. Tuttavia, farei attenzione a mantenere gli standard di prestazione realistici. Per le start-up, sovradimensionare le prestazioni estreme in previsione della crescita è uno spreco di energie. IMO, questo sforzo raccoglierebbe maggiori ricompense se diretto alla differenziazione delle caratteristiche, al marketing, al feedback degli utenti, ecc. Ottimizza solo quando necessario e solo con un piano.

A proposito, vorrei anche suggerire di esaminare protocol buffers come formato di messaggistica, per prestazioni migliori a basso rischio di progetto.

Answer 5

Siamo per lo più un negozio di MS in questa fase o almeno questa è la direzione che stiamo cercando di intraprendere (convincenti ragioni di business per una start-up) ma vogliamo evitare qualsiasi lock-in. Un approccio che sto osservando è avere un framework middleware che astrae le specifiche del cloud. Il middleware comprendeva due strati primari, quello inferiore avrebbe un adattatore cloud per astrarre le sfumature e le API del cloud specifico. Lo strato superiore fornirebbe servizi quadro generali.

Il middleware avrebbe il compito di:

• utente, credenziali, ecc: deve fornire tutte le informazioni dell'utente, profili, e l'autorizzazione ecc
• Sicurezza: Dovrebbe fornire eventuali implementazioni di sicurezza e far rispettare alcuna restrizione.
• Specifiche del provider di servizi cloud: gestione di istanze e archiviazione. Misurazione dell'uso e del costo dell'utilizzo del cloud.
• Servizi di istanza: servizi di livello inferiore all'interno di un'istanza, ad es. CPU, memoria, memoria locale. Fornire l'implementazione dell'elaborazione parallela. Creazione di endpoint/porte, ecc.
• Estratto accesso al cloud storage (ad esempio tabelle, code, BLOB in azzurro).
• Configurazione dei servizi applicativi.
• Distribuzione: qualsiasi specifica richiesta per la distribuzione in un cloud: tenterebbe di automatizzare la distribuzione specifica del cloud.
• Registrazione: deve essere un framework di registrazione completo che consenta la misurazione delle prestazioni attraverso il cloud.

Commenti benvenuto.