Когда отношения с техническим обслуживанием не складываются

Учебники
AWS

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

Жизнь была потрясающей… пока не стала такой.

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

Верите или нет, наши отношения с технологиями не так уж и отличаются.

Разрыв с сервисом

Был момент, когда вы решили воспользоваться каким-то сервисом — возможно, это был SaaS, PaaS или что-то более общее. В те времена вы принимали решение, не задумываясь о том, когда вы больше не планируете использовать этот сервис? Вероятно, нет. Вы просто думали о всех замечательных возможностях для будущего.

Но что происходит, когда использование этого сервиса больше не в ваших интересах? Теперь вас ждет вызов, который называется отказ от сервиса. Хотя сервисы можно отключить с разумными усилиями, получение базовых данных может быть проблематичным. Это часто зависит от типа сервиса и объема данных, принадлежащих этому поставщику услуг.

Иногда идеальный процесс разрыва выглядит так: прекратите платить за сервис, но сохраните доступ к источнику данных на некоторое время. Это вообще возможно? Да, возможно!

Сила VPC Peering

Ведущие облачные поставщики приняли виртуальную частную сеть (VPC) как фактический подход к установлению связи между ресурсами. Например, экземпляр EC2 на AWS может получить доступ к источнику данных, используя VPC и услуги конечных точек VPC. Можно представить это как точечное соединение.

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

Этот концепт называется сопряжением VPC и позволяет установить частное соединение из другой сети.

Пример миграции сервиса

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

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

Вот как будет выглядеть новое соглашение:

VPC-пиаринг с Heroku

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

Затем вам нужно будет выполнить следующие простые сетевые требования:

  • Виртуальная частная сеть должна использовать совместимый блок IPv4 CIDR в своей конфигурации сети.
  • Виртуальная частная сеть должна использовать блок CIDR RFC1918 (10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16).
  • Блок CIDR виртуальной частной сети не должен пересекаться с диапазонами CIDR для вашего Частного пространства. Стандартные диапазоны: 10.0.0.0/16, 10.1.0.0/16 и 172.17.0.0/16. 

После запуска вашего Частного пространства вам нужно будет получить информацию о его пиринге:

Shell

 

Запишите ID аккаунта AWS (647xxxxxx317) и ID VPC AWS (vpc-e285ab73). Вам нужно будет предоставить эту информацию стороннему поставщику, который контролирует источник данных AWS. Оттуда они могут использовать либо консоль AWS, либо CLI для создания соединения пиринга. Их операция будет выглядеть примерно так:

Shell

 

Это создает запрос на пиринг. Как только поставщик это сделает, вы сможете увидеть ожидающий запрос на стороне Heroku:

Shell

 

На скриншоте ниже мы можем видеть статус ожидания акцепта для соединения пиринга.

Отсюда вы можете принять запрос на соединение пиринга:

Shell

 

Мы проверяем статус запроса во второй раз:

Shell

 

Мы видим, что соединение пиринга активно.

На этом этапе приложение, работающее в нашем частном пространстве Heroku, сможет получить доступ к источнику данных AWS без каких-либо проблем.

Заключение

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

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

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

Такой подход позволит вашему новому сервису развиваться без перерыва в обслуживании потребителей.

Source:
https://dzone.com/articles/when-tech-service-relationships-dont-work-out