З початком повномасштабної війни росії проти України Fozzy Group зіштовхнулася з новими викликами. Для наших бізнесів критично важливо було забезпечити українців продуктами першої необхідності, швидко адаптуватися до змін та побудувати нові логістичні ланцюжки.

ІТ інфраструктура TemaBit Fozzy Group відіграла одну з ключових ролей у вирішенні цих завдань. Завдяки їй компанія могла:

• швидко реагувати на зміни попиту на продукти;
• налагодити постачання товарів з нових джерел;
• підтримувати роботу магазинів та складів.

Також це був рік, коли ми планували оновити обладнання центрів обробки даних (ЦОД), яке уже ставало застарілим. Будь-які розстрочки та великі капіталовкладення були недоступними. Крім того, час доставки обладнання значно збільшився. Так, замість 90 днів, які ми зазвичай чекали на нове обладнання, довелося б чекати удвічі, а іноді й втричі довше. Це вже не кажучи про випадки, коли взагалі було неможливо передбачити терміни доставки.
З початком повномасштабної війни Fozzy Group опинилася перед викликами. Зберігати дані на серверах на землі було ризиковано, а оновити обладнання ЦОД було непросто. Тому було прийнято рішення рухатися у хмару. Це дозволило компанії продовжувати роботу та забезпечувати українців продуктами першої необхідності.

Чому ми обрали AWS?

Проаналізувавши різні варіанти клаудів наш вибір впав на AWS, оскільки їхня політика партнерської співпраці спонукає до розвитку експертної кваліфікації IT-команд за напрямком cloud strategy. 

Також AWS дає можливості оптимізувати хмарні ресурси та детально спостерігати за ними у хмарі. Одна з найважливіших хмарних вигід — можливість платити тільки за ті ресурси, які ви фактично використовуєте, та не переплачувати наперед. Не треба інвестувати або гадати, скільки треба вкласти грошей — Pay as you Go. 

З початку співпраці наша компанія збагатила внутрішню експертизу і вже налічує 15+ AWS Certified Solutions Architect (Associate and Professional) та інші сертифікації PRO and Specialty рівнів. На цьому ми не зупиняємося та продовжуємо сертифікацію наступних. Цей процес драйвить Станіслав Коленкін. У його команді майже кожен пройшов успішне навчання та має мінімум 2 сертифікати включно з AWS Solution Architect Associate.

Серед наших колег в TemaBit за перше півріччя 82 людини пройшли навчання із роботи з AWS сервісами на різні тематики: робота в хмарі, безпека в хмарі, створення архітектурних рішень для безперебійного забезпечення роботи компанії.

Jornеy map: де ми є та куди прямуємо

Підготовка

Уже на початку ми розуміли, що перехід у хмару має бути оціненим з усіх сторін та ретельно проаналізованим. Адже необдумане рішення може призвести до безлічі ризиків. 

Аудит

Першим кроком ми зробили великий аудит інфраструктури, знайшли всі системи та пішли до бізнесів, щоб визначити ступінь їхньої критичності. А бізнесів у нас досить багато, серед ключових — мережі «Сільпо» (300+ магазинів), «Фора» (300+ магазинів), «Траш» (90+ магазинів), гіпермаркети Fozzy C&C (8 магазинів), Банк «Восток», мережа аптек «Біла ромашка» (90+ аптеки), магазини техніки Ringoo, e-com (доставка “Сільпо” та LOKO), Власна Логістика, маркетплейс MAUDAU, магазини зоотоварів E-ZOO та ін.

Тут нас чекав виклик, адже оцінити критичність своїх систем бізнеси не могли, спершу все здавалося надважливим. Та коли дійшли до фінансової складової і постало питання, чи може бізнес, скажімо, платити 100 тисяч доларів на рік за сервіс, почали задумуватися. Щоб визначити критичність та черговість перенесення сервісів у хмару, ми розробили алгоритм, який запропонували заповнити кожному з бізнесів.

Спершу ми визначили розподіл між собою системи за хвилями міграції. Ставало питання: які системи потрібно нести в хмару вже сьогодні, які можуть почекати, наприклад, два-три місяці, а які й взагалі можна відкласти на кінець року. Для визначення цієї черговості були сформовані певні критерії, які й формували хвилі міграції та включали перелік систем. В нашому випадку ми отримали 6 хвиль міграції системи в хмару. Визначення та погодження хвиль видались для нас складною та тривалою аналітичною роботою.

Ті ж системи, які бізнеси віднесли до некритичних, ми залишили у ЦОДі та захистили реплікою. Наразі копії всіх віртуальних машин є в AWS. Та, нажаль, ніхто не може з впевненістю сказати, скільки зусиль та часу займе відновлення цих систем у разі їх втрати.

Team composition

Ми сформували команду фахівців, яка буде займається міграцією в AWS. Були сформовані декілька повнофункціональних команд міграції, кожна з яких має у своєму складі PM, архітектора, системних інженерів, DBA. Команди можуть працювати паралельно для пришвидшення міграції.

Ми починали міграцію з lift and shift, тобто без зміни технологій. Тому на початку для більшості працівників, наприклад, розробників, у процесах нічого не змінювалося. Як вони працювали з нашим ЦОДом, так вони й продовжили працювати з AWS, для них це було знайоме середовище.

