AWS Highlights: як перенести інфраструктуру підприємства в AWS Cloud

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт, мене звати Сергій Борисов, я — Cloud Solutions Architect в компанії N-iX, яка є Advanced Tier Services партнером Amazon Web Services (AWS). Я майже фанатичний Cloud Solutions Architect з фокусом на AWS. Маю понад 16 років досвіду роботи з інформаційними технологіями, а також маю пристрасть до розробки та впровадження масштабованих, безпечних та економічно ефективних хмарних рішень.

Разом з Ігорем Іванюком ми розпочинаємо цикл статей, у яких плануємо розповідати про найцікавіші проєкти, пов’язані з AWS. Як Solutions Architect в AWS, Ігор допомагає замовникам впроваджувати свої ноу-хау та розвивати бізнес за допомогою хмарних технологій. До цього Ігор використовував сервіси AWS у своїх проєктах, допомагаючи компаніям впроваджувати хмарні технології у галузі фінтех, банківських рішеннях та e-commerce.

Я впевнений, ви помітили, що за останнє десятиліття все більше і більше клієнтів мігрують свої робочі навантаження в хмару AWS. Хмарні міграції зазвичай є складними та трудомісткими для клієнтів. Щоб підтримати та полегшити ці міграції, AWS розробила Migration Acceleration Program (MAP).

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

Далі я розповім, як N-iX допомогла одному з найбільших світових виробників побутової електроніки та напівпровідників перенести свою інфраструктуру в хмару AWS. Ця міжнародна електронна компанія спеціалізується на виробництві побутової електроніки, ІТ-технологіях, мобільному зв’язку та рішеннях для пристроїв. Щоб підтримати свій стрімкий розвиток, компанія вирішила відмовитися від дорогих ліцензій Oracle, які стали критичною перешкодою для масштабування. Вони скористалися перевагами MAP для міграції в хмару AWS, підтримуючи сервіс в робочому стані 24/7 під час міграції.

Чому підприємства переходять на AWS

Компанії, що розпочинають свій шлях до AWS, зазвичай мають цілу низку причин для цього. Наприклад, прагнуть поєднати декілька центрів обробки даних в одному місці, позбутися застарілого обладнання або програмного забезпечення, скоротити витрати на ліцензії баз даних. Чи знали ви, що компанії можуть заощадити 20-50% витрат на ресурси після переходу на AWS?

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

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

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

Що таке AWS MAP

У жовтні 2019 року Amazon завершила міграцію власних баз даних з Oracle до хмари AWS. Вони перенесли 75 петабайтів внутрішніх даних, що зберігалися у майже 7 500 базах даних Oracle (до спеціально створених баз даних AWS).

Спираючись на цей колосальний досвід та масштабуючи успішний підхід до міграції, AWS розробила комплексну стратегію під назвою AWS Migration Acceleration Program (MAP).

Стратегія MAP складається з трьох фаз, що забезпечують ефективні міграції в хмару AWS. Ця стратегія адаптована до різних масштабів, хоч то десятки, сотні або навіть тисячі баз даних та застосунків. Кожна фаза сприяє успішній міграції, але всі ці фази пов’язані між собою та утворюють ітеративний процес, що залежить від прогресу клієнтів у їхній хмарній подорожі.

Три етапи AWS MAP

Розгляньмо, як партнери AWS проходять етапи MAP зі своїми клієнтами.

Оцінювання

На етапі оцінки ми звертаємо увагу на готовність клієнта до роботи в хмарі. Ми разом з клієнтом визначаємо робочі навантаження, які потрібно перенести до хмари AWS. А також аналізуємо залежності від інфраструктури та складності додатків. Потім ми проводимо аналіз витрат, щоб порівняти поточні витрати клієнта з прогнозованими після переходу до хмари AWS.

На цьому кроці ми обговорюємо стратегії міграції та модернізації клієнтської інфраструктури й розробляємо бізнес-кейс для обґрунтування рішення про перехід до хмари AWS.

