Почти два года исполнилось с момента, когда SolbegSoft начала переход с Amazon Cloud на Microsoft Azure. Зачем меняли провайдера, какие варианты миграции есть, как переезжать при постоянной активности системы?
Подробностями поделился Антон, Head of Solution Architect компании.
Почти два года исполнилось с момента, когда SolbegSoft начала переход с Amazon Cloud на Microsoft Azure. Зачем меняли провайдера, какие варианты миграции есть, как переезжать при постоянной активности системы?
Подробностями поделился Антон, Head of Solution Architect компании.
К этому решению подтолкнула необходимость сокращения издержек и расходов. Сюда же отнесу end-user пожелания клиента. Наконец, у нас майкрософтовский .NET-стек, который не всегда слаженно работает с Amazon Cloud. Поэтому мы решили мигрировать, что называется, в родную гавань.
От идеи до завершения работ по первой фазе прошло восемь месяцев. Событие коснулось всей группы engineering.
Основная команда, которая принимала решения, состояла из VP of DevOps, троих DevOps инженеров, Solution Architect, System Architect, DBA, двоих QA-инженеров. Кроме того, код также требовал изменений, поэтому, по сути, весь engineering слаженно трудился над проектом.
Начали действовать в мае 2019 года. Процесс давался нелегко. Нужно было перенести порядка 140 приложений. Также из-за того, что клиенты используют решения SolbegSoft, у них срабатывали firewalls, которые запрещали доступ.
Инфраструктура состояла из фермы виртуальных машин, SQL Master и SQL Replication Cluster. Мы продумывали разные стратегии. Даже слетали в Сиэттл, в штаб-квартиру Microsoft. Технические и бизнес-специалисты компании нас проконсультировали и подобрали оптимальный подход для перехода на новую платформу.
Всего их три:
Команда изучила best practices, получила рекомендации, но в итоге сама выбрала, на чем остановиться. Microsoft предложили реплатформинг. Мы же решили сделать lift and shift, плавно переходящий в рефакторинг. Такой вариант занимал меньше времени.
Миграция продолжается до сих пор. Сейчас идет адаптация решений под сервисы Cloud Native.
Главным ограничителем была и остается постоянная активность системы. Мы не можем ее надолго остановить. Поэтому у нас есть небольшое maintenance-окно продолжительностью до 4-х часов. За это короткое время мы должны сделать максимум возможного.
Чтобы точно уложиться, мы тренировались с секундомером. Расписывали, кто и что делает. Затем делали тестовый прогон и специальный человек замерял, сколько времени это займет. К моменту миграции команда была натренирована слаженно работать в таких стрессовых условиях.
Для мониторинга сформировали три команды. Каждая из них состояла из 2-х представителей каждого из отделов: QA, DevOps, Development, Architect, Support. В момент миграции и первый рабочий день после нее был организован длительный звонок. Далее каждый день были контрольные созвоны по расписанию и постоянный контроль и мониторинг работы системы с различных ракурсов. Несколько дней команды сменяли друг друга, круглосуточно следили за работой системы, делали фиксы на горячую.
Основная боль была связана с кластером MS SQL. Не так-то просто ее перенести за эти пару часов. Если делать backup и restore, то времени вообще не хватит. А таких баз порядка 10 штук. Поэтому было принято решение создать и использовать transaction log replication. Это позволило нам без негативного эффекта на текущую систему асинхронно мигрировать базу данных. Для реализации построили VPN — туннель между двумя облаками с двойным резервированием. Так мы подняли виртуальные машины в Azure и настроили туда SQL-репликацию. Этот подход позволил нам в момент миграции остановить все write-операции в мастер базу, зареплицировать все in-flight transactions, и переключить мастер базу на новую — Azure hosted. Для того, чтобы иметь rollback план без потери каких-либо данных клиентов, мы меняли направление реплицирования между облаками. Web portal, который состоит из множества web applications разворачивали преимущественно как есть, в соответствии с концепцией lift and shift. Изменения коснулись только конфигурирования приложений.
Пришлось повозиться с CI/CD и сделать серьезный рефакторинг. Проблема была в том что сборки приложения — пакеты, которые получались на выходе, были ориентированы под конкретные environment, а все конфиги содержали финальные настройки. Перекинуть с одного на другой без глубокой переработки было невозможно. Плюс у клиента было 10 таких environment. И всех их нужно было перенести. Мы сделали разделение процесса разворачивания на две части:
В итоге мы сделали конфигурацию шаблонной, пакеты стали независимыми. Во время deployment подставлялись нужные конфигурации. Теперь любой пакет можно было развернуть на любой environment и задать нужные параметры.
Сложности возникали и на этапе тестирования. Так как мы построили параллельный продакшн, нужно было протестировать email-сервисы, инфраструктуру и при этом не отослать письма реальным пользователям с невалидной информацией. Для этого искали так называемые «сервисы-затычки», которые изолируют систему и дадут возможность провести полноценные тесты.
Дедлайна по переезду нет. Мы находимся в состоянии перманентной миграции. Lift and shift завершена. Сейчас занимаемся миграцией web applications части на Azure Web App Services (Azure Cloud Native Service). Впереди еще работа с масштабированием базы данных.
Однако то, что уже сделано, открыло возможность команде engineering использовать новые сервисы: Azure Functions, Web App Services, Table Storage, Blob Storage, CosmosDB, Redis Cluster, Azure Service Bus и другие Azure Cloud Native сервисы.
Для решения проблемы с firewall мы временно перешли на туннелинг. Для этого оставили точки входа на AWS. Это Application Load Balancer, когда в браузере пишется линк, происходит соединение с Amazon balancer. Через VPN-туннель он направляет запрос уже в другое облако. Назад тем же путем. В перспективе мы хотим избавиться от решения, потому что это не лучшее с точки зрения безопасности и экономичности.
Наши .NET-разработчики помогали перенести данные с сервиса File Storage S3 от Amazon на Azure Blob Storage. Сейчас находимся в стадии переезда приложений с хостинга виртуальных машин на Cloud Native Web App Service, где ребята тоже задействованы. Скоро запускаем переезд с SQS-очередей на Azure Service Bus. Здесь тоже не обойдется без .NET-разработчиков.
Вообще, у клиента огромный список того, что он хочет сделать. Сейчас у нас идет сражение за планирование, какой проект поставить во второй и третий квартал, а какой потом. Проектов очень много. Их можно разделить на несколько категорий:
На всех проектах важную роль сыграют .NET-разработчики. Тимлид ротирует задачи таким образом, что у всех есть возможность попробовать себя в разных проектах.
Хорошим подспорьем в такой работе, на мой взгляд, выступает то, что четко расписан процесс разработки. На проекте применяется SDLC. Кроме того, есть список технологий, который регулярно обновляется за счет включения трендовых технологий и сервисов. Предварительно они проходят обкатку в работе, чтобы те же DevOps понимали, как поступить во внештатной ситуации.
Разработчики могут самостоятельно прорабатывать архитектуру roadmap, которые они делают. Это дается на откуп команде. К слову, в ней тимлид, до 6 разработчиков .NET и два-три QA. Единственное, после проработки идею нужно защитить перед architecture-советом.
Если .NET-разработчик хочет, он может участвовать в архитектурных митингах и обсуждениях фич с клиентами. Это все на английском языке, так как наши клиенты преимущественно из США. Таким образом, специалист прокачивает навыки коммуникации, иностранного языка и профессиональную экспертизу. Напрямую можно будет пообщаться и с DevOps, DBA. В офисе они сидят неподалеку от разработчиков. Если специалист выбрал удаленку, то и здесь нет никаких препятствий к диалогу.
В SolbegSoft .NET-разработчик может развиваться как технически, так и в сторону менеджмента. У компании 50+ других проектов помимо миграции, где можно себя реализовать. Все в руках человека и зависит только от его качеств. Например, я вырос с позиции mid engineer до своей текущей позиции Head of Solution Architect.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.