Неудачные архитектурные решения при миграции в облако

Всем привет! Перевели для вас статью создателя сообщества AWS Эяля Эстрина о наболевшем — о неудачных решениях при миграции в облако. Стоит отметить, что Эяль описывает собственный профессиональный опыт, и некоторые его утверждения могут показаться вам спорными. Если так и случилось — давайте обсудим в комментариях.

Полезного чтения! 

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

В этой статье мы обсудим наиболее распространённые ошибки в архитектуре при миграции в облако.

Ошибка 1: выбор Lift-and-Shift

Подход Lift-and-Shift подразумевает ускоренный перенос приложения или инфраструктуры из локальной среды в облако без каких-то изменений в коде или архитектуре. Lift-and-Shift позволяет сохранить логику и данные, находящиеся в локальном оборудовании. 

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

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

Подход lift-and-shift хорош в качестве промежуточного решения, пока у компании нет времени и ресурсов на реорганизацию рабочей нагрузки и выбор другой архитектуры, например, микросервисной и бессервисной. Однако если взглянуть на эту стратегию с точки зрения долгосрочной перспективы, то мы увидим, что это довольно затратное решение, которое не позволит использовать все возможности облачных сервисов. К примеру, будут недоступны горизонтальное масштабирование, масштабирование до нуля, отказоустойчивость управляемых сервисов и многие другие).

Ошибка 2: использование Kubernetes для небольших или простых рабочих нагрузок

При разработке современных приложений организации чаще всего стараются следовать тенденциям своей сферы. Один из самых ярких трендов — выбор контейнеров для развертывания различных компонентов приложений. И во многих случаях компании в качестве оркестратора контейнеров выбирают Kubernetes.

Несмотря на многочисленные преимущества Kubernetes и наличие сервисов для управления им у всех ведущих облачных провайдеров, с его использованием связано немало трудностей.

Чтобы полностью понять, как настраивать и обслуживать Kubernetes, требуется очень много времени. Для небольших или предсказуемых приложений, созданных из небольшого числа различных контейнеров, существуют более эффективные и простые в развертывании и обслуживании альтернативы, такие как Amazon ECS, Azure Container Apps или Google Cloud Run. Они проще в освоении и вполне могут справляться с небольшими рабочими нагрузками.

Ошибка 3: использование облачного хранилища для сценариев резервного копирования или аварийного восстановления

Когда организации начинают искать первые варианты использования публичного облака, они сразу же думают о нём как о месте резервного копирования или даже DR (Disaster Recovery (DR) — это стратегия быстрого восстановление инфраструктуры, приложений и данных после серьёзного сбоя). Эти варианты допустимы, но они не учитывают общую картину. 

Если мы планируем использовать объектное хранилище или управляемые службы хранения NFS/CIFS для бэкапов, то мы должны задуматься об этапе восстановления. Перенос больших двоичных файлов резервных копий из облачной среды обратно в локальную будет занимать много времени, не говоря уже о стоимости данных на выходе, вызовов API для чтения объектов и многого другого.

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

Ошибка 4: разделение между приложениями и внутренними уровнями хранилищ данных

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

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

За исключением случаев, когда целевое приложение не подвержено задержкам в сети, всегда рекомендуется проектировать все компоненты близко друг к другу, чтобы уменьшить задержку в сети между ними. 

Ошибка 5: переход на мультиоблачные технологии в надежде избежать риска привязки к поставщику

Многие компании рискуют оказаться в ситуации вендор локин (vendor lock-in), когда клиенты конкретного поставщика облачных услуг становятся привязаны к его экосистеме. Главная проблема вендор локин — это стоимость перехода от одного облачного провайдера к другому.

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

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

Ошибка 6: выбор самого дешёвого региона в облаке

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

Если ваше приложение обслуживает клиентов по всему миру или в нескольких регионах, рассмотрите возможность добавления CDN (Content Delivery Network — это географически распределённая сетевая инфраструктура, обеспечивающая быструю доставку контента пользователям веб-сервисов и сайтов) в сочетании с мультирегиональными решениями (например, межрегиональной репликацией, глобальными базами данных, глобальными балансировщиками нагрузки и т. д.), чтобы держать весь статический контент поближе к клиентам.

Ошибка 7: отсутствие переоценки существующей архитектуры

Если в традиционных центрах обработки данных мы проектировали архитектуру приложения и сохраняли ее статичной на протяжении всего жизненного цикла приложения, то при разработке современных приложений в облаке мы должны придерживаться динамического мышления ^[1]. Это значит, что нужно постоянно пересматривать архитектуру, анализировать прошлые решения и смотреть, могут ли новые технологии или новые сервисы предоставить более подходящие решения для работы приложения.

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

Ошибка 8: предвзятые архитектурные решения

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

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

Ошибка 9: отсутствие финансового планирования при принятии архитектурных решений

Стоимость является важнейшим фактором при использовании облачных сервисов. Основное для пользователя возможность потреблять сервисы именно по требованию (и/или перестать платить за неиспользованные сервисы).

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

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

В сухом остатке

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

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

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

_____

Спасибо, что прочитали наш перевод! Вот ещё несколько полезных ссылок по теме: 

• Оптимизируем затраты на облако: 4 лучшие практики FinOps; ^[2]

• Чек-лист по разработке облачных приложений (в двух частях); ^[3]

• Видео: Облако vs on-premise: что выбрать для надёжного бизнеса? (YouTube ^[4], RuTube ^[5], VK Video ^[6])