Strategie architettoniche per ridurre al minimo il rischio di lock-in del cloud?

Question

Vorrei capire qual è il modo migliore per ridurre il rischio di blocco del fornitore per i sistemi basati su cloud.

Ad esempio, mi piacerebbe distribuire una moltitudine di sistemi diversi, ad esempio, Amazon EC2 o Windows Azure, ma vorrei ridurre al minimo il costo della migrazione di tali sistemi a un fornitore di cloud alternativo se/quando necessario .

Per lo meno, sembra che più mi affido a soluzioni specifiche del fornitore (come Amazon Queue Service), più sono intrinsecamente bloccato (almeno penso di sì), ma mi piacerebbe capire meglio questo rischio e oltre.

Esistono strategie architettoniche che posso utilizzare per attenuare questo problema (ad esempio, fare affidamento sulla riduzione della mappa, poiché i miei script saranno trasferibili su un'altra mappa per ridurre l'env del cloud)? Ci sono O/S o stack che sono migliori di altri (Linux, LAMP?). Usare JClouds è utile?

Idealmente, mi piacerebbe progettare sistemi virtuali che possono essere distribuiti su EC2, ad esempio, ma poi facilmente migrati ad Azure o App Engine (o viceversa).

Scrivo generalmente in Java, ma sto considerando l'utilizzo selettivo di Scala e Python (o Jython) e in genere sto ancora cercando di rimanere basato su JVM. Tendo a fare molta elaborazione parallela e mi affido alle tecnologie di archiviazione e di manipolazione dei dati sia SQL che non SQL (ma non necessario NoSQL).

Grazie in anticipo. Spero di non essere troppo irrealistico qui.

Answer 1

A mio parere, l'unico modello architettonico per il problema che si descrive è: l'astrazione

Assicurati di attenersi a utilizzare le risorse che vengono offerti attraverso vari fornitori, come lo stoccaggio, code, ecc Creare livelli di astrazione per ogni di loro.

Spero che questo aiuti. Non penso che sia un compito molto semplice da fare, data la variabilità dei servizi tra i cloud provider

Answer 2

Sono d'accordo con IgoreK: se lo stai facendo in codice, ci vorrà molta astrazione, questo è a proposito.

Un'altra opzione è adottare un approccio cloud IaaS: progettare l'applicazione in base solo ai ruoli della macchina virtuale. La maggior parte dei provider Cloud offre una qualche forma di ruolo della macchina virtuale: Amazon, Azure, Rackspace, ecc. La migrazione implica quindi molte meno modifiche al codice, ma un po 'più di amministratore dalla tua parte.

Answer 3

Onestamente, la tua domanda si basa su una premessa errata. Stai cercando di evitare il lock-in piuttosto che cercare di sfruttare appieno la piattaforma che hai scelto di utilizzare.

Il modo migliore di affrontare il problema non è quello di cercare di avere l'infrastruttura sia hot-swap (ad esempio, evitare il vendor lock-in), ma in realtà prendere una decisione sul provider IaaS che si desidera utilizzare e sfruttalo nel miglior modo possibile.

Answer 4

Il team di consulenza clienti di Microsoft ha un eccellente sample on how to do that (penso di aver scaricato il progetto da qui). C'è un sacco di codice e alcune astrazioni davvero buone per rendere le cose "libere". Ovviamente, come con qualsiasi astrazione, introduci anche un nuovo livello di complessità, quindi assicurati di averlo veramente tutto prima di applicarlo.

Nella maggior parte dei casi, meno è di più.E anche se un lock non è qualcosa che si desidera, probabilmente non è così difficile da "risolvere" se si presenta la necessità. Ma chiedi a te stesso se è importante per il bisogno di essere soddisfatto ora, o se dovessi terminare il progetto, e il refactoring più tardi.