Самой большой проблемой, с которой я столкнулся, были местные запасные варианты.В типичном облачном сценарии вы перемещаете свои ресурсы, которые когда-то жили в традиционном хранилище данных (база данных, файловая система и т. Д.), Во что-то за API, которое вы не можете легко скопировать локально.Для нашего приложения мы переместили несколько типичных очередей из MySQL в SQS Amazon.Проблемы:
В настоящее время Amazon взимает 0,01 доллара США за 10 000 запросов SQS, стоимость, которая может показаться очень маленькой, но нет абсолютно никакой причины платить при локальной разработке (или за ваш тестовый сервер, если предположить, что выесть отдельная).
Если у вас нет резервной локальной очереди, вам нужна отдельная очередь для среды разработки / тестирования.Вы действительно не хотите, чтобы сообщения из разных очередей перепутывались.
Не существует простого способа локального эмуляции SQS для нашей среды (о котором я знаю).
В архитектурном плане я имел дело с переходом на SQS с помощью простых адаптеров :
- Абстрактный адаптер, который выполнял большую часть работы,с абстрактными функциями для конкретного хранилища,
- Адаптер SQS, который унаследовал абстрактный адаптер, и использующий SQS SDK,
- Адаптер MySQL, который был более или менее точно таким же, каким был раньше,
- фабричный метод , который создавал модели Queue, решал, какой адаптер использовать, подал его на модели.
Та же архитектура (более или менее) работаладовольно хорошо, когда мы переместили наши изображения в S3 , с локальным резервом файловой системы.Простой, маленький и достаточно простой для объяснения, и, что более важно, он работает.Если вы переносите приложение в облако, скорее всего, вы будете писать довольно много адаптеров для своих серверных сервисов, кроме простого резервного механизма, вы не хотите, чтобы поставщик был привязан к конкретной услуге.
Очевидно, что если вы создаете приложение с учетом облака, вам может не потребоваться локальный запасной вариант, особенно если ваша платформа имеет простой способ эмуляции облачной среды.Что-то вроде Stratosphere , если вы разрабатываете на .Net / Mono или нацеливаетесь на сервисы Amazon.Но если у вас есть зрелое приложение, у вас уже есть локально настроенная инфраструктура, продолжать использовать ее имеет смысл.
Облачные «накладные расходы» - это не то, о чем вам нужно беспокоиться, если вы используетеОблако как модное хранилище данных.Но если вы ищете облачные вычисления, то ответа нет, это всегда зависит от того, что именно вы делаете.
Несколько важных вопросов: