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

Я полагаю, что под агностиком облака вы подразумеваете независимость от конкретной платформы, на которой вы работаете, например 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 ни делал на бэкэнде, они спроектировали что-то очень странное.

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

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

Промежуточное ПО будет отвечать за:

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

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

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

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

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

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

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