Архитектурные стратегии для минимизации риска привязки к облаку?

Я хотел бы понять, как лучше всего снизить риск привязки к поставщику для облачных систем .

Например, я хотел бы развернуть множество различных систем, например, Amazon EC2 или Windows Azure, но я хотел бы минимизировать затраты на перенос этих систем к альтернативному поставщику облачных услуг, если / когда это необходимо.

По крайней мере, кажется, что чем больше я полагаюсь на решения конкретных поставщиков (например, Amazon Queue Service), тем больше я заперт (по крайней мере, я так думаю), но я хотел бы понять этот риск лучше и выше.

Существуют ли архитектурные стратегии, которые я могу использовать для смягчения этого (например, полагаться на map reduce, поскольку мои сценарии будут переносимы на другую карту, reduce cloud env)? Есть ли операционная система или стеки, которые лучше других (Linux, LAMP?). Полезно ли использование JCloud?

В идеале я хотел бы разработать виртуальные системы, которые можно было бы развернуть, например, на EC2, но затем легко перенести на Azure или App Engine (или наоборот).

Обычно я пишу на Джава, но я рассматриваю выборочное использование Scala и Python (или Jython) и в целом все еще пытаюсь оставаться на основе JVM. Я обычно много выполняю параллельную обработку и полагаюсь на технологии хранения и обработки данных как на SQL, так и не на SQL (но не обязательно на NoSQL).

Заранее спасибо. Надеюсь, я здесь не слишком нереалистичен.

9
задан kvista 8 January 2011 в 06:20
поделиться