Amazon на Azure: кейс SolbegSoft. Как переехать с одного облака на другое?

Почему мигрировали с Amazon на Azure?

К этому решению подтолкнула необходимость сокращения издержек и расходов. Сюда же отнесу end-user пожелания клиента. Наконец, у нас майкрософтовский .NET-стек, который не всегда слаженно работает с Amazon Cloud. Поэтому мы решили мигрировать, что называется, в родную гавань. 

Основная команда, которая принимала решения, состояла из VP of DevOps, троих DevOps инженеров, Solution Architect, System Architect, DBA,  двоих QA-инженеров. Кроме того, код также требовал изменений, поэтому, по сути, весь engineering слаженно трудился над проектом.

Начали действовать в мае 2019 года. Процесс давался нелегко. Нужно было перенести порядка 140 приложений.  Также из-за того, что клиенты используют решения SolbegSoft, у них срабатывали firewalls, которые запрещали доступ. 

Инфраструктура состояла из фермы виртуальных машин, SQL Master и SQL Replication Cluster. Мы продумывали разные стратегии. Даже слетали в Сиэттл, в штаб-квартиру Microsoft. Технические и бизнес-специалисты компании  нас проконсультировали и подобрали оптимальный подход для перехода на новую платформу. 

Всего их три:

• Рехостинг, или lift and shift. Это значит, что берем существующую структуру и без изменений все переносим. Код под Cloud Native не адаптируем, только меняем compute.
• Реплатформинг. По сути похож на рехостинг, но с внесением быстрых изменений и использованием «фишек» Cloud Native.
• Рефакторинг. Самый брутальный подход. Это полная адаптация под Cloud Native. По сути, это переписывание существующего солюшена под особенности облака, на которое переезжаешь. 

Команда изучила 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. И всех их нужно было перенести. Мы сделали разделение процесса разворачивания на две части: 

1. Сборка шаблонных пакетов
2. Непосредственно развертывание пакетов (deployment) с подстановкой необходимых значений конфигураций для конкретного environment. 

В итоге мы сделали конфигурацию шаблонной, пакеты стали независимыми. Во время deployment подставлялись нужные конфигурации. Теперь любой пакет можно было развернуть на любой environment и задать нужные параметры.

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

Какие итоги переезда на Microsoft Azure?

Дедлайна по переезду нет. Мы находимся в состоянии перманентной миграции. 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-разработчиков в проекте?

Наши .NET-разработчики помогали перенести данные с сервиса File Storage S3 от Amazon на Azure Blob Storage. Сейчас находимся в стадии переезда приложений с хостинга виртуальных машин на Cloud Native Web App Service, где ребята тоже задействованы. Скоро запускаем переезд с SQS-очередей на Azure Service Bus. Здесь тоже не обойдется без .NET-разработчиков. 

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

• roadmap. Их около 40% от всех задач;
• maintenance;
• tech dept.

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

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

Если .NET-разработчик хочет, он может участвовать в архитектурных митингах и обсуждениях фич с клиентами. Это все на английском языке, так как наши клиенты преимущественно из США. Таким образом, специалист прокачивает навыки коммуникации, иностранного языка и профессиональную экспертизу. Напрямую можно будет пообщаться и с DevOps, DBA. В офисе они сидят неподалеку от разработчиков. Если специалист выбрал удаленку, то и здесь нет никаких препятствий к диалогу.

В SolbegSoft .NET-разработчик может развиваться как технически, так и в сторону менеджмента. У компании 50+ других проектов помимо миграции, где можно себя реализовать. Все в руках человека и зависит только от его качеств. Например, я вырос с позиции mid engineer до своей текущей позиции Head of Solution Architect.