Основним результатом цього першого етапу є документ під назвою Migration Readiness Assessment, що характеризує готовність до міграції. Цей документ надає клієнту переконливу бізнес-інформацію для переходу до наступної фази програми MAP. Документ ретельно описує сильні сторони клієнтської інфраструктури, які можна швидко перенести в хмару AWS. Також цей документ вказує на сфери, які потребують покращення або підвищеної уваги клієнта для безперешкодної міграції у хмару.

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

Сильні сторони — це команди та практики, які добре підготовлені до широкого впровадження в організації замовника. Ці сфери не потребують додаткових зусиль для успішної масштабної міграції в хмару. Слабкі сторони, з іншого боку, вказують на сфери, які потребують дій.

В результаті SWOT-аналізу ми виявили, що клієнт був добре підготовлений до початку своєї хмарної подорожі в таких сферах:

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

З іншого боку, ці сфери вимагали вдосконалення:

  • відсутність досвіду роботи з міграційними проєктами;
  • команди не мали достатньо досвіду у хмарних сервісах;
  • відсутність чіткості у підходах до роботи з керованими сервісами, конфігурацією та управлінням змінами в хмарі.

Розв’язання цих проблем мало забезпечити безперебійний процес міграції та зменшити ймовірність затримок у створенні фундаменту для проєкту.

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

Етап оцінки зайняв п’ять тижнів. Ми використовували AWS Migration Evaluator для створення бізнес-обґрунтування міграції до AWS. Виявилося, що спочатку лише 30% інфраструктури клієнта готові до міграції в хмару. Щоб дізнатися більше про AWS Migration Evaluator, перейдіть на офіційну сторінку сервісу.

Підготовка

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

Основними результатами етапу підготовки є чітко визначена траєкторія міграції, а також готовність до початку масштабної міграції. Припустимо, що клієнти шукають стимули, як-от кредити або підтримка партнерів. У такому разі цей етап також передбачає зобов’язання клієнта досягти після міграції річного регулярного доходу та завершити аналіз Well-Architected Review для пілотних робочих навантажень, які переходять у хмару AWS на цьому етапі.

Повертаємося до нашого кейс-стаді. На другому етапі ми співпрацювали з AWS Professional Services, щоб розробити нову архітектуру баз даних. У цій новій архітектурі Amazon Aurora PostgreSQL та Amazon DynamoDB замінили такі клієнтські бази даних як Oracle та MongoDB.

Для локальних баз даних Oracle клієнта з високою вартістю ліцензії, ми дійшли згоди використовувати хмарні бази даних Amazon Aurora PostgreSQL. Ця повністю керована AWS система регуляційних баз даних поєднує в собі швидкість та надійність Amazon Aurora з простотою та економічністю баз даних з відкритим кодом. Amazon Aurora PostgreSQL — це сучасна заміна Oracle, яка поліпшує конфігурацію, експлуатацію, та масштабування нових та чинних баз даних.

Для баз даних MongoDB ми запропонували клієнту використовувати Amazon DynamoDB як повністю керовану NoSQL базу даних. DynamoDB призначена для запуску високопродуктивних застосунків і пропонує вбудовану систему безпеки, безперервне резервне копіювання, автоматизовану реплікацію в декілька регіонів, кешування в пам’яті, а також інструменти для імпорту та експорту даних.

Міграція та модернізація

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

Третій етап завершує міграційну подорож клієнта за допомогою ретельно розрахованої та оптимізованої операції.

У нашому кейс-стаді на третьому етапі ми співпрацювали з консультантами Database Migration Global Delivery (DMGD), щоб конвертувати понад 3000 SQL-запитів з Oracle PL/SQL на PostgreSQL PL/pgSQL. Ми використовували AWS Schema Conversion Tool для автоматизації конвертації. Ті SQL-запити, що не вдалося автоматично конвертувати, конвертували вручну, після чого перевірили, що код PL/pgSQL з базою даних Aurora PostgreSQL дає такі ж результати, як і PL/SQL код з базою даних Oracle.

