Облачная Агностическая Архитектура?

Question

Я занимаюсь архитектурой нового решения, которое изначально будет работать в Windows Azure. Однако я бы хотел, чтобы решение (или, по крайней мере, архитектура / дизайн) было облачным (в какой-то степени реалистичным). Кто-нибудь проделал какую-либо работу в этом направлении или видел какие-нибудь хорошие документы / сообщения в блоге?

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

Стремится услышать мысли других.

Приветствие Dave

Answer 1

Я предполагаю, что под облачным агностиком вы подразумеваете независимость от конкретной платформы, на которой вы работаете, такой как GAE, Amazon EC2 или Azure, и вы хотите написать такую, развернуть где угодно.

Теоретически это должно быть возможно, если все облачные провайдеры поддерживают одни и те же языки. Насколько я знаю, GAE поддерживает Python и Java. Amazon EC2 может использовать практически все на самом сервере, а Azure является полностью .net-платформой. Таким образом, фактическая сторона обработки вещей, то есть написание веб-службы очереди и блока (ов) обработки, может быть затруднена.

Другим препятствием является то, что не существует общего унифицированного API для вызова служб облачных вычислений. В любом случае реализации в GAE / Azure / EC2 различны, поэтому все методы, предоставляемые их API, различны, и для этого вашему переднему коду необходимо будет знать, какой тип API он вызывает для управления ресурсами облачных вычислений.

Однако по своей природе веб-сервисы слабо связаны. Это означает, что при условии, что вы попытаетесь абстрагировать элемент управления ресурсами, чтобы вы могли создать экземпляр в любом облаке, которое вам нужно, если этот новый экземпляр является еще одним модулем, обрабатывающим ввод / вычисление веб-службы, и предоставляемая веб-служба такая же в GAE например, в EC2 ничто не мешает двум говорить. Точно так же, если вы используете какую-либо форму веб-службы / протокола между экземплярами, вы все равно должны иметь возможность общаться с другими экземплярами через Интернет на разных вычислительных платформах. Тем не менее, при этом вы предоставите данные своего внутреннего приложения всему миру и тем самым создадите угрозу безопасности.

Я бы согласился с отречением: Java - довольно хороший путь. Существует огромное количество EJB-контейнеров и еще больше серверов веб-служб, таких как Tomcat. Я предполагаю, что EC2 поддерживает это (ну, это определенно так, но работают ли они на Tomcat / Geromino, а не на выпусках IBM, и каковы расходы, я не знаю). GAE звучит ограничено на основе этого поста в блоге - что бы Google ни делал на бэкэнде, они разработали что-то очень странное.

Answer 2

После первоначальной публикации этого вопроса 2,5 года назад мы пришли к нашему решению. Недавно я написал пост об избежании облачной блокировки, в котором рассказывается о том, как определить облачную архитектуру. http://www.cloudycover.com/post/26549365156/avoiding-cloud-lock-in

Компания, о которой идет речь, является облачным провайдером платформы HPC, предлагающим беспрепятственную разгрузку ресурсоемких рабочих нагрузок в облако, где вам нужно платить только за миллисекунды потребляемого времени вычислений: http://www.greenbutton.com

Answer 3

На данном этапе мы в основном магазин MS или, по крайней мере, это направление, которое мы ищем (веские деловые причины для стартапа), но хотим избежать какой-либо блокировки. Один из подходов, на которые я смотрю, - это наличие инфраструктуры промежуточного программного обеспечения, которая абстрагирует специфику облака. Промежуточное программное обеспечение будет состоять из двух основных уровней, а нижний уровень будет облачным адаптером для отвода нюансов и API конкретного облака. Верхний уровень будет предоставлять общие базовые услуги.

Промежуточное программное обеспечение будет отвечать за:

• Пользователь, учетные данные и т. Д.: Должны предоставить любую пользовательскую информацию, профили, авторизацию и т. Д.
• Безопасность: должна обеспечивать любые реализации безопасности и применять любые ограничения.
• Особенности облачного провайдера: управление экземплярами и хранилищами. Измерение использования и стоимости использования облака.
• Услуги экземпляра: Услуги более низкого уровня в экземпляре, например, Процессор, память, локальное хранилище. Обеспечить реализацию параллельной обработки. Создание конечных точек / портов и т. Д.
• Абстрагировать удаленный доступ к облачному хранилищу (например, таблицы, очереди, большие двоичные объекты в лазури).
• Настройка служб приложений.
• Развертывание. Любые особенности, необходимые для развертывания в облаке, - попытка автоматизировать облачное развертывание.
• Ведение журнала: Должна быть всеобъемлющая структура ведения журнала, которая позволяет измерять производительность в облаке.

Комментарии приветствуются.

Answer 4

SOA - это прекрасный способ абстрагировать реализацию подсистемы. До тех пор, пока обязанности службы четко определены, а совместимость является приоритетной, теоретически можно будет впоследствии заменить альтернативную облачную реализацию. EC2 поддерживает Windows, поэтому реализация Azure будет многократно использоваться. Однако App Engine основан на Java / python, что означает, что все, что можно использовать повторно, это ваши сообщения и RPC-контракты. Следовательно, реализация WCF должна быть первая схема сначала контрактная .

Что касается производительности, мой стандартный подход к

1. работа с бизнес-клиентом для определения приемлемой производительности,
2. реализовать прототип того, что вы считаете наиболее критичным для производительности аспектом (ами) системы, и
3. измерение производительности.

Если производительность неприемлема, становится бизнес-решением определить больший риск: неспособность переключиться на другого облачного провайдера или решение потенциальных проблем с производительностью. Тем не менее, я был бы осторожен, чтобы сохранить стандарты производительности реалистичными. Для стартапов чрезмерное подчеркивание экстремальных показателей в ожидании роста - пустая трата усилий. ИМО, эти усилия принесут большую выгоду, если будут направлены на разграничение функций, маркетинг, обратную связь с пользователями и т. Д. Оптимизация только при необходимости и только с планом.

Кстати, я бы также предложил рассмотреть буферы протокола в качестве формата обмена сообщениями для большей производительности при низком уровне риска проекта.

Answer 5

Я бы сказал, что это довольно хороший вариант для Java Enterprise Edition. Хотя это означает, что вы застряли с Java, по крайней мере, тогда у вас будет несколько коммерческих решений для большинства описанных вами сервисов.