[Перевод] Неудачные архитектурные решения при миграции в облако
Всем привет! Перевели для вас статью создателя сообщества 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: отсутствие переоценки существующей архитектуры
Если в традиционных центрах обработки данных мы проектировали архитектуру приложения и сохраняли ее статичной на протяжении всего жизненного цикла приложения, то при разработке современных приложений в облаке мы должны придерживаться динамического мышления. Это значит, что нужно постоянно пересматривать архитектуру, анализировать прошлые решения и смотреть, могут ли новые технологии или новые сервисы предоставить более подходящие решения для работы приложения.
Динамичная природа облака в сочетании с развивающимися технологиями дает нам возможность вносить изменения и находить лучшие способы запускать приложения быстрее, устойчивее и экономичнее.
Ошибка 8: предвзятые архитектурные решения
Это ловушка, в которую попадают многие архитекторы. Имея опыт работы с определенным облачным провайдером, они проектируют архитектуру на основе его экосистемы, таким образом принимая предвзятые решения, которые создают ограничения в дизайне архитектуры.
Вместо этого архитекторы должны полностью понимать потребности бизнеса, весь спектр on-cloud решений, траты на обслуживание и возможные ограничения. Только после этого они могут начать выбирать наиболее подходящие сервисы, которые станут частью архитектуры приложения.
Ошибка 9: отсутствие финансового планирования при принятии архитектурных решений
Стоимость является важнейшим фактором при использовании облачных сервисов. Основное для пользователя возможность потреблять сервисы именно по требованию (и/или перестать платить за неиспользованные сервисы).
Каждое принимаемое вами решение влияет на стоимость. Вы сможете оценить потенциальные расходы только тогда, когда вы будете понимать модели ценообразования каждого сервиса и осознавать потенциальный рост вашей рабочей нагрузки.
Как мы упоминали ранее, динамичный характер облака может приводить к изменению затрат каждый месяц. Поэтому важно регулярно пересматривать стоимость, периодически заменять сервисы и корректировать их под конкретные рабочие нагрузки.
В сухом остатке
В публичном облаке существует множество проблем, связанных с выбором правильных сервисов и архитектур для удовлетворения конкретных требований к рабочим нагрузкам и сценариям использования.
Да, при проектировании архитектуры не существует единственно верного решения. Но в этой статье мы увидели множество «неудачных», которых можно избежать, если смотреть на картину в целом и проектировать на долгосрочную перспективу.
Рекомендация для читателей статьи: продолжайте расширять свои знания в области облачных технологий и архитектуры. Советуем регулярно пересматривать свои текущие решения, чтобы со временем выяснить, есть ли более подходящие для них альтернативы.
_____
Спасибо, что прочитали наш перевод! Вот ещё несколько полезных ссылок по теме:
