Назад | Перейти на главную страницу

могут ли две облачные инфраструктуры соединяться

Я хочу использовать движок приложений, но, к сожалению, они не поддерживают свои пространственные запросы к БД, поэтому мне было интересно, есть ли способ создать свою БД в одном облаке, AWS или Azure, и мой бэкэнд на движке приложений.

если это возможно:

  1. как лучше всего это сделать?
  2. каковы будут последствия для производительности?
  3. лучше ли разместить все мое решение в одном облаке?

могут ли две облачные инфраструктуры соединяться

Если предположить, что ваше определение «соединения» состоит в том, что два облака могут маршрутизировать IP-трафик между собой, тогда в подавляющем большинстве случаев ответ будет: да, конечно.

Однако простое IP-соединение не обеспечивает стабильной инфраструктуры.

как лучше всего это сделать?

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

«Лучшая практика» здесь не применима, поскольку существует миллион способов создания многооблачных распределенных развертываний. Короче говоря, это полностью зависит от вашего конкретного приложения.

каковы будут последствия для производительности?

Что ж, производительность запросов к базе данных будет какой ужас.

лучше ли разместить все мое решение в одном облаке?

Опять же, это полностью субъективно. Зависит от ваших потребностей и архитектуры вашего приложения.


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

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

Я вижу несколько вещей, о которых нужно подумать при разделении приложения на несколько облаков (или между облаком и локальной средой):

  • Задержка. Если для ваших сервисов требуется предсказуемая (и низкая) задержка, вы можете обнаружить, что эти типы сервисов должны быть совмещены. После того, как вы покинете сеть одного облачного провайдера, вы перейдете через общедоступный Интернет к другому облаку (или локальному объекту). Эта задержка может быть больше, чем может выдержать ваше приложение.
  • Затраты на пропускную способность. Например, с Azure и AWS у вас есть бесплатные входящие данные, но вы платите за исходящие. Вероятно, вы увидите довольно доступные затраты в одном направлении (например, запросы к базе данных) и более высокие затраты на пропускную способность в другом (полезные данные).
  • Обслуживание. У каждого облачного провайдера есть собственная модель и API для обслуживания приложений / виртуальных машин / баз данных. Это необходимо учитывать в вашей среде DevOps. То же самое для подходов к резервному копированию.
  • Безопасность. Как и при подключении к локальным ресурсам, вам нужно подумать о подключении между облаками (можете ли вы создать безопасный туннель или использовать SSL?) И управлении доступом (можете ли вы защитить конечные точки серверных служб, такие как база данных и кеш?).
  • Высокая доступность / аварийное восстановление. Каждый облачный провайдер будет предлагать определенные варианты HA и DR для своих услуг (и ваших). Вам нужно будет внимательно рассмотреть каждый из них.

Я уверен, что есть и другие вещи, которые следует учитывать - надеюсь, этот список поможет.

Итог: гибридные архитектуры (облачные <--> локальные, облачные <--> облачные) существуют сегодня, и ваши конкретные требования помогут вам определить, подойдет ли это для вас.