Чему следует научиться из-за сбоя AWS S3

Итак, что мы все извлекли из сбоя AWS на этой неделе? Зависит от того, кого вы спросите. Многие из нас в ИТ считают, что это было хорошим напоминанием о необходимости рассмотреть многооблачные и гибридные облачные среды - по сути, не кладите все яйца облачной рабочей нагрузки в одну корзину AWS. Отказ хранилища S3 затронул около 150 000 веб-сайтов, размещенных в центре обработки данных Amazon-EAST-1, расположенном на севере Вирджинии.

Прекращение работы Amazon напомнило всем ИТ-специалистам, что облачные рабочие нагрузки выполняются за пределами предприятия и могут отключиться в любой момент. Облаку по-прежнему нужен план восстановления, резервного копирования и обеспечения непрерывности. Есть также проверенное временем предостережение о том, что люди по-прежнему используют облачные машины. Сбой S3 на этой неделе произошел, когда инженер допустил командную ошибку во время рутинной задачи по отключению подсистемы хранения.

Но есть и другие способы думать о сбоях в работе провайдера общедоступного облака (которые происходят гораздо реже, чем раньше). Вместо того, чтобы просто сказать, что вы начнете исследовать развертывание мультиоблачных сред или строить больше гибридных облаков, один отраслевой эксперт говорит, что проектирование на случай сбоя - это то, что вам следует учитывать в облачной инфраструктуре. Рекомендуемые советы, которые следует сразу принять во внимание, включают выбор межрегиональной репликации AWS и выполнение тестирования на предмет простоев и решений для восстановления. Долгосрочные советы - выбрать облачный API, который лучше всего подходит для вашего бизнеса, и не подписываться на второго облачного провайдера исключительно по причинам аварийного переключения.

Что касается гибридного облака, в этом рассказе исследуется тенденция бессерверных вычислений. Говорят, что бессерверные вычисления - это, по сути, то же самое, что и вычисления «платформа как услуга» (PaaS). При таком подходе посредник (закупающий оборудование) исчезает, позволяя ИТ-командам выделять ресурсы непосредственно на платформы облачных провайдеров. В конце концов, по словам одного консультанта, ИТ-специалисты предприятия могут выбрать прямое подключение серверных служб к клиентам и клиентским приложениям, чтобы не было так много остановок между пользователями и облачными функциями, которые им нужны.

Конечно, по крайней мере, один облачный провайдер смог почувствовать себя довольным, когда отключение AWS не повлияло на их собственное облако, о чем только что было объявлено на этой неделе. Nimble не хранит свои облачные тома ни в AWS, ни в Azure, потому что это не может гарантировать надежность. Вместо этого он создал проприетарный общедоступный облачный сервис для блочного хранилища. Это может быть хорошо как для продаж Nimble, так и для стабильности их клиентов. Будет интересно посмотреть, положит ли это начало тенденции.

До следующей недели крепко обнимите тех серверов.