Сьогодні все більше і більше компаній у світі замислюються щодо переносу своєї інфраструктури до хмари, тобто щодо міграції у хмару. Хмара та хмарні сервіси дозволяють підвищити гнучкість діяльності, оптимізувати витрати чи збільшити темпи розробки, впливає як на ІТ-команду, так і на всю організацію в цілому.
Але важливо бути на 100% впевненими, що ви безпечно та економічно переміщаєте свої дані та програми, не перериваючи роботу кінцевого користувача. Дотримуючись наших рекомендацій щодо міграції Google Cloud Platform, організації можуть легко та швидко отримати доступ до переваг хмарної технології GCP.
Що таке хмара Google?
Google Cloud Platform – це набір загальнодоступних хмарних сервісів для обчислень, зберігання та розробки додатків, які працюють на обладнанні Google. Розробники програмного забезпечення, адміністратори хмарних служб та інші корпоративні ІТ-спеціалісти можуть отримати доступ до сервісів Google Cloud Platform через загальнодоступний Інтернет або через виділене з’єднання.
Хоча Google є меншим гравцем на ринку хмарних послуг, він має декілька значних і важливих переваг серед конкурентів:
- Ціноутворення – Google оцінює послуги посекундно, із значними знижками для постійних клієнтів без попередніх зобов’язань. Також ціни на інстанси можуть бути на 40-50% нижчими, ніж у компаній-конкурентів.
- Приватна глобальна мережа — Google Cloud Platform використовує приватну глобальну оптоволоконну мережу Google, яка забезпечує дуже швидке пряме з’єднання між центрами обробки даних.
- Міграція в реальному часі – Google Cloud Platform може безперешкодно переносити робочі навантаження з однієї віртуальної машини на іншу без жодних простоїв.
- Безпека — GCP пропонує ті самі заходи безпеки, що й власні глобальні послуги Google, такі як Gmail, Google Search та Google Документи.
Що таке міграція в хмару?
Міграція в хмару – це процес переміщення цифрових активів, таких як дані, робочі навантаження, ІТ-ресурси або програми у хмарну інфраструктуру. Міграція в хмару зазвичай означає переміщення інструментів та даних зі старої, застарілої інфраструктури або локального центру обробки даних, що надається постачальником хмарних послуг, таким як Google Cloud. Усі дані переходять до хмари, хмарна міграція дедалі частіше відбувається всередині хмари, оскільки компанії мігрують між різними постачальниками хмарних послуг (відома як міграція із хмари до хмари). Для більшості організацій хмарна міграція є найвищим пріоритетом у контрольному списку ІТ-перетворень. Звичайно, можуть бути різні причини, що підтримують міграцію, серед яких одними з основних є керування витратами, інновації (нова аналітика, машинне навчання, штучний інтелект), гнучкість ІТ, гарантія та надійність, просте керування інфраструктурою, згортання сховищ даних та підвищення продуктивності.
Однак міграція сховища даних з однієї платформи на іншу — непросте завдання і часто досить складний процес. Тож з чого компаніям краще почати? Надзвичайно важливо точно знати, що є в їхній ІТ-екосистемі, і розуміти, які додатки їм слід перенести в першу чергу і усвідомлювати усі ризики, що з цим процесом пов’язані.
Наші фахівці рекомендують організаціям розпочати процес міграції до хмари з оцінки їхньої поточної it інфраструктури, яка допоможе визначити усі ризики, складності, ключові показники ефективності, інтеграцію, продуктивність, виконання запитів тощо. Це також допомагає організації створити цілісне уявлення про активи свого центру обробки даних та ІТ-екосистему.
І звісно, перше запитання, яке потрібно поставити, — що мій бізнес отримає від хмарної міграції?
Які основні переваги міграції в хмару?
Давайте розглянемо деякі з переваг, які змушують організації переносити ресурси у загальнодоступну хмару:
- Масштабованість. Хмарні обчислення можна масштабувати щодо підтримки більших робочих навантажень та більшої кількості користувачів набагато простіше, ніж локальну інфраструктуру. У традиційних ІТ-середовищах компаніям доводилося б купувати та встановлювати фізичні сервери, ліцензії на програмне забезпечення, сховище та мережеве обладнання щодо масштабування бізнес-послуг.
- Вартість – постачальники хмарних послуг беруть на себе технічне обслуговування та оновлення, компанії, що переходять до хмари, можуть значно менше витрачати на ІТ-операції. І тим самим вони можуть виділити ще більше ресурсів на власні інновації — розробку нових продуктів або покращення вже наявних.
- Сучасний цифровий досвід — користувачі можуть отримувати доступ до хмарних служб та даних із будь-якого місця, незалежно від того, чи вони є співробітниками чи клієнтами. Це сприяє цифровій трансформації, підвищує якість обслуговування клієнтів та надає співробітникам сучасні та гнучкі інструменти.
Які загальні проблеми міграції у хмару?
Міграція може бути складною та інколи навіть ризикованою, без спеціалізованої підготовки. Ось деякі з основних проблем, з якими стикаються багато організацій під час міграції та перенесенні ресурсів.
Опір впровадженню хмарного середовища
Коли справа доходить до загальних проблем під час міграції, найчастіше найбільшою проблемою є люди. Люди схильні чинити опір змінам, бо ж міграція приносить багато змін та навіть збоїв — часто зі суттєво новими системами, процесами і навіть керівництвом.
Відсутність стратегії
Багато організацій починають мігрувати в хмару, не приділяючи достатньо часу та уваги розробці стратегії. Успішне впровадження потребує ретельного планування наскрізної міграції у хмару, бо кожен додаток і набір даних можуть мати різні вимоги та міркування, а також може знадобитися свій підхід до міграції в хмару. В організації має бути чітке економічне обґрунтування щодо кожного робочого навантаження, яке переноситься в хмару.
Організації повинні зосередитись на створенні плану управління змінами, який чітко визначає:
- Комплексну стратегію міграції
- Можливі проблеми міграції
- Ресурси підтримки міграції
- Методи перевірки успішної міграції
Ось чому багато організацій працюють із досвідченими ІТ-фахівцями над розробкою високорівневих планів та показників щодо плавного переходу.
Керування витратами
При переході до хмари багато організацій роблять одні й ті ж помилки і не встановлюють чітких KPI, щоб розуміти, що вони планують витратити або заощадити після переходу. Це ускладнює розуміння того, чи міграція була успішною з економічного погляду. Крім того, хмарні середовища динамічні, і витрати можуть швидко змінюватися в міру прийняття нових послуг та зростання кількості використаних програм.
Час простою
При переміщенні великих обсягів даних у хмару одним із найбільших ризиків є перебої у роботі мережі. Якщо резервне копіювання даних не виконується належним чином, збої можуть призвести до безповоротної втрати даних.
Потенційний обхідний шлях — створення резервного ІТ-середовища, в якому можна розміщувати та запускати програми до завершення міграції. Зверніть увагу, що тимчасові сервери часто не можуть впоратися з піковими навантаженнями.
У таких ситуаціях найкраще керувати робочими навантаженнями користувачів та/або заздалегідь інформувати користувачів про обмежені можливості та періодичну недоступність додатків.
Ось чому ідеальним рішенням є варіант міграції до хмари у години мінімального навантаження.
Безпека і конфіденційність
В той момент, коли ваші дані починають переноситися з фізичних серверів, стає найбільш вразливим і необхідно звернути пильну увагу на мережеву безпеку та потенційні вразливості перед початком процесу міграції.
Бажано також перевірити:
- Які короткострокові вразливості може спричинити процес міграції інфраструктури в хмару?
- Чи будуть системи відслідковуватися на наявність загроз у режимі реального часу?
- Чи будуть дані підлягати наскрізному шифруванню та резервному копіюванню?
- Наскільки політики безпеки хмарної платформи співпадають з вашими?
- Чи відповідає він стандартам безпеки даних (HIPAA, PCI DSS, CCPA тощо)?
Сумісність
Не всі програми, які потрібно перенести у хмару, можуть бути сумісні з хмарним середовищем. Деякі програми краще працюють у приватній або гібридній хмарі, ніж у загальнодоступній хмарі, інші програми вимагають незначного налаштування, а треті можуть вимагати масштабного перекодування.
Якщо ви проводите покрокову міграцію, обов’язково визначте та усуньте проблеми сумісності між локальними системами та хмарними службами.
Однак за наявності сервісів у хмарі від багатьох постачальників функціональна сумісність не викликає занепокоєння. Крім основних постачальників, таких як Google Cloud Platform, існує безліч спеціалізованих пропозицій, які можуть краще відповідати вашим потребам.
Адаптивність
Адаптивність при міграції відноситься до здатності організації співпрацювати та підвищувати ефективність за рахунок нових систем та політик.
Організації, що не здатні адаптуватися, часто стикаються з проблемами міграції до хмари. Під час міграції підготуйте бізнес-процеси для спільної роботи з новою архітектурою. Це може означати використання нового підходу до розподілу:
- Технічні ресурси
- Фінансування
- Кадрове забезпечення
- Влада
- Процедури контролю
Стратегії міграції у хмару
Gartner визначив п’ять методів міграції до хмари, відомих як “5 R”. Організації, які бажають перейти в хмару, повинні добре поміркувати, яка стратегія міграції найкраще відповідає їхнім потребам. Нижче наводимо короткий опис кожної:
Rehosting. Повторний хостинг, або «підйом та перенесення», передбачає використання «інфраструктури як послуги (IaaS)». Ви просто повторно розгортаєте існуючі дані та програми на сервері хмар. Це легко зробити, і тому він підходить для організацій, що лише знайомляться з хмарними середовищами. Це також гарний варіант для тих випадків, коли важко змінити код, і ви хочете перенести свої програми без змін.
Refactor. Рефакторинг, або «підняти, переробити і змінити», це коли ви налаштовуєте і оптимізуєте свої програми для хмари. І тут використовується модель «платформа як послуга» (PaaS). Базова архітектура програм залишається незмінною, але вносяться певні зміни, що дозволяють краще використовувати хмарні інструменти.
Revise. Стратегія ґрунтується на попередніх, вимагаючи більш значних змін в архітектурі та коді систем, що переміщуються у хмару. Це робиться для того, щоб програми могли повною мірою використовувати сервіси, доступні в хмарі, що може вимагати серйозних змін до коду. Ця стратегія вимагає попереднього планування та передових знань.
Rebuild. Перебудова ще більше просуває підхід Revise, відкидаючи існуючу кодову базу та замінюючи її на нову. Цей процес займає багато часу і розглядається тільки тоді, коли компанії вирішують, що їхні рішення не відповідають поточним потребам бізнесу.
Replace. Заміна – ще одне вирішення проблем, пов’язаних із підходом Rebuild. Різниця тут у тому, що компанія не переробляє власну програму з нуля, а включає перехід на попередньо створене стороннє додаток, наданий постачальником. Єдине, що ви переносите із свого існуючого додатка, це дані, а все інше в системі нове.
4-етапний план міграції у хмару відповідно до Google Cloud
Перехід у хмару це процес, що складається з послідовних етапів. Фахівці Google Cloud створили універсальний план міграції, який можна використовувати в будь-якій організації, незалежно від мети міграції, обраної стратегії або розміру ресурсів, які необхідно мігрувати.
Щоб допомогти організації ефективно виконати міграцію, ми підготували 4 ключові кроки у контрольному переліку щодо міграції до хмари, заснованому на багаторічному досвіді.
Крок 1: Оцінка збереження даних
Етап оцінки має вирішальне значення перед початком будь-якої міграції. Це ідеальний час, щоб залучити експерта, який допоможе оцінити потреби вашої організації, провести інвентаризацію існуючих даних та програм, вникнути у середовище додатків та інфраструктури, відстежити залежності, рівень споживання чи системні вимоги. Також це етап визначення сукупної вартості володіння (TCO), тобто. загальну вартість обслуговування інфраструктури.
Проведення інвентаризації додатків та технологій
Ключем до ефективної міграції є знайомство з вашим поточним додатком, його компонентами та взаємозв’язками, а також із середовищем виконання. Необхідно «переглянути» програми та ресурси – використовувані технології, бази даних, сховища даних або мережі та відносини між ними. Надважливим результатом роботи на цьому етапі також має стати перелік всіх використовуваних машин разом з їх характеристиками, операційними системами, ліцензіями та способами їх використання програмою.
Організація додатків та ресурсів за категоріями
Переглянувши елементи програм та ресурси компанії, впорядкуйте їх за категоріями. Ви можете створювати власні категорії, однак варто враховувати два фактори:
- критичність елементу (чи буде мати збій міграції негативний вплив на функціонування організації?),
- рівень залежності (чи підключений елемент до бази даних впливає на інші функції?).
Матриця допомагає визначити елементи, які можна перенести насамперед.
Проведення експериментів та створення доказу концепції
Наступним важливим етапом є вибір та реалізація Proof of Concept.
PоC – це тестова версія ІТ-системи, перевірена з точки зору потреб бізнесу та вимог, яким має відповідати остаточна версія програми.
На цьому етапі ваша команда повинна поекспериментувати зі службами Google Cloud Platform, щоб визначити ті з них, які найкраще відповідають вимогам програми та реагують на конкретні ситуації використання.
Області, які можна «дослідити» з GCP:
- робота з надвисокими навантаженнями на віртуальні машини,
- використання брандмауера для комплексного навантаження,
- порівняння продуктивності локальних баз даних із продуктивністю сервісів Cloud SQL, Cloud Spanner, Firestore або Cloud Bigtable,
- перевірка доступності кластерів GKE у різних регіонах,
- оцінка швидкості та стабільності процесу впровадження з використанням різних сервісів GCP.
Розрахунок сукупної вартості володіння (TCO) обох рішень
У загальну вартість володіння входить як ціна придбаних машин, так і вартість хмарних сервісів. При розрахунку сукупної вартості володіння локального рішення слід враховувати вартість живлення машин, мереж, витрати на технічне обслуговування та сервісні роботи.
Калькулятор, підготовлений Google Cloud, допоможе розрахувати сукупну вартість володіння сервісами Google Cloud Platform. Пам’ятайте, що послуги GCP є безсерверними, а це означає, що загальна вартість володіння буде знижена до вартості обслуговування (зазвичай 20-30% внутрішніх витрат).
Визначення ресурсів для першої міграції та тестування
Останнім кроком на етапі оцінки є вибір ресурсів, які в першу чергу потрібно перенести у хмару. Ці кроки призначені для ознайомлення з процесом міграції та тестування додатків у хмарі, тому рекомендуємо обирати прості елементи програми. На наступних етапах ви будете мігрувати все більш складні області з більш високим ступенем важливості для бізнесу.
Які області необхідно поставити в першу чергу?
- некритичні для бізнесу, щоб решта організації не відчула наслідків тестових міграцій в хмарі,
- області з найбільш популярною структурою, що дозволяють використовувати аналогічний шаблон міграції для інших подібних елементів,
- ті, які можуть розширити базу знань та записати хороші практики міграції,
- області, що не мають великої кількості залежностей в інших частинах системи, щоб не довелося відразу вносити численні зміни додатку,
- елементи, що не потребують рефакторингу або потребують не значних змін,
- не вимагають перенесення великих обсягів даних.
Крок 2:планування
Другий етап плану міграції будується на налагодженні середовища, встановленню посвідчень та призначенню ролей та прав доступу. Тобто, на цьому етапі ви будуєте засади власної хмарної інфраструктури. Вкрай важливо слідкувати за тим, щоб не приймати рішення та здійснювати дії, які здатні блокувати деякі шляхи розвитку та еволюції рішення – переконайтеся, що у вас буде змога вносити зміни за потребою.
Підтвердження особи користувачів
IAM (повна назва сервісу: Cloud Identity and Access Management) — центр управління ролями та авторизаціями до ресурсів GCP — дозволяє контролювати доступ до всіх сервісів, що використовуються з однієї панелі. В IAM можна призначати ролі окремим користувачам, службам або групам користувачів.
Типи користувачів, яких можна додати до панелі IAM:
- Обліковий запис Google — обліковий запис користувача для сервісів Google Cloud — приватний користувач (наприклад, власник електронної пошти в домені @gmail.com) або пакет Workspace ,
- група облікових записів Google — група приватних користувачів, які використовують сервіси Google Cloud,
- група облікових записів у домені Workspace — група користувачів у домені Workspace, наприклад, користувачі електронної пошти в домені @fotc.com,
- група облікових записів у домені Cloud Identity — група користувачів, особистість яких підтверджена за рахунок сервісу Cloud Identity,
- сервісний обліковий запис — рівень доступу до сервісів та програм за межами Google Cloud Platform.
- Організація ресурсів
- Після аутентифікації ваших користувачів з хмарними сервісами Google ви можете перейти до створення структури ресурсів за допомогою організації, проекту, папки та сегментів, для яких ви надаєте доступ і призначаєте ролі окремим користувачам або групам.
Приклад розподілу ресурсів у Google Cloud Platform за рахунок проектів та папок
Надання ролей та доступів в IAM
Наступним кроком є надання доступу та можливості для внесення змін до служб та ресурсів Google Cloud Platform. Для міграції вам потрібно призначити наступні ролі:
- адміністратор організації (organization admin) – управляє доступами в IAM-панелі та встановлює ієрархію ролей,
- мережевий адміністратор (network admin) – створює та налаштовує мережі та мережеві пристрої, в т.ч. Cloud Router, Cloud VPN або балансування навантаження у хмарі; додатково керує брандмауерами у співпраці з адміністратором безпеки,
- адміністратор безпеки – встановлює правила та обмеження безпеки для організації та її ресурсів, налаштовує нові ролі для проектів у IAM та веде журнал подій,
- адміністратор білінгу — налаштовує білінгові облікові записи, відстежує вживання ресурсів та витрат у Google Cloud Platform.
Проектування мереж та з’єднань
Останнім кроком третього етапу плану міграції є налаштування вашої мережі та створення з’єднання між вашим існуючим середовищем та Google Cloud. Після створення проектів та призначення ролей вам необхідно створити хоча б одне підключення до віртуальної приватної хмари (VPC – це приватна мережа, що охоплює різні регіони; VPC не використовує публічний інтернет).
VPC дозволить вам сортувати і комбінувати окремі елементи програми, що переноситься. Також необхідно встановити брандмауер, його правила та налагодити моніторинг подій з сервісом Cloud Logging.
Крок 3: реалізація
Цей етап почніть із найменш складних елементів, з невеликим обсягом даних, що не мають великої кількості залежностей і не являються критичними для функціонування організації. У міру просування процесу міграції може з’явитися потреба у перегляді та аналізі основи середовища. Це нормальна практика час від часу озиратися назад, щоб переконатися, що ви не відходите від свого детального плану і наміченого шляху.
У Google Cloud використовується унікальний підхід до перенесення даних ДО початку перенесення всіх програм у хмару. Це необхідно для задоволення різних залежностей, які програми часто мають зі своїми даними. Згідно Google Cloud, після того, як ваші дані були успішно перенесені ви налаштуєте себе на плавну міграцію додатків у майбутньому. На цьому етапі важливо вибрати різні варіанти зберігання, а також будь-які способи передачі. Деякі з кращих варіантів зберігання Google Cloud включають:
- Хмарне сховище Google – висока доступність, єдиний API для всіх класів сховищ і робочих навантажень, швидке та масштабоване з часом до байта всього за мілісекунди, надзвичайно надійне.
- Nearline — підходить для тих, кому потрібна трохи нижча доступність, нижчі витрати на зберігання у стані спокою, підходить для тих, хто планує зчитувати або оновлювати свої дані приблизно раз на місяць, відмінно підходить для архівування даних.
- Локальні твердотільні накопичувачі або постійні диски. Фізичні диски, підключені до серверів, що прискорюють IPOS, можуть бути об’єднані для надання до 3 ТБ дискового простору на екземпляр, але можуть обмежувати доступність, довговічність або гнучкість.
- Google Cloud SQL — це повністю керовані сервіси, що спрощують керування вашими серверами у хмарі. Виконує повсякденні завдання за вас, щоб ви могли зосередитися на створенні та покращенні своїх програм.
- Сховище даних — база даних NoSQL, яка автоматично масштабується та виділяє ваші програми, тому вам ніколи не доведеться турбуватися про великий обсяг навантаження.
- Bigtable — база даних NoSQL, в першу чергу орієнтована на великі дані з надзвичайно низькою затримкою, призначена для обробки великих обсягів даних та безшовної інтеграції з інструментами для роботи з великими даними.
Крок 4: оптимізація
Перехід у хмару не закінчується перенесенням можливих ресурсів. Не менш важливим етапом є процес оптимізації, пошуку та впровадження покращень.
Які області можна оптимізувати після переходу до хмар?
Формування, зміцнення та розвиток команди фахівців
Адміністратори та розробники під час підготовки та проведення міграції отримали цінні знання, які є неоціненними при подальшому використанні потенціалу платформи Google Cloud. Варто подбати про рівень їхньої залученості та креативності, вивчити їх компетенції, поділившись матеріалами з Google Cloud, підтримати підходи до сертифікації, створити бюджет для проведення подальших експериментів або фінансування участі в хакатонах та інших заходах. Чим більша і обізнана команда фахівців, тим більше шансів у всієї організації.
Цілодобовий моніторинг
Безперервний моніторинг сервісів та процесів гарантує, що все працює як слід. Поінформованість про те, що відбувається, також дає поле для внесення покращень, покращення процесів, впровадження нових практик та перевірки впливу змін на середовище та додаток. Моніторинг можна виконувати зі службою Operations (раніше називалася Stackdriver).
Автоматизація процесів та діяльності
Ручні операції, крім того, що вимагають багато часу, несуть певний ризик. Шукайте можливості автоматизації ключових процесів, таких як розгортання та оновлення конфігурації, наприклад, з Cloud Composer або Spinnaker для Google Kubernetes Engine. Це заощадить час вашої команди, витрати на обслуговування рішення і знизить ризик помилки.
Спрощення за допомогою коду
Намагайтеся включити у свій код якомога більше інформації. Введіть такі процеси, як «Інфраструктура як код» (управління інфраструктурою, конфігурацією або процесами з вихідного коду) або «Політика як код» (управління політиками на рівні коду, наприклад, відповідність вимогам або правилам безпеки). Вживання коду дозволить вам краще контролювати середовище, спростити управління та аудит. Це також дасть можливість створювати код за допомогою розробки через тестування та швидко отримувати інформацію про зміну, яку привнесе запланована модифікація.
Вживання автоматично керованих служб замість керованих вручну служб
Google Cloud Platform пропонує безліч сервісів, якими можна керувати автоматично, тим самим розвантажуючі команду та підвищуючи гнучкість та масштабованість upscaling (масштабування вгору) та downscaling (масштабування вниз).
Приклади послуг, якими можна керувати автоматично:
- Хмарний SQL замість ручної роботи кластера MySQL,
- AutoML для розпізнавання та класифікації графіки замість створення та навчання власних моделей машинного навчання,
- виконання впроваджень у Google Kubernetes Engine замість обслуговування власного кластера Kubernetes.
Оптимізація продуктивності та масштабованості
Однією з переваг переходу в хмару є доступ до необмеженого дискового простору та обчислювальної потужності. Їх можна налагодити вручну або автоматично відповідно до вимог програми. Ви можете масштабувати по горизонталі, додаючи або видаляючи віртуальні машини, вузли кластера або екземпляри бази даних, і по вертикалі, змінюючи конфігурацію служби або додаючи інший екземпляр до служби Compute Engine.
Шукаємо можливості скоротити витрати
Google Cloud Platform пропонує чудові можливості для моніторингу споживання та пов’язаних з ним витрат. За допомогою прозорих діаграм, таблиць та звітів ви можете відстежувати в консолі розмір зборів за конкретну послугу, за той чи інший проект, за певний період часу. Варто звернути увагу на портфель безкоштовних сервісів Cost Management, які допомагають відстежувати та прогнозувати витрати.
Google Cloud Platform також пропонує безкоштовні обмеження та знижки: знижки за обов’язкове використання – знижки за зобов’язання використовувати мінімальний рівень ресурсів або Free Tier – пакет безкоштовних послуг, що оновлюється щомісяця.
Деякі послуги, включені в рівень безкоштовного користування:
Як легко мігрувати з FOTC: отримайте ваучер на 500 доларів та професійну підтримку
Так само, яким унікальним є ваш бізнес, унікальним буде і ваш перехід до хмари, коли ви складете детальний план своїх потреб і сплануєте відповідну хмарну стратегію. Якщо вам потрібна допомога на початку вашого особистого шляху до хмари, команда FOTC може допомогти вам. Ми відкриті до дискусії щодо обговорення, як може виглядати міграція в хмару для вас і які саме переваги ви можете отримати, перенісши свій бізнес із локального середовища в хмару. Сертифіковані спеціалісти FOTC допоможуть вам оцінити весь хмарний потенціал, усі хмарні сервіси, обрати рішення та спланувати стратегію з попереднім детальним аналізом, а також нададуть підтримку в процесі міграції та подальшого споживання Google Cloud Platform. Крім того, ви отримаєте ваучер на $500 на перші кроки в консолі GCP. Чекаємо на ваше повідомлення!