Коли вже почали перехід на нативні сервіси AWS, потрібно було розуміти, наприклад, як організовувати процес бекапу, мережу, захист та ін. Найважчим тут було паралельно з першим процесом здобувати необхідні знання для подальшої роботи.

Вже для систем, які рефакторяться, потрібна специфічна експертиза і тут ми отримували підтримку від фахівців з AWS. Паралельно наші працівники проходили навчання та сертифікацію в AWS. Також ми посилили нашу команду досвідченими фахівцями, які мають великий досвід у міграції в інших великих компаніях.

Варто зазначити, що на всіх етапах міграції нас підтримує команда експертів з AWS та нова cloud Foundation команда зі скілованими спеціалістами, у яких за спиною сотні успішних проєктів з міграції та AWS.

Міграція

Основним драйвером комбінованого підходу, який ми обрали, — є війна проти України. Нам дуже важливо якнайшвидше убезпечити ключові дані, які необхідні для безперебійної роботи бізнесу. 

Підходів до переходу є досить багато: Rehost, Replatform, Refactor, Retire, Retain, Repurchase.

Ми ж для себе виділили такі два:

1. Перенесення даних, як є — lift and shift;
2. Перенесення з реархітектурою, щоб дані ставали native cloud.

Ми обрали для Fozzy Group комбінований шлях, тобто рухаємося одночасно двома шляхами. Ми не могли зупинити ЦОД на тривалий період, адже це як робити операцію на живому серці. Робота вимагає філігранності та обережності. Тому ми домовлялися з бізнесами, і частинами переносили системи, не зупиняючи роботу магазинів.

Для Critical Application робимо реархітектуру і далі вони йдуть на cloud native application. Інші додатки переносимо «як є», а далі вже поступово будемо робити їх cloud native.

До кінця року плануємо закінчити міграцію Critical Application з реархітектурою та паралельно перенести важливі дані «як є».

Далі, безумовно, будемо працювати з cloud native. Також, у нас є дані, які не можна перенести у cloud, навіть з підходом «як є», тому їх треба рефакторити, а це вже, по суті, новий проєкт, який також буде братися до роботи.

Слід зауважити, що всі нові розробки відразу реалізуються у клауді на базі AWS. Таких проєктів стає дедалі більше й управління ними потребує все більшого ресурсу з точки зору фахівців. Тому тут ми вирішили рухатися шляхом Platform Engineering і в нас з’явилася Platform team та SRE у рамках cloud Foundation. 

Cloud Foundation — це інтегрована платформа для ефективного створення, управління та оптимізації хмарної інфраструктури. Вона вибудовує автоматизовані патерни, завдяки яким реалізувати та управляти проєктами стає легше, швидше та з меншим залученням фахівців. Тобто робота над запуском нового проєкту стає більш автоматизованою та імплементується підхід Infrastructure as code (IaC).

Поради бізнесам, які задумалися про міграцію в AWS

• Для переходу в AWS варто зважено оцінювати та прогнозувати витрати. AWS пропонує широкий спектр послуг, кожна з яких має власну цінову політику. Недооцінка може призвести до несподіваних високих витрат, тоді як правильна оцінка допоможе ефективно використовувати ресурси та уникнути фінансових збитків. Важливо ретельно проаналізувати навантаження та спрогнозувати витрати на розміщення в AWS не тільки на перший, але й на другий та третій роки, бо ці витрати можуть стрімко зростати, адже після міграції настає фаза оптимізації ресурсів, right sizing, reservation.
• Перехід компанії на AWS вимагає часу та фахових знань для налагодження та управління інфраструктурою. Для деяких компаній це може стати викликом, особливо якщо вони не мають внутрішніх ресурсів для такого роду роботи. Системи можуть почати поводитися неочікувано під час покрокового перенесення систем в хмару без детального їх опису та залежностей одна від одної. Це може призвести до повної чи часткової відмови частини систем, які залежать від тої, що мігрується.
• Під час переходу на AWS важливо застосовувати IaC підхід і заборонити clickOps.
• Варто одразу прорахувати та вивільнити необхідну кількість людей для всіх процесів, оскільки без цього строки виконання міграції можуть порушитися.
• Під час переходу зі старих процесів на нові хмарні змінюється і майндсет у людей, тобто відбувається певна трансформація. Тому тут важливо мати команду сильних DevOps фахівців, які допоможуть колегам із різних підрозділів справитися із культуральними змінами та зроблять процес трансформації безшовним, а також дозволять оптимізувати фінансові і людські витрати.
• Почати впроваджувати FinOps фреймворк та культуру.

 Замість висновків

Перехід компанії на AWS може мати багато переваг, таких як масштабованість, гнучкість та широка функціональність. Однак, слід враховувати потребу в фахових знаннях для ефективного управління.

Перед прийняттям рішення про перехід на AWS, варто ретельно проаналізувати свої потреби та можливості, а також порівняти його з іншими схожими сервісами. А далі — багато цікавої та складної роботи, зміна майндсету компанії та постійне навчання, аби ставати ще потужнішими.

І пам’ятайте, AWS — це не той звір, який кусається, до нього просто треба знайти підхід.