Бессерверный. Скорее всего, вы уже сталкивались с этим термином, но что именно он означает? Начнем с того, что бессерверные или серверные вычисления на самом деле не означают отсутствие серверов, поскольку они есть, а скорее означают тот факт, что ответственность за управление, масштабирование, предоставление, обслуживание и т.д. этих ресурсов теперь лежит на облачных провайдерах, таких как AWS Lambda, Google Cloud Platform, Microsoft Azure и других. Бессерверные вычисления могут стать огромным преимуществом для организаций, у которых нет необходимых ресурсов или команд для управления физическими ресурсами, такими как серверы/оборудование, и всеми сопутствующими операциями по обслуживанию и лицензированию, что позволяет им сосредоточиться на разработке кода и приложений.
Преимущества бессерверной модели
В бессерверной архитектуре, когда разрабатываются приложения, они обычно состоят из множества различных сервисов. Когда они развертываются в ответ на запрос, эти сервисы развертываются как отдельные функции, также известные как FaaS, или функции как сервис. Опять же, преимущество заключается в том, что код внутри ваших контейнеров или виртуальных машин управляется поставщиком облачных услуг. Больше не нужно беспокоиться об обслуживании, исправлениях или масштабировании. К другим преимуществам бессерверной архитектуры относятся следующие:
Стоимость
Очевидно, что без необходимости арендовать или покупать физические серверы, организациям может быть выгоднее отказаться от традиционного способа управления физической инфраструктурой и платить только за время и память, используемые для работы кода/приложений.
Масштабируемость
Как мы уже говорили ранее, большая часть ответственности за управление ресурсами сервера возлагается на облачного провайдера, включая масштабирование вверх и вниз. Разработчикам не нужно тратить дополнительное время на тонкую настройку системы или обращаться за поддержкой к другим командам, поскольку все это делается автоматически с помощью облачного провайдера.
Фокус на разработке приложений
Поскольку большая часть управления, обслуживания и политик передана облачному провайдеру, разработчики могут сосредоточить свои усилия на совершенствовании своих приложений.
Недостатки бессерверной модели
В переходе на бессерверную архитектуру есть много интересного, но могут быть и некоторые недостатки по сравнению с традиционной, монолитной моделью. Основной проблемой является отсутствие доступа к метрикам базовой инфраструктуры. Другим фактором является то, что бессерверные приложения являются распределенными, а иногда и на разных облачных платформах, что затрудняет управление процессом. Организации должны решить, с чем они готовы расстаться при переходе к бессерверной среде. Среди других недостатков бессерверной модели можно назвать следующие:
Лимиты ресурсов
В связи с тем, что модель serverless основана на принципе оплаты, существуют ограничения на ресурсы, которые можно использовать, и на то, как долго могут выполняться код, запросы и другие сторонние ресурсы. Для рабочих нагрузок, требующих высокой производительности, организациям лучше приобрести собственные серверы.
Сроки реагирования
Когда код не используется, облачные провайдеры обычно снижают его скорость. Однако когда наступает время запроса ресурсов, может возникнуть задержка во времени, необходимом для того, чтобы код снова заработал. Приложения, постоянно работающие на выделенном сервере, не так сильно страдают от задержек.
Безопасность и конфиденциальность
Вы можете подумать, что передача контроля над ресурсами вашего сервера крупному облачному провайдеру сделает его более безопасным, но это не обязательно так. Хотя поставщики облачных услуг делают все возможное для защиты клиентов от атак и уязвимостей, общий объем компонентов и элементов, которые необходимо защищать, намного превышает тот, который необходим для традиционной инфраструктуры. И
Мониторинг
В бессерверных средах мониторинг может быть сложнее, поскольку вы теряете видимость и контроль над внутренними показателями производительности ваших приложений. Это также может затруднить точное определение того, как и сколько с вас берут за ресурсы для работы ваших приложений. А для того, чтобы выяснить, где возникла проблема, вы все еще можете копаться в сотнях страниц и группах журналов, чтобы найти ее.
Мониторинг бессерверных приложений
Не имея контроля над всем стеком приложений, как в традиционной системе, мониторинг в бессерверных средах может быть немного сложным. Не имея представления о метриках на стороне сервера, времени рендеринга и сбоях производительности на уровне элементов, может быть сложно устранить проблемы, когда они возникают. Даже если ваши приложения работают в бессерверной среде, все равно есть элементы, которые необходимо отслеживать в производстве. Вы не можете просто установить и забыть об этом. Вам, вероятно, придется устранять любые непредвиденные проблемы и, очевидно, оптимизировать производительность вашего приложения. Есть несколько вещей, на которые следует обратить внимание, и мы обсудим их ниже.
Ошибки
Очевидно, что вы захотите знать, когда приложения или запросы терпят неудачу, а также что стало причиной их отказа, поэтому ошибки являются критическим фактором для мониторинга. Иногда ошибки происходят незаметно. Может пройти несколько дней, прежде чем кто-то заметит, что критический шаг или компонент приложения не работает.
Задержка
Время, которое проходит между действием и ответом, является задержкой. Например, в случае веб-приложения это может быть время, которое проходит после того, как пользователь нажимает кнопку отправки формы. Очень важно знать время, которое проходит между успешным и неудачным запросом, поскольку это ключевой фактор для общего впечатления пользователя. В бессерверных средах, когда ваше приложение не запущено, оно дросселируется, поэтому дополнительные ресурсы не используются, и вы не платите. Однако, когда оно снова запускается, может возникнуть некоторая задержка во времени, необходимом для обработки необходимых ресурсов. Это известно как «холодный старт». Если холодных запусков много, это может повлиять на удобство работы пользователей.
Трафик
Трафик — это количество запросов к вашей системе, которое, в зависимости от услуги, обычно составляет HTTP-запросы в секунду.
Мониторинг бессерверных приложений с помощью Dotcom-Monitor
Провайдеры бессерверных вычислений, такие как AWS Lambda, позволяют развертывать веб-сайты, веб-приложения и API из выбранных вами регионов, однако необходимо также контролировать эти сайты и веб-приложения из этих же регионов, чтобы знать, что они работают так, как задумано.
Решения на платформе Dotcom-Monitor позволяют организовать мониторинг веб-сайтов, веб-приложений и API на основе браузера. Настройте мониторы по местоположению, с заранее определенными порогами производительности и оповещениями о времени работы, чтобы вы точно знали, когда ваши приложения или сайты работают не так, как ожидалось. Кроме того, наше решение для мониторинга веб-приложений вместе с EveryStep Web Recorder дает вам возможность создавать сценарии многоэтапных пользовательских транзакций, таких как процесс корзины или формы и страницы входа, и отслеживать этапы на предмет непредвиденных ошибок. EveryStep Web Recorder легко добавляет дополнительные возможности мониторинга, такие как мониторинг проверки ключевых слов. Вы можете узнать, как проводить мониторинг ключевых слов в этой статье Wiki. Если они есть, вы получите немедленное уведомление, чтобы вы могли устранить проблему до того, как она затронет большее количество пользователей. Ознакомьтесь со всеми решениями Dotcom-Monitor.
Заключение: Мониторинг бессерверных приложений
Время — это деньги. А когда вы платите облачным провайдерам за работу ваших приложений по миллисекундам, каждая секунда на счету. Аналогичным образом, опыт работы пользователей с вашими приложениями может привести к заключению или расторжению сделки. Убедитесь, что ваши пользователи получают наилучшие возможности, и обязательно отслеживайте работу приложений и сайтов на предмет непредвиденных простоев и проблем, связанных с производительностью.
Попробуйте всю платформу Dotcom-Monitor бесплатно в течение 30 дней!
