Чому Вашому сайті електронної комерції потрібен активний-активний підхід мульти-хмари цього святкового сезону

Для лідерів електронної комерції свята приносять дві певності: величезний приплив покупців і підвищений ризик виходу з ладу постачальників хмарних послуг. Великі порушення хмарних послуг здаються все частішими і більш руйнівними. Регіон AWS US-East-1, наприклад, має історію значних порушень під час святкового сезону. Аналогічно, кожного року близько січня, Microsoft Azure має тенденцію мати проблеми з затримкою мережі або виходом з ладу мережі через свій план випуску або тестування в певних регіонах. І нам потрібно тільки глянути назад на червень минулого року, коли велике порушення Google Cloud вплинуло на широкий спектр застосунків, щоб бути нагадуваним, що жоден окремий постачальник не є імунним.

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

Застосунки мульти-хмари

Якщо ваша організація платить за послуги AWS, Azure і GCP, у вас справді є всі три хмари у вашому розпорядженні. Тоді як ви можете використовувати всі три, важливо вивчити, що відбувається, коли ви йдете на один рівень глибше. Чи деякі з ваших застосунків специфічні для AWS, Azure чи GCP? Чи вони продовжать працювати, якщо один постачальник хмарних послуг вийде з ладу і вам потрібно швидко переключитися на інший?

Ваш застосунок повинен працювати ідеально на будь-якій з хмар. Це те, що таке справжній мульти-хмарний набір. Якщо ви хочете бути хмарно-агностичним, ви не можете просто платити за мульти-хмари; вам потрібно переконатися, що ваші застосунки також мульти-хмарні.

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

Масштабування до активного-активного підходу

Це вимагає серйозної підготовки від DevOps. Це неймовірно складно мати 100% точну стратегію бізнес-continuity та відновлення після катастроф (BCDR), оскільки коли справа доходить до виконання ваших операцій в режимі реального часу, існує кілька точок виходу з ладу. Ви не хочете тестувати свою стратегію BCDR під час виходу з ладу, тому вам може здатися, що все, що ви можете зробити, – це передбачити можливі сценарії, а потім підготуватися відповідно.

Моя порада інженерам з надійності сайту – архітектурно проектувати з виходом з ладу за замовчуванням. Це означає наявність вторинної або навіть третинної хмари, що працює в активному стані. Стратегія BCDR, обмежена одним постачальником, – це одна точка виходу з ладу; якщо контрольна площина постачальника або мережевий хребет вийде з ладу, весь ваш план відновлення буде безсиллим.

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

Цей активний-активний підхід означає, що у вас є повністю працюючий продукт, дублікат, який працює в іншому місці. Якщо ваш первинний постачальник хмарних послуг переживає серйозне погіршення або порушення, ви можете безперебійно переключити 100% вашого трафіку на вторинного постачальника через DNS або глобальний балансувальник, роблячи його основною точкою входу без порушення для ваших клієнтів.

Справжня вартість не переходу на мульти-хмари

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

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

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

Остатні думки

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

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