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

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

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

Мультихмарні застосунки

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

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

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

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

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

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

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

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

Правdziва вартість не мультихмарного підходу

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

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

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

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

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

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