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

Question

Я только что закончил рассматривать этот вопрос: https://stackoverflow.com/questions/753122/which-cloud-computing-platform-should-i-choose

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

Итак, если мое приложение написано на ASP.NET, используя SQL Server, казалось бы, что лучше всего делать дизайн для Azure, но будет ли решение Amazon хорошим выбором?Как бы мне решить, должен ли я просто иметь все в той же системе или есть данные на облаке Amazon и ASP.NET в Azure?

У меня есть еще одно приложение, над которым я работаю, которое имеет дело с информацией о коммунальных услугах, о воде и электричестве, поэтому там есть информация об использовании и выставлении счетов, и оно было написано на PHP с использованием SQL Server.Возможно, это было бы хорошим приложением для облачных вычислений?Казалось бы, решение Amazon было бы лучшим решением для PHP, так что это мой единственный вариант, но как вы решаете, какие части их предложений использовать?

В основном мой вопрос касается архитектуры приложения.Проектирование для хостинга несложно, но облачные вычисления создают новые проблемы.

Моя главная забота связана исключительно с дизайном моего приложения.

Если я выберу язык, запрет ли это меня в облачном решении?

Когда я хотел бы, чтобы база данных находилась в другом облаке, чем приложение?

Если я захочу использовать фреймворк LIFT (написанный на Scala), позволит ли мне кто-нибудь из них установить все, что мне нужно?

Answer 1

Мы запускаем довольно крупный SaaS-сервис финансовых услуг на Amazon AWS.

Здесь речь идет о двух общих проблемах:Архитектура приложений и сервисы облачной платформы.

Я обнаружил, что архитектура нашего приложения по сути такая же, как была бы, если бы мы развертывали его на собственных виртуальных машинах или реальном оборудовании.Мы создали довольно стандартное n-уровневое приложение, используя в основном инструменты с открытым исходным кодом (Java, Spring, Hibernate, MySQL, Terracotta, ...).Есть некоторые соображения, когда речь заходит о высокодоступной / устойчивой к ошибкам базе данных (поскольку аппаратные опции недоступны), но в остальном мы на самом деле не "нацелены" на конкретную облачную реализацию.

Сервисы облачной платформы - это совершенно другое дело.Под этим я подразумеваю такие вещи, как:

• Запуск / Остановка / Мониторинг / Управление / Масштабирование экземпляров
• Доступность / Избыточность (например,У Amazon есть Зоны доступности)
• Развертывание / Инициализация / Настройка экземпляров
• Резервное копирование / восстановление файлов
• Безопасность (например,управление брандмауэром)

В этой области практически нет стандартизации, хотя это область, представляющая активный интерес.

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

Что касается разделения презентации и базы данных между разными поставщиками, я бы не стал предлагать это, потому что:

• Если какой-либо из поставщиков выйдет из строя, вам конец
• Передача данных через Интернет происходит медленнее, дороже и менее безопасно, чем передача данных внутри одного облачного провайдера.

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

Как правило, вы можете установить на свои виртуальные серверы любое программное обеспечение, которое вам нравится, хотя у меня нет особого опыта работы с Azure.Если вы используете AWS или аналогичные сервисы, установка LIFT не составит проблемы.

Answer 2

Выбор языка не блокирует вас в качестве поставщика; Тем не менее, проектирование для запуска на Windows делает. Виртуализация Windows - гораздо более узкий рынок, чем виртуализация Linux; Xen, технология Linode, Slicehost и т. Д., Не будет виртуализировать Windows более одного раза.

С учетом того, что ваши приложения предназначены для Windows, ваш выбор значительно меньше. На моем рынке я знаю, что Amazon обслуживает Windows (как и Azure, очевидно). Однако более рентабельные решения, такие как наши и Slicehost, не подойдут - Windows обойдется вам дороже.

Что касается облачной сегрегации: основная причина сегментировать ваше приложение в несколько «облаков» это обеспечить надежность приложения. Облака спускаются - правда, редко - и хранение всех ваших яиц в одной корзине обойдется вам в приложение, которое требует высокой доступности. Однако, если ваша база данных находится в отдельном облаке от вашего приложения, вы будете страдать от задержек при выполнении SQL через Интернет (плюс потребуется некоторая архитектура для защиты этого трафика, например SSH-туннель или шифрование на уровне протокола, которое может предложить SQL Server). [не совсем уверен, я парень из PostgreSQL]).

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

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

Answer 3

Это рассвет "облачных вычислений" и, как и в случае с любым подобным, участники ставят " мышиные ловушки " в надежде поймать как можно больше. Пройдет некоторое время, прежде чем игроки придут к определению точки соприкосновения (то есть стандартов той или иной формы) и до тех пор, пока их оружие не станет «дифференцированным». заставит нас выбирать стороны.

Я полагаю, это слишком "ориентировано на бизнес" и за него проголосуют ... но, эй, я думаю о бизнес-аспектах до технологии / языка. В конце концов, все сводится к зарабатыванию денег.

Если кто-то подумает о том, что не заблокирован для поставщика облачных вычислений (типы SaaS / PaaS, в то время как производители типа IaaS находятся дальше), то в начале игры вам придется большие сюрпризы. Огонь прочь!

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: я не представляю поставщика облачных вычислений любого типа (SaaS, PaaS, IaaS). Будут ли люди, которые проголосовали за меня, заботиться о своей преданности?