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

Question

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

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

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

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

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

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

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

Answer 1

На мой взгляд, единственная архитектурная схема проблемы, которую вы описываете: абстракция

Обязательно придерживайтесь ресурсов, предлагаемых различными поставщиками, таких как хранилище, очередь и т. Д. Создайте слои абстракции для каждого из них.

Надеюсь, это поможет. Я не думаю, что это очень простая задача, учитывая изменчивость услуг у разных облачных провайдеров

Answer 2

Я согласен с IgoreK - если вы делаете это в коде, потребуется много абстракций, вот и все.

Другой вариант заключается в использовании облачного подхода IaaS - проектируйте свое приложение только на основе ролей виртуальной машины.Большинство провайдеров облачных услуг предлагают ту или иную форму роли виртуальной машины - Amazon, Azure, Rackspace и т. Д. В этом случае миграция означает гораздо меньше изменений кода, но немного больше администраторов на вашей стороне.

Answer 3

Служба поддержки клиентов Microsoft имеет превосходный пример того, как это сделать (я думаю, что я скачал проект отсюда). В нем много кода и несколько действительно хороших абстракций, чтобы сделать вещи «свободными». Очевидно, что, как и в случае любой абстракции, вы также вводите новый уровень сложности, поэтому убедитесь, что вы действительно все перед тем, как применять его.

В большинстве случаев чем меньше, тем больше. И даже если lock-in - это не то, что вам нужно, вероятно, его не так сложно «исправить», если возникнет такая необходимость. Но спросите себя, важно ли это для того, чтобы это было удовлетворено сейчас, или вы должны закончить проект, а рефакторинг позже.

Answer 4

Честно говоря, ваш вопрос основан на некоторой ложной предпосылке. Вы пытаетесь избежать блокировки, а не пытаетесь в полной мере использовать платформу, которую вы выбрали для использования.

Лучший способ решения этой проблемы - не пытаться обеспечить горячую замену вашей инфраструктуры (например, избегать привязки к поставщику), а на самом деле принять решение о нужном поставщике IaaS использовать и использовать его как можно лучше.