Миграцията на стотици стари приложения от виртуални машини (VM) към AWS работи, когато я водите като производствена линия, а не като стотици отделни проекти: инвентаризирайте и класифицирайте всяко приложение, решете за всяко от тях дали да се обнови, или да се изгради наново, и разделете целия парк на блокове, поети от малки екипи. Общ скелет на приложенията, изпробвани стъпки за превключване и връщане и ръководства за експлоатация (runbooks), които всеки екип може да следва, поддържат качеството стабилно с нарастването на обема.
Започнете с инвентаризация, която показва от какво всъщност се нуждае всяко приложение
Преди някой да докосне AWS, избройте всички приложения, които работят на старите виртуални машини, и запишете фактите, които определят усилията за миграцията. В началото е достатъчна обща електронна таблица. Важното е всяко приложение да има ред, отговорник и едни и същи колони.
След това разпределете всяко приложение в малък брой направления, например обновяване, преизграждане и извеждане от употреба. Така екипите могат да планират по направления, вместо да обсъждат всяко приложение от нулата.
- Версия на средата за изпълнение и на рамката, като се отбелязва всичко с изтекла поддръжка
- Бази данни, споделени файлови ресурси и планирани задачи, от които зависи приложението
- Входящи и изходящи интеграции, включително твърдо зададени имена на хостове и IP адреси
- Метод за удостоверяване и всички тайни, съхранявани на виртуалната машина
- Бизнес отговорник, степен на използване и приемлив прозорец за прекъсване
Решавайте между обновяване и преизграждане за всяко приложение, а не веднъж за цялата програма
Нито една стратегия не пасва на стотици приложения. На някои им трябват само обновяване на рамката, изнасяне на конфигурацията и нова цел за деплой. Други носят толкова мъртъв код или заплетена структура, че преизграждането върху чиста основа е по-бързо от поправянето им.
Вземайте решението по писмени критерии, за да стигат различните екипи до един и същ отговор. Полезно правило: ако преместването на приложението върху стандартния скелет така или иначе означава да пренапишете повечето му контролери и достъпа до данните, изградете го наново. Ако бизнес логиката се пренася почти непокътната, обновете го.
Програмата на Crédit Agricole, която премести 600+ вътрешни приложения от стари виртуални машини към AWS, използва и двата пътя. Приложенията бяха изградени наново върху вътрешния скелет на банката на CodeIgniter, като някои бяха обновени, а други – изградени от нулата.
- Обновявайте, когато кодът е четим, поведението му е ясно и разликата във версиите на рамката е малка
- Изграждайте наново, когато бизнес логиката навсякъде е смесена с представянето или приложението зависи от премахнати възможности на езика
- Извеждайте от употреба, когато използването е почти нулево и бизнес отговорникът е съгласен, защото най-евтината миграция е тази, която пропускате
Разделете парка на блокове и дайте всеки блок на един екип
При този мащаб един централен екип се превръща в тясното място. Моделът с разделяне на блокове възлага група свързани приложения на един малък екип, който отговаря за тях от анализа до превключването.
Групирайте блоковете по общи зависимости, а не по азбучен ред. Приложенията, които споделят база данни или се извикват едно друго, трябва да се преместват заедно, иначе една и съща работа по интеграциите се повтаря в различни екипи.
Блоковете правят и напредъка измерим. Всеки екип отчита едни и същи състояния за всяко приложение, например анализирано, мигрирано, тествано, превключено и изведено от употреба, а таблото на програмата е сборът от тези състояния. Програмата на Crédit Agricole работеше по този начин и SDK Enterprises изпълни 50+ от миграциите на приложения като част от екипа на програмата.
Изградете един стандартен скелет и местете всяко приложение върху него
Стандартният скелет на приложенията е това, което превръща стотици миграции в повторяем процес. Той фиксира решенията, които не бива да се вземат отново за всяко приложение: структура на директориите, конфигурация от променливи на средата, формат на дневниците, проверки на състоянието (health checks), точки за удостоверяване и pipeline за деплой.
Така всяко мигрирано приложение се различава само по бизнес логиката си. Рецензентите знаят къде да гледат, екипите по експлоатация получават еднакви дневници и аларми, а поправка в скелета достига до всяко приложение, изградено върху него.
Поддържайте скелета малък и версиониран. Ако той се разрасне до собствена рамка, екипите ще започнат да го заобикалят.
Планирайте превключването и връщането преди първата миграция
Всяко приложение се нуждае от план за превключване, който посочва как се пренасочва трафикът, как се пренасят данните и как да се върнете назад. Решете тези неща, преди да се премести първото приложение. Импровизираното връщане по време на инцидент е начинът, по който програмите за миграция губят доверието на бизнеса.
- Период на замразяване: договорете с бизнес отговорника кога спират промените на старата виртуална машина
- Синхронизация на данните: мигрирайте данните предварително, а след това направете последна синхронизация на разликите по време на прозореца за превключване
- Превключване на трафика: променете DNS или маршрутизирането на балансьора на натоварването, с ниски DNS TTL, зададени няколко дни предварително
- Димни тестове (smoke tests): кратка скриптирана проверка на входа, ключовите екрани и интеграциите веднага след превключването
- Условие за връщане: посочен човек и писмени условия за превключване обратно
- Запазена стара виртуална машина: спрете я, но не я изтривайте, докато приложението не работи безпроблемно на AWS за договорен период
Напишете ръководства за експлоатация, които всеки екип може да следва от първия ден
Ръководството за експлоатация (runbook) е списъкът за проверка на една повторяема операция: подготовка на приложение, превключването му, връщането му, извеждане на виртуалната машина от употреба. Напишете всяко от тях веднъж, изпробвайте го върху първите няколко приложения и го обновявайте всеки път, когато нещо изненада някой екип.
Добрите ръководства назовават команди, отговорници и очаквани резултати, а не намерения. „Проверете дали приложението работи” не е стъпка. „Влезте като тестовия потребител и потвърдете, че таблото зарежда данните на акаунта” е стъпка.
Ръководствата са и начинът, по който инженерите, които се присъединяват по средата на програмата, бързо стават продуктивни. Специалист, който пристига през шестата седмица, трябва да може да превключи приложение, като следва документите след една съвместна сесия.
Къде се вписва външен екип в голяма миграция
Големите програми често се нуждаят от допълнителен капацитет за определен период, без да предават контрола. Поемаме блокове от миграции в рамките на по-големи програми, като работим върху скелета, ръководствата и инструментите на клиента, с нашите инженери и проверени фрийлансъри специалисти по един договор.
Основното накратко
- Инвентаризирайте и класифицирайте всяко приложение, преди да мигрирате което и да е от тях, за да може работата да се планира по направления.
- Избирайте обновяване, преизграждане или извеждане от употреба за всяко приложение по писмени критерии, които всеки екип прилага по един и същи начин.
- Разделете парка на блокове от свързани приложения, всеки от които изцяло се поема от един малък екип.
- Малък, версиониран скелет на приложенията прави стотици миграции еднакви и лесни за преглед.
- Никога не превключвайте приложение без изпробван път за връщане и без старата виртуална машина да е все още налична.
Въпроси и отговори
Колко време отнема миграцията на стотици приложения към AWS?
Зависи от броя приложения, от дела на тези, които трябва да се изградят наново, от броя паралелни екипи и от прозорците за превключване, които бизнесът приема. Направете оценката след класификацията: измерете времето за няколко приложения от всяко направление, умножете по размера на всяко направление и разделете на капацитета на екипите.
Да преместим ли първо старите приложения без промени (lift and shift) и да ги модернизираме по-късно?
Lift and shift е най-бързият вариант, когато приложението вече работи в поддържана среда за изпълнение и целта е да напуснете даден център за данни. При приложения в среди с изтекла поддръжка преместването им без промени пренася старите рискове на новата платформа, затова обновяването или преизграждането по време на преместването често излиза по-евтино като цяло.
Какво е миграция с разделяне на блокове?
Миграцията с разделяне на блокове разделя голям парк от приложения на групи свързани приложения и възлага всяка група на един екип, който отговаря за нея от анализа до превключването. Тя премахва централното тясно място и прави напредъка лесен за проследяване при много екипи.