Після того, як ми записали конвертований код до цільової бази даних Aurora PostgreSQL, консультанти DMGD допомогли підвищити швидкість роботи нової бази даних. Оскільки чинна база даних клієнта продовжувала працювати, дані в ній постійно змінювались. Щоб забезпечити міграцію цих змін, ми налаштували постійну реплікацію за допомогою функції change data capture в AWS Data Migration Service. Цей підхід був частиною безперебійної міграції, і сам він дозволив клієнту перейти на нову базу даних без простою.

Переваги міграції в AWS

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

Завдяки ретельно розробленим етапам програма MAP забезпечує систематичну основу, яка дозволяє успішно виконувати міграцію в хмару. Ця структура також допомагає клієнтам дізнатися більше про можливості AWS і сприяє їхньому швидкому прогресу в хмарному середовищі.

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

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

Завдяки трьом етапам — оцінюванню, підготовці, міграції і модернізації — MAP гарантує, що клієнти не тільки успішно мігрують, але й зможуть швидше почати використовувати можливості хмарних сервісів. У рамках програми MAP клієнти можуть отримати додаткові фінансові вигоди від AWS, як-от кредити на послуги після міграції або оплату послуг з міграції.

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

Міцний фундамент як ключ до успіху

Хоча всі три етапи програми MAP роблять значний внесок, на мій погляд, етап оцінювання є найбільш важливим. Тут створюється фундамент всієї міграції в AWS. Отже, як саме N-iX забезпечує ефективність етапу оцінювання?

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

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

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

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

Використання інструменту AWS Migration Readiness Assessment (MRA) допомагає діагностувати готовність до міграції, узгодити дії керівництва наших клієнтів та обґрунтувати потребу в змінах.

Анкетування та інтерактивні заходи, які ми проводимо під час консультативних семінарів, також сприяють цьому процесу. Проходження MRA допомагає клієнту підготуватися до міграційного проєкту. Цей досвід також висвітлює сфери, які можна покращити на етапі підготовки.

Крім того, ми використовуємо такі інструменти, як Optimization and Licensing Assessment (OLA), а також Cost Assessment, щоб визначити обсяг міграції. Під час оцінювання варіантів міграції в хмару ми враховуємо потенційний вплив витрат на ліцензування програмного забезпечення та стратегії управління ними.

Ми використовуємо OLA як інструмент для оптимізації витрат клієнта на ліцензії. Він генерує звіт для моделювання потенційних сценаріїв розгортання з використанням ліцензій. Завдяки таким ретельним процедурам партнери AWS гарантують, що етап оцінювання мине, як заплановано, і створить основу для успішної міграції в хмару.

Висновки

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

Як бачите, використання правильного підходу спрощує складні, трудомісткі та відповідальні міграції корпоративних робочих навантажень у хмару. Програма Migration Acceleration Program, партнери AWS та чітке планування можуть забезпечити безперешкодну міграцію для будь-якого клієнта.

Залишайтеся з нами та стежте за новинами про проєкти, що пов’язані з AWS.

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

У на зараз ошивається команда безкоштовних Архітекторів з амазону

Ну не знаю
Читають методичку
Багато мітингів ніпрощо

Тільки й того що язик не шершавий і босам відкати гарно заходять

Дуже дякую за стат’ю. Але тема не розрита — чому АWS, а не Azure(name it) ? Які pros&cons кастомер отримав після міграціі?

Какие были требования у клиента, что вы его убедили на DynamoDB вместо DocumentDB?

Dynamo по стоимости адаптации существующих приложений может быть намного дороже, но поскольку про требования в статье ни слова, то что это за кейс такой? Как я могу понять что выбранный подход имеет смысл?

Раз уж говорить по кейс, сделайте две диаграммы исходное и целевое состояние ключевых компонентов системы без специфики вашего клиента, покажите в чем выигрыш, где компромисс. А так ребята, спасибо за текст, но он не так полезен если цель была показать ваш уровень.

Ну воно в будь-якому випадку буде не безкоштовне (інстанси, зберігання даних, налаштування).

Привіт!

Хочу відповісти тут на цей і на подібні запити.

1. У світі не існує ідеальних імплементацій. Є дуже багато нюансів, моментів і т.п., самий типовий з них — забаганки Клієнта, наприклад: «ми до того звикли», «нам так зручніше», «у нас є відповідні спеціалісти», «ми вже купили ліцензію на це», «просто ми так хочемо» і так далі. В ітозі ідеальний солюшен перетворюється на не завжди ідеальну імплементацію. Але Клієнт — хепі :)
2. Вказати тут обгрунтування всіх подібних кейсів — нереально.
3. Сподіваюсь — відповів

Дякую за статтю, зрозумілий опис на high-level актуальної теми та наявного тулінгу. Кейс Mongo -> DynamoDB дуже цікавий, бо зазвичай Dynamo не підходить і кастомери обирають або DocumentDB як «офіційний» еквівалент, або Mongo Atlas коли хочуть взяти максимум від Mongo

Чи знали ви, що компанії можуть заощадити 20-50% витрат на ресурси після переходу на AWS?

Лукавство. чтобы перейти на cloud, при этом не теряя в надежности — Вам нужны люди которые этот самый cloud знают нормально. Эти люди стоят денег. Если у Вас их нет (а у вас их нет — с чего бы им идти где нет), то:

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

Не стоит цепляться за миф, что мол cloud — дешевле. Не зря появились такие вещи как FinOps и множество других вещей, суть который сводиться к «cloud ну очень дорого, а как-бы мне в унитаз не вылететь на этих расходах»

вы сами все сделаете, велика вероятность попасть на деньги и качестве

А такивідкатик ще босам

Треба вчитися і самим робити

Ростити як там їх accountability and credibility
Щоб ваше слово щось значило

Лукавство. чтобы перейти на cloud, при этом не теряя в надежности — Вам нужны люди которые этот самый cloud знают нормально. Эти люди стоят денег. Если у Вас их нет (а у вас их нет — с чего бы им идти где нет),

Зачем же передергивать?
Ведь для того чтобы заимплементить и эксплуатировать аналогичную инфраструктуру в частном DC, тоже нужны специалисты которые в этом разбираются, и их тоже днем с огнем не сыщешь, причем кавалификация их должна быть сильно повыше.
Миграция в клауд просто приоткрывает уже давно накопившиеся проблемы до разгребания которых :
— у специалистов компании не дошли руки
— у специалистов компании не хватает компетенций, но об этом не хочется говорить вслух ведь это сразу потянет за собой косты.
— для внесения изменений требуются все те же сторонние консультанты с глубоким знанием инфраструктуры ДС.

Перезд в клауд позволит:
— не заниматься вопросами связаным с поддержанием собственного DC.
— вопросы связанные с расширением теперь решаются через Infrastructure-as-code и занимают не месяцы и годы, а часы или дни. Сделать подобное конечно можно и в частном DC, но это уже будет частный клауд и все равно он будет опираться на сотрудников которые сами по себе представляют риск, а не на бизнес клауд-провайдера.
— поскольку инфра в клауде конфигурируемая, то такое кол-во «старых добрых админов» проповедущих подходы «держать и непущать» уже не требуется. Вместо них нужны адекватные DevOps-ы.

Ну пару слов насчет Oracle-a.
Тот кто когда-либо с ним работал или сталкивался с его лицензионными ограничениями, знает:
— да же если у Oracle-а нет претензий к вашей компании по лицензированию, при более углубленном расмотрении такие претензии легко можно предъявить.
— лицензировани Oracle построено таким образом что все удобства доступны только в Enterprise Edition лицензии или как она там сейчас называется, иными словами максимальные отчисления, в то время как используя другие лицензии вы сильно ограничены в возможностях построения решений которые не требуют EE лицензии.
А потому любые попытки слезть с vendor lock-in в общем случае несут добро.

В загальному — клауд дорожчий, однозначно.

Він стає цікавим відтоді коли навчишся їм правильно користуватись, як і будь-яким інструментом.

Згідний на 100%

Чи знали ви, що компанії можуть заощадити 20-50% витрат на ресурси після переходу на AWS?

А можуть і переплатити

А можуть навіть ще більше заощадити, якщо розглядатимуть і інших провайдерів

Підписатись на коментарі