Миграция в облако. Перспективы и возможности российских сервисов
Еникеев
технический директор компания ITentika
Многие российские компании начинают задумываться о миграции в облако собственных программных решений, статистика от года в год показывает уверенный прирост пользователей облачной инфрастуктуры, а российский рынок облачных сервисов прогнозирует рост до 35% за этот год . В статье Роман Еникеев, технический директор компания ITentika, рассмотрит, какие нюансы стоит учесть при таком переносе и какие варианты доступны на российском рынке в 2022 году.
Облачные сервисы, если говорить о крупных публичных облаках, позволяют легко и практически мгновенно получить доступ к вычислительным ресурсам. Плюсов в этом много, помимо быстрого развертывания инфраструктурных компонент, облачные технологии позволяют автоматически или вручную регулировать количество ресурсов, для наиболее эффективного использования вычислительных мощностей (Auto-Scaling) или создавая избыточность ресурсов, для обеспечения большей отказоустойчивости системы (High Availability). Большая степень отказоустойчивости также достигается возможностью задействовать ресурсы, физически находящиеся в разных географических регионах. В сумме это позволяет компаниям разных размеров создать инфрастуктуру разрабатываемой системы доступную лишь крупным компаниям, имеющим дата центры по всей стране или даже всему миру, а также сократить расходы на поддержание и обслуживание собственного дата-центра. Стоит также отметить, что каждый поставщик услуг облачных вычислений предлагает свои уникальные решения, которые могут существенно сократить время команды разработки программного продукта на добавление новой функциональности, а быстрое развертывание новых сред разработки позволяют ускорить процесс тестирования ПО.
Шаги миграции в облако
Миграция в облако – это процесс переноса всего или части приложения и баз данных компании с собственных серверов на вычислительные ресурсы одного или нескольких поставщиков облачных служб.
Сложность миграции зависит от многих факторов: размер программного решения (количество сервисов, баз данных), количество серверов, требования к доступности и т.д. Для простого приложения с небольшим количеством пользователей, как, например, несложная внутренняя система отчетности, миграция может занять один день и большинство пользователей даже не заметят простоя; в то время как миграция всей инфрастуктуры с десятками сервисов и баз данных может является настоящим вызовом для инженерной команды. Когда мы производили одну из миграций, было использовано множество подходов, что-то было перемещено как есть, часть сервисов была существенно доработана, а что-то пришлось выкинуть и переписать с нуля.
Команда
Размер и состав команды зависит от множества факторов, но обязательными участниками миграции являются архитектор программных решений, который сможет оценить существующую систему, понять необходимость ее модификации, собрать требования по нагрузке и доступности, расставить приоритеты и подготовить план миграции, специалист DevOps (ответственен за настройку инфрастуктуры, автоматизацию развертывания и технические консультации) и дата-инженер, который сможет правильно спланировать и провести миграцию баз данных.
Бесшовная миграция
Для систем среднего и больше размера, единовременная миграция всех сервисов не самая простая задача. Перенос разумнее делать по частям, переводя один сервис за другим, в таком случае в течении определенного времени вся система полностью перейдет на облачные вычислительные мощности, сохранив полную работоспособность в течении переходного периода. Следует понимать, что не все программные решения реализованны по принципам микросервисной архитектуры, в таком случае возможно выделение части логики приложения в отдельный компонент. Единых, всегда работающих подходов к выделению сервиса из монолитного приложения не существует, поэтому для данного случая необходима помощь архитектора программных решений, который сможет проанализировать существующую системы и разбить ее на составляющие.
Миграция данных
В самом простом случае мы можем или полностью остановить работу сервиса на короткое время миграции, или, использовать чистую базу данных, в том случае когда работа сервиса не зависит от информации, хранящейся в ней (например он может восстановить нужные записи по запросу)
В тех случая когда отдельно взятый сервис не может позволить себе терять и данные и свою работоспособность даже на короткое время, необходимо продумать план миграции базы данных. Так как процесс переноса данных, а в особенности больших их объемов не атомарный, то в процессе миграции будут одновременно существовать две базы данных при все еще работающем сервисе, а значит, существует необходимость в их синхронизации. В зависимости от характера работы сервиса, потребуется либо однонаправленная либо двунаправленная синхронизация.
Миграция данных это важный и сложный этап перехода сервиса в облако, поэтому стоит уделить ему особое внимание.
Выбор поставщика облачных услуг
Лидерами в данной сфере, а также самыми популярными провайдерами являются AWS, Azure и GCP. Однако существует ряд причин по которым выбор может пасть на российских поставщиков, это в первую очередь требования к физическому размещению вычислительных мощностей (например требования Федерального закона №152 о персональных данных) в определенных регионах, или ограничения накладываемыми зарубежными провайдерами. На российском рынке существует множество поставщиков облачных сервисов, такие как Yandex.Облако, VK Cloud Solutions, SberCloud, КРОК Облачные сервисы, Tionix и другие. Да, все наши разработки пока еще уступают лидерам рынка, однако за последние несколько лет российские сервисы сильно прибавили в функциональности, удобстве пользования и надежности. А учитывая возросший спрос на отечественные платформы – по некоторым оценкам рынок российский облачных сервисов может увеличится на 30-35%, можно с уверенностью предположить, что на этом их развитие не остановится.
При выборе облачного провайдера нужно ориентироваться на множество факторов, ценовую политику, наличие использующихся в текущем проекте баз данных, оперированием которых занимается сам провайдер, наличие потенциально нужных сервисов, аналогов которым нет у других поставщиков облачных вычислений. Стоит также оценить имеющиеся лимиты на оперативную память, размер жесткого диска, пропускную способность сети, максимально доступное количество процессоров и других параметров, возможно определенный поставщик облачных услуг просто не способен выдержать требования мигрируемой системы.
В самом общем случае от провайдера требуется только возможность создания виртуальных машин, ведь всю существующую инфрастуктуру можно установить прямо на них, однако многие облачные провайдеры предоставляют управляемые сервисы. К примеру, Яндекс.Облако имеет сервис управляемой базой данных PostgreSQL, это значит, что задачи по развертыванию, базовому мониторингу и созданию резервных копий лежит на самом провайдере, что позволяет сократить время команды миграции сервиса, конечно при том условии, что поставщик облачных услуг поддерживает необходимый тип и версию базы данных.
Отдельно стоит упомянуть собственные проприетарные сервисы, которые предоставляют облачные провайдеры. Это могут быть как собственные системы баз данных (как SQL, так и NoSQL), так и сервисы машинного обучения, компьютерного зрения, распознавания речи и многие другие. Все эти сервисы могут быть полезны существующему программному решению как в будущем, так и в настоящем, так как способны заменить часть существующих компонент после их интеграции, что может повысить их производительность или качество работы. Также все чаще встречаются бессерверные решения, которые позволяют переложить задачи по конфигурации, планированию мощностей, реализации отказоустойчивости, на поставщика облачных услуг. Однако стоит помнить, что в данном случае с каждым новым подобным сервисом увеличивается степень привязки к поставщику (Vendor lock-in), что может усложнить переход от одного облачного провайдера к другому.
Выбор поставщика облачных услуг и его сервисов это всегда компромисс между скоростью миграции и гибкостью или портативностью инфрастуктуры программного решения. Чтобы суммировать вышесказанное, можно составить краткий список основных критериев при выборе провайдера: используемый аппаратный комплекс, ключевые параметры производительности, расположение дата центров, надежность и уровни поддержки и имеющийся бюджет.
Миграция существующих программных решений это всегда индивидуальный подход. Команда должна принять взвешенное решение при выборе облачного провайдера, плана миграции и необходимости доработки и модернизации частей существующего решения, а также профессионально и качественно исполнить перемещение сервисов. Хорошо, если в штате есть специалисты способные проделать данную работу, но если таких нет, можно обратиться к специалистам компании ITentika, которая может предоставить экспертизу на каждом этапе миграции.
ITentika – российский разработчик программного обеспечения, входит в N3 group. У команды ITentika многолетний опыт разработки для ведущих мировых компаний, экспертиза в создании сложных информационных систем и продуктов для лидеров финансовой сферы, ритейла и электронной коммерции, транспорта и логистики, здравоохранения, промышленности и других отраслей.
