Сэм Фарид, инженер-программист из Кремниевой долины, работавший над инфраструктурой мирового масштаба, такой как бессерверная (serverless) платформа Google и система защиты от мошенничества YouTube, обсуждает на портале The New Stack, чего не хватает serverless, чтобы справиться со всей производственной работой DevOps.
Вот типичный, хотя и неприятный, случай сбоя: сеть падает на несколько секунд. Каждое клиентское приложение переходит в автономный режим и ставит запросы клиентов в очередь, а когда все снова начинает работать, все запросы поступают одновременно. Несмотря на то, что вы настроили код приложения с помощью бессерверного сервиса для обработки всплесков трафика от клиентов, этот всплеск трафика больше, чем обычно. Автомасштабирование serverless реагирует удвоением количества экземпляров, но база данных не настроена на обработку такого количества открытых соединений. Это приводит к каскадному сбою: база данных начинает выбрасывать ошибки, что приводит к повторным попыткам выполнения каждого неудачного запроса, что вызывает еще большее автомасштабирование, что...
Остаток дня уходит на изменение размера экземпляров, перенастройку базы данных и судорожное добавление функции экспоненциального отката к вашим клиентам, чтобы избежать DOS в следующий раз. Если повезет, трафик в нерабочее время замедлится настолько, что все вернется на круги своя.
Я поддерживаю «право на ошибку» (blameless postmortem), но в таких ситуациях я склонен спрашивать себя, есть ли в этом моя вина или это следствие нашего стека. В начале своей карьеры я бы винил себя — я должен был лучше разбираться в коде, быстрее реагировать, иметь готовые плейбуки, и тогда все не обернулось бы так.
После того как я перешел на работу с облачными платформами, я убедился, что некоторый процент сбоев является естественной функцией вашего выбора поставщика инфраструктуры.
В описанном сбое база данных выдавала ошибки, потому что не могла справиться с масштабом. Но я бы предположил, что истинной причиной была философия дизайна, лежащая в основе бессерверной технологии: она предлагает функции как услугу с неограниченной масштабируемостью, но именно вы должны убедиться, что все, с чем она соприкасается, может справиться с ее масштабом.
По сути, serverless дает вам достаточно свободы, чтобы все испортить, но недостаточно гибкости, чтобы предотвратить эти ошибки. Это отнюдь не просто запустить и забыть.
Вопрос выбора дизайна особенно усложняется, если рассматривать его с точки зрения альтернатив serverless. Когда команда выбирает serverless для кода своих приложений, она фактически заявляет о своих приоритетах в отношении сервисной и технологической стратегии — желании сосредоточиться на бизнес-логике, а все остальное передать своему облачному провайдеру.
Этот выбор в пользу более управляемой инфраструктуры можно представить в виде спектра с другими распространенными вариантами для новых проектов: Kubernetes и некоторые виды PaaS, такие как Heroku или Elastic Beanstalk от Amazon Web Services.
Тонкая, но зловещая проблема заключается в том, что каждый из этих вариантов страдает сложностью. Serverless — это абстракция, и независимо от того, насколько простой она кажется, проблемы могут возникнуть в любом месте базовой инфраструктуры. Serverless требует меньше всего при настройке, но когда что-то идет не так, требования становятся самыми большими.
Kubernetes знает себе цену, и ему все равно, считаете ли вы его сложным. Вы выбираете Kubernetes за его гибкость, и если вам нужна помощь в управлении им, могут подключиться поставщики.
Serverless находится на противоположной стороне спектра, и его компромиссы имеют смысл только в условиях изоляции. Если бы serverless был согласован с окружающей его экосистемой, он мог бы предотвратить этот сбой. Что если бы он поставлялся с эластичным, глобально доступным уровнем хранения? Что если бы его балансировщики нагрузки ограничили скорость входящих запросов после возникновения ошибок? Что если бы он мог перенастроить количество соединений с базой данных, открытых для каждого экземпляра?
Неважно, что именно, просто это должно быть что-то, а не ничто. Serverless очень близок к тому, чтобы справиться со всей производственной работой DevOps, но он явно не прошел «последнюю милю».
