Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Узнайте о роли шаблона автоматического выключателя в защите от сбоев и повышении отказоустойчивости в распределенных средах в AWS.
Бессерверная архитектура — это способ создания и запуска приложений без необходимости управления инфраструктурой. Вы пишете свой код, а поставщик облачных услуг делает все остальное — предоставление ресурсов, масштабирование и обслуживание. AWS предлагает различные бессерверные сервисы, среди которых AWS Lambda является одним из наиболее известных. Когда мы говорим о « бессерверности », это не означает отсутствие серверов. Вместо этого ответственность за обслуживание сервера переходит от пользователя к поставщику. Этот сдвиг приносит несколько преимуществ:
- Экономическая эффективность: при использовании бессерверной системы вы платите только за то, что используете. Неиспользуемые мощности отсутствуют, поскольку выставление счетов основано на фактическом объеме ресурсов, потребляемых приложением.
- Масштабируемость: бессерверные службы автоматически масштабируются в соответствии с потребностями приложения. По мере увеличения или уменьшения количества запросов к приложению сервис плавно настраивается.
- Снижение эксплуатационных расходов: разработчики могут сосредоточиться исключительно на написании кода и выпуске обновлений, а не беспокоиться об обслуживании сервера.
- Ускоренный выход на рынок: без необходимости управлять инфраструктурой циклы разработки короче, что обеспечивает более быстрое развертывание и итерацию.
Важность устойчивости в бессерверной архитектуре
Как бы чудесно ни звучало бессерверное решение, оно не застраховано от сбоев. Устойчивость — это способность системы обрабатывать сбои и восстанавливаться после них, и она жизненно важна в бессерверной среде по нескольким причинам:
- Безгражданство: бессерверные функции не сохраняют состояние, то есть они не сохраняют никаких данных между выполнениями. Хотя это способствует масштабируемости, это также означает, что любой сбой в функции или серверной службе, от которой она зависит, может привести к несогласованности или потере данных, если их не обработать должным образом.
- Сторонние сервисы. Бессерверные архитектуры часто полагаются на различные сторонние сервисы. Если в какой-либо из этих служб возникнут проблемы, ваше приложение может пострадать, если оно не рассчитано на такие ситуации.
- Сложная оркестровка. Бессерверное приложение может включать в себя сложное взаимодействие между различными службами. Для их надежной координации требуется надежный подход к обработке ошибок и механизмам возврата.
Поэтому устойчивость не просто желательна, но и необходима. Это гарантирует, что ваше бессерверное приложение останется надежным и удобным для пользователя, даже если некоторые части системы выходят из строя. В последующих разделах мы рассмотрим шаблон автоматического выключателя — шаблон проектирования, который повышает отказоустойчивость и отказоустойчивость в распределенных системах , например тех, которые построены на бессерверных технологиях AWS.
Понимание схемы автоматического выключателя
Представьте себе шумный город, где движение движется плавно, пока не происходит авария. В ответ светофоры адаптируются к изменению маршрута автомобилей, предотвращая полный тупик. Аналогичным образом, при разработке программного обеспечения мы используем шаблон автоматического выключателя — механизм, предназначенный для предотвращения общесистемных сбоев. Его основная цель — обнаружить сбои и остановить поток запросов к неисправной детали, подобно тому, как светофор останавливает автомобили, чтобы избежать заторов. Если определенная служба или операция не выполняются должным образом, срабатывает автоматический выключатель, и будущие вызовы этой службы блокируются или перенаправляются.
Этот шаблон важен, поскольку он допускает постепенное ухудшение функциональности, а не полный сбой системы. Это похоже на план действий на случай чрезвычайной ситуации: если что-то пойдет не так, шаблон гарантирует, что остальная часть приложения сможет продолжать работать. Он обеспечивает период восстановления для вышедшей из строя службы, при этом не добавляется никакой дополнительной нагрузки, что позволяет выполнить потенциальное самовосстановление или дает разработчикам время для решения проблемы.
Связь между схемой выключателя и отказоустойчивостью в распределенных системах
Во взаимосвязанном мире распределенных систем, где сервисы зависят друг от друга, отказоустойчивость является краеугольным камнем надежности. Шаблон автоматического выключателя играет в этом ключевую роль, гарантируя, что сбой в одной службе не распространится на другие. Это буфер, который поглощает удары от вышедшего из строя компонента. Отслеживая количество недавних сбоев, шаблон решает, когда следует разомкнуть «цепь», тем самым предотвращая дальнейшие повреждения и поддерживая стабильность системы.
Идея проста, но эффективна: при достижении порога отказа схема отключается, останавливая поток запросов к проблемной службе. Последующие запросы либо возвращаются с заранее определенным резервным ответом, либо ставятся в очередь до тех пор, пока служба снова не будет признана работоспособной. Такой подход не только защищает систему от перехода в состояние зависания, но и защищает пользователей от повторяющихся ошибок.
Актуальность шаблона автоматического выключателя в микросервисной архитектуре
Архитектура микросервисов подобна сложной экосистеме с многочисленными видами — многочисленными сервисами, взаимодействующими друг с другом. Подобно тому, как процветание экосистемы зависит от баланса, так и архитектура микросервисов зависит от устойчивости отдельных сервисов. Схема автоматического выключателя особенно актуальна в таких средах, поскольку она обеспечивает необходимые сдержки и противовесы для обеспечения поддержания этого баланса.
Учитывая, что микросервисы часто проектируются так, чтобы быть слабосвязанными и независимо развертываемыми, сбой одного сервиса не должен привести к выходу из строя всей системы. Шаблон автоматического выключателя позволяет службам корректно обрабатывать сбои, повторяя операции, перенаправляя трафик или предоставляя резервные решения. Это не только улучшает работу пользователей во время частичных сбоев, но и дает разработчикам уверенность в том, что они смогут быстро выполнять итерации, зная, что существует механизм безопасности для решения непредвиденных проблем.
В современных приложениях, где время безотказной работы и удовлетворенность пользователей имеют первостепенное значение, реализация шаблона автоматического выключателя может означать разницу между незначительным сбоем и полномасштабным прерыванием обслуживания. Признавая его жизненно важную роль в поддержании работоспособности экосистемы микросервисов , разработчики могут создавать более надежные и отказоустойчивые приложения, способные противостоять неизбежным проблемам, связанным с распределенными вычислениями.
Использование AWS Lambda для отказоустойчивых бессерверных микросервисов
Когда мы говорим о бессерверных вычислениях, AWS Lambda часто оказывается в центре внимания. Но что такое AWS Lambda и почему она меняет правила игры при создании микросервисов? По сути, AWS Lambda — это сервис, который позволяет запускать код без подготовки серверов и управления ими. Вы просто загружаете свой код, и Lambda позаботится обо всем, что необходимо для запуска и масштабирования вашего кода с высокой доступностью. Это мощный инструмент в наборе инструментов бессерверной архитектуры, поскольку он абстрагирует управление инфраструктурой, позволяя разработчикам сосредоточиться на написании кода.
Теперь разработчики DST Global предлогают посмотреть, как схема выключателя вписывается в эту картину. Схема автоматического выключателя направлена на предотвращение перегрузок системы и каскадных сбоев. При интеграции с AWS Lambda он отслеживает вызовы внешних сервисов и зависимостей. Если эти вызовы неоднократно терпят неудачу, автоматический выключатель срабатывает и дальнейшие попытки временно блокируются. Последующие вызовы могут быть перенаправлены на резервный механизм, гарантируя, что система останется отзывчивой, даже если какая-то ее часть неисправна.
Лучшие практики от разработчиков DST Global использования AWS Lambda в сочетании с шаблоном автоматического выключателя
Чтобы получить максимальную выгоду от использования AWS Lambda с шаблоном автоматического выключателя, рассмотрите следующие рекомендации:
- Мониторинг и ведение журналов. Используйте Amazon CloudWatch для мониторинга показателей и журналов функции Lambda для раннего обнаружения аномалий. Знание того, что ваши функции близки к отключению автоматического выключателя, может предупредить вас о потенциальных проблемах до того, как они обострятся.
- Тайм-ауты и логика повторных попыток: реализуйте тайм-ауты для функций Lambda, особенно при вызове внешних служб. В сочетании с логикой повторных попыток тайм-ауты могут гарантировать, что ваша система не зависнет на неопределенный срок, ожидая ответа, который может никогда не прийти.
- Надежные резервные варианты: создавайте свои функции Lambda так, чтобы они имели запасную логику на случай, если основной сервис будет недоступен. Это может означать предоставление кэшированных данных или упрощенную версию вашего сервиса, позволяющую вашему приложению оставаться функциональным, хотя и с ограниченными возможностями.
- Разделение сервисов. Используйте такие сервисы, как Amazon Simple Queue Service (SQS) или Amazon Simple Notification Service (SNS), для разделения компонентов. Такой подход помогает поддерживать отзывчивость системы даже в случае сбоя одного компонента.
- Регулярное тестирование. Регулярно проверяйте автоматические выключатели, моделируя отказы. Это гарантирует, что они будут работать должным образом во время реальных сбоев, и поможет вам усовершенствовать стратегии реагирования на инциденты.
Интегрируя шаблон автоматического выключателя в функции AWS Lambda, вы создаете надежный барьер против сбоев, которые в противном случае могли бы распространиться на ваши бессерверные микросервисы. Взаимодействие между AWS Lambda и шаблоном автоматического выключателя заключается в их общей цели: предложить отказоустойчивый и высокодоступный сервис, ориентированный на предоставление функциональности, независимо от неизбежных сбоев, возникающих в распределенных системах.
Хотя AWS Lambda освобождает вас от операционных накладных расходов на управление серверами, реализация таких шаблонов, как автоматический выключатель, имеет решающее значение для обеспечения того, чтобы это удобство не достигалось за счет надежности. Следуя этим рекомендациям, вы сможете с уверенностью использовать AWS Lambda для создания бессерверных микросервисов, которые не только эффективны и масштабируемы, но и устойчивы к непредвиденным обстоятельствам.
Реализация шаблона автоматического выключателя с помощью пошаговых функций AWS
AWS Step Functions позволяет организовать и координировать компоненты бессерверных приложений. С помощью AWS Step Functions вы можете определить рабочие процессы как конечные автоматы, которые могут включать последовательные шаги, логику ветвления, параллельные задачи и даже шаги вмешательства человека. Эта услуга гарантирует, что каждая функция знает свою команду и выполняется в нужный момент, способствуя бесперебойной работе.
Теперь давайте добавим в эту хореографию паттерн автоматического выключателя. Когда на каком-либо этапе вашего рабочего процесса возникает проблема, например, тайм-аут API или ограничение ресурсов, в дело вступает автоматический выключатель. Интегрируя шаблон автоматического выключателя в функции шагов AWS, вы можете указать условия, при которых произойдет «отключение» цепи. Это предотвращает дальнейшую нагрузку на систему и позволяет ей восстановиться или перенаправить поток на альтернативную логику, которая решает проблему. Это очень похоже на партнершу по танцу, которая изящно импровизирует движение, когда исходная программа не может быть исполнена из-за непредвиденных обстоятельств.
Чтобы реализовать этот шаблон в AWS Step Functions, вы можете использовать такие функции, как политики Catch и Retry, в определениях вашего конечного автомата. Они позволяют вам определить поведение обработки ошибок для конкретных ошибок или обеспечить скорость отсрочки, чтобы избежать перегрузки системы. Кроме того, вы можете настроить резервное состояние, которое действует при отключении цепи, гарантируя, что ваше приложение останется отзывчивым и надежным.
Преимущества использования AWS Step Functions для реализации шаблона автоматического выключателя многочисленны. Прежде всего, это повышает надежность вашего бессерверного приложения, предотвращая эскалацию сбоев. Вместо того, чтобы позволить единственной точке отказа вызвать эффект домино, автоматический выключатель изолирует проблемы, давая вам время для их устранения, не влияя на всю систему.
Еще одним преимуществом является снижение затрат и повышение эффективности. AWS Step Functions позволяет платить за переход вашего конечного автомата. Это означает, что, избегая ненужных повторных попыток и снижая нагрузку во время простоев, вы сохраняете не только свою систему, но и свой кошелек.
И последнее, но не менее важное: улучшаются ясность и удобство обслуживания ваших бессерверных рабочих процессов. Определив четкие правила и резервные варианты, ваша команда сможет мгновенно понять ход действий и знать, куда обращаться, если что-то пойдет не так. Это ускоряет отладку и улучшает общий опыт разработки.
Включение шаблона автоматического выключателя в AWS Step Functions — это больше, чем просто техническая реализация; речь идет о создании хореографии, в которой учитывается каждый шаг, а за каждой ошибкой есть процедура восстановления. Это гарантирует, что ваша бессерверная архитектура будет корректно работать под нагрузкой, сохраняя надежность, которую ожидают пользователи и от которой зависит бизнес.
Заключение
Среда бессерверной архитектуры динамична и постоянно развивается. Эта статья дала фундаментальное понимание. В нашем путешествии по тонкостям бессерверной архитектуры микросервисов на AWS мы столкнулись с мощным союзником в виде шаблона автоматического выключателя. Этот механизм имеет решающее значение для повышения отказоустойчивости системы и обеспечения способности наших бессерверных приложений противостоять непредсказуемому характеру распределенных сред.
Разработчики DST Global начали с изучения концепции бессерверной архитектуры AWS и ее многочисленных преимуществ, включая масштабируемость, экономическую эффективность и упрощение оперативного управления. Мы поняли, что, несмотря на многочисленные преимущества, отказоустойчивость остается важнейшим аспектом, требующим внимания. Признавая это, мы исследовали шаблон автоматического выключателя, который служит защитой от сбоев и повышает отказоустойчивость в наших распределенных системах. Особенно в архитектуре микросервисов он действует как дозорный, отслеживая ошибки и предотвращая каскадные сбои.
Наше исследование позволило нам глубже изучить практические аспекты реализации с помощью AWS Step Functions и то, как они изящно организуют бессерверные рабочие процессы. Интеграция шаблона автоматического выключателя в эти функции позволяет сделать обработку ошибок более надежной и реактивной. Благодаря AWS Lambda мы увидели еще один уровень надежности, добавленный к нашим бессерверным микросервисам, где шаблон автоматического выключателя можно умело применять для управления исключениями и поддержания непрерывности обслуживания.
Инвестирование времени и усилий в обеспечение надежности наших бессерверных приложений заключается не только в предотвращении простоев; речь идет о построении доверия с нашими пользователями и экономии затрат в долгосрочной перспективе. Приложения, способные корректно решать проблемы и поддерживать операции в условиях необходимости, выделяются на современном конкурентном рынке. Уделяя приоритетное внимание надежности с помощью таких шаблонов, как автоматический выключатель, мы не только смягчаем последствия сбоев отдельных компонентов, но также повышаем общее удобство работы пользователей и поддерживаем непрерывность бизнеса.
В заключение отметим, что возможности шаблона автоматического выключателя в бессерверной среде невозможно переоценить. Это свидетельство идеи о том, что при наличии правильных стратегий даже самые, казалось бы, непреодолимые проблемы можно превратить в возможности для роста и инноваций. Наша задача как архитекторов, разработчиков и новаторов — использовать эти шаблоны и принципы для создания отказоустойчивых, быстро реагирующих и надежных бессерверных систем, которые смогут поднять наши приложения на новую высоту.
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Ижевск, ул. Воткинское шоссе, д. 170 Е, Технопарк Нобель, офис 1117
Задать вопрос по почте
Вот у меня есть хостер. Х лет он был нормальный, я ему исправно платил, а он исправно работал и не создавал проблем.
И вот хостер начал творить дичь. Смена владельца, оптимизация, скачок цен, закрытие направления, уход команды технарей, на которых все держалось и вот это всё.
Я делаю дампы дисков и разворачиваю их у нового хостера. Гудбай май лав, оставайся со своими тараканами, а я голосую ногами.
Денёк возни и вся моя контора снова работает и забываает о прошлвх проблемах.
А теперь представьте, что у меня серверлесс. По деньгам столько же или больше, по возможности свалить — полная безнадега.
В чем выгода мне и моей конторе?
Основной принцип бессерверных технологий заключается в том, что вам не нужно заботиться об управлении и масштабировании инфраструктуры, вы платите только за то, чем пользуетесь. Под эти критерии подходит множество сервисов — AWS DynamoDB, S3, SNS или SQS, Graphcool, Auth0, Now, Netlify, Firebase и многие другие. В целом, бессерверность подразумевает использование всех возможностей облачных вычислений без необходимости управления инфраструктурой и её оптимизации ради масштабирования. Также это означает, что безопасность на уровне инфраструктуры больше не ваша проблема, а это огромное преимущество, учитывая трудность и сложность соблюдения стандартов безопасности. Наконец, вам не нужно покупать предоставленную вам в пользование инфраструктуру.
Бессерверность можно считать «состоянием разума»: определённой ментальностью при проектировании решений. Избегайте подходов, требующих обслуживания любой инфраструктуры. При бессерверном подходе мы тратим время на решение задач, которые непосредственно влияют на проект и приносят выгоду для наших пользователей: создаём устойчивую бизнес-логику, развиваем пользовательские интерфейсы и разрабатываем адаптивные и надёжные API.
К примеру, если можно избежать управления и сопровождения платформы свободного текстового поиска, то именно так мы и поступим. Такой подход к сборке приложений способен сильно ускорить вывод продукта на рынок, ведь вам не нужно больше думать об управлении сложной инфраструктурой. Избавляйтесь от обязанностей и расходов на управление инфраструктурой и сосредоточьтесь на создании приложений и сервисов, которые нужны вашим клиентам. Патрик Дебуа назвал такой подход ‘servicefull’, этот термин принят в бессерверном сообществе. Функции нужно рассматривать как связующее звено для сервисов в виде развёртываемых модулей (вместо развёртывания целой библиотеки или веб-приложения). Это обеспечивает невероятную гранулярность управления развёртыванием и изменениями в приложении. Если вы не можете таким образом развёртывать функции, то это может говорить о том, что функции выполняют слишком много задач и должны быть отрефакторены.
Некоторых смущает зависимость от вендора при разработке облачных приложений. То же самое и с бессерверными технологиями, и вряд ли это следствие заблуждения. По нашему опыту, создание бессерверных приложений на AWS в сочетании со способностью AWS Lambda объединять другие AWS-сервисы — всё это отчасти и формирует достоинства бессерверных архитектур. Это хороший пример синергии, когда результат объединения получается больше, чем просто сумма слагаемых. Пытаясь избежать зависимости от вендора, вы можете столкнуться с ещё большими проблемами. При работе с контейнерами проще управлять собственным уровнем абстракции между облачными провайдерами. Но когда речь заходит о бессерверных решениях, усилия не будут окупаться, особенно если с самого начала учитывать экономическую эффективность. Обязательно выясните, как вендоры обеспечивают предоставление услуг. Некоторые специализированные сервисы зависят от точек интеграции с другими вендорами, и из коробки могут предоставлять возможность подключения в стиле plug-and-play. Проще обеспечить вызов Lambda из конечной точки API шлюза, чем проксировать запрос в какой-то контейнер или экземпляр EC2. Graphcool обеспечивает простое конфигурирование с помощью Auth0, а это проще, чем использовать сторонние средства аутентификации.
Выбор правильного вендора для вашего бессерверного приложения — это решение архитектурного уровня. При создании приложения вы не рассчитываете, что однажды вернётесь к управлению серверами. Выбор облачного вендора ничем не отличается от выбора использования контейнеров или базы данных, или даже языка программирования.
Обдумайте:
— Какие сервисы вам нужны и почему.
— Какие сервисы предоставляют облачные провайдеры и как вы можете объединить их с помощью выбранного FaaS-решения.
— Какие языки программирования поддерживаются (с динамическим или статическим типизированием, компилируемые или интерпретируемые, какие есть бенчмарки, какая производительность при холодном старте, какова open source-экосистема и т.д.).
— Каковы ваши требования по безопасности (SLA, 2FA, OAuth, HTTPS, SSL и т.д.).
— Как управлять вашим CI/CD и циклами разработки ПО.
— Преимуществами каких решений класса infrastructure-as-code вы можете воспользоваться.
Если вы расширяете имеющееся приложение и инкрементально добавляете бессерверные функции, то это может несколько ограничить доступные возможности. Однако почти все бессерверные технологии предоставляют какие-то API (через REST или очереди сообщений), позволяющие создавать расширения независимо от ядра приложения и с простой интеграцией. Ищите сервисы с понятными API, хорошей документацией и сильным сообществом, и не ошибётесь. Простота интеграции зачастую может быть ключевой метрикой, и, вероятно, это одна из главных причин успеха AWS с тех пор, как в 2015-м вышла Lambda.
Благодаря экономии расходов и простоте масштабирования, бессерверные решения одинаково применимы как для внутренних систем, так и для внешних, вплоть до веб-приложения с многомиллионной аудиторией. Счета измеряются скорее не в евро, а в центах. Аренда самого простого экземпляра AWS EC2 (t1.micro) в течение месяца обойдётся в €15, даже если вы ничего с ним не делаете (кто ни разу не забывал выключить?!). Для сравнения, чтобы достичь такого уже уровня расходов за тот же период времени, вам потребуется запустить Lambda размером 512 Мб на 1 секунду примерно 3 миллиона раз. А если вы не используете эту функцию, то ничего не платите.
Так как бессерверная технология зависит преимущественно от событий, можно довольно легко добавить в старые системы бессерверную инфраструктуру. Например, с помощью AWS S3, Lambda и Kinesis вы можете создать аналитический сервис для старой розничной системы, который сможет получать данные через API.
Большинство бессерверных платформ поддерживают разные языки. Чаще всего это Python, JavaScript, C#, Java и Go. Обычно во всех языках нет никаких ограничений по использованию библиотек, так что можете применять свои любимые open source-библиотеки. Однако желательно не злоупотреблять зависимостями, чтобы ваши функции выполнялись оптимально и не обнуляли преимущества огромной масштабируемости ваших бессерверных приложений. Чем больше пакетов нужно загрузить в контейнер, тем дольше будет выполняться холодный запуск.
Холодный запуск — это когда необходимо сначала инициализировать контейнер, среду исполнения и обработчик ошибок, прежде чем ими пользоваться. Из-за этого задержка выполнения функций может достигать 3 секунд, а это не лучший вариант для нетерпеливых пользователей. Однако холодные запуски бывают при первом обращении спустя несколько минут простоя функции. Так что многие считают это незначительным неудобством, которое можно обойти с помощью регулярного пингования функции, чтобы поддерживать ее на холостом ходу. Или вообще игнорируют этот аспект.
Хотя AWS выпустила бессерверную SQL-базу данных Serverless Aurora, всё же SQL-базы не идеальны для подобного применения, ведь при выполнении транзакций они зависят от подключений, которые могут быстро стать узким местом при большом трафике на AWS Lambda. Да, разработчики постоянно улучшают Serverless Aurora, и вам стоит поэкспериментировать с ней, однако сегодня для бессерверных систем гораздо лучше подходят NoSQL-решения вроде DynamoDB. Впрочем, несомненно, что эта ситуация очень скоро изменится.
Инструментарий тоже накладывает немало ограничений, особенно в сфере локального тестирования. Хотя и существуют решения вроде Docker-Lambda, DynamoDB Local и LocalStack, однако они требуют кропотливой работы и значительного объёма конфигурирования. Впрочем, все эти проекты активно развиваются, так что это лишь вопрос времени, когда инструментарий достигнет необходимого нам уровня.
Влияние бессерверных технологий на цикл разработки
Поскольку ваша инфраструктура представляет собой просто конфигурацию, можно задать и развернуть код с помощью скриптов, например, shell-скриптов. Или можно прибегнуть к решениям класса configuration-as-code вроде AWS CloudFormation. Хотя этот сервис и не предоставляет конфигурацию для всех сфер, но зато позволяет определять конкретные ресурсы для использования в качестве Lambda-функций. То есть там, где CloudFormation вас подведёт, вы можете написать свой ресурс (Lambda-функцию), который закроет эту брешь. Таким образом вы можете сделать что угодно, даже сконфигурировать зависимости за пределами вашего AWS-окружения.
Поскольку всё это просто конфигурация, вы можете параметризовать ваши скрипты развёртывания под конкретные окружения, регионы и пользователей, особенно если применяете решения класса infrastructure-as-code вроде CloudFormation. Например, вы можете развернуть копию инфраструктуры для каждой ветки в репозитории, чтобы полностью изолированно тестировать их в ходе разработки. Это радикально ускоряет получение разработчиками обратной связи, когда хотят понять, адекватно ли работает их код в живом окружении. Руководителям не нужно беспокоиться о стоимости развёртывания многочисленных окружений, ведь оплачивается только фактическое использование.
У DevOps становится меньше забот, поскольку им нужно лишь удостовериться, что у разработчиков корректная конфигурация. Больше не нужно управлять инстансами, балансировщиками или группами безопасности. Поэтому всё чаще применяют термин NoOps, хотя всё ещё важно уметь конфигурировать инфраструктуру, особенно когда речь идёт об IAM-конфигурации и оптимизации облачных ресурсов.
Есть очень мощные инструменты для мониторинга и наглядного представления вроде Epsagon, Thundra, Dashbird и IOPipe. Они позволяют отслеживать текущее состояние бессерверных приложений, предоставляют журналы и трассировку, регистрируют метрики производительности и узкие места архитектуры, выполняют анализ и прогнозирование расходов, и многое другое. Они не только дают DevOps-инженерам, разработчикам и архитекторам исчерпывающее представление о работе приложений, но и позволяют руководителям отслеживать ситуацию в реальном времени, с посекундными расходами на ресурсы и прогнозированием затрат. Организовать такое с управляемой инфраструктурой гораздо труднее.
Проектировать бессерверные приложения значительно проще, потому что вам не нужно развёртывать веб-серверы, управлять виртуальными машинами или контейнерами, патчить серверы, операционные системы, интернет-шлюзы и т. д. Абстрагирование от всех этих обязанностей позволяет бессерверной архитектуре сосредоточиться на главном — на решении потребностей бизнеса и клиентов.
Хотя инструментарий мог быть и лучше (он улучшается с каждым днём), однако разработчики могут сосредоточиться на реализации бизнес-логики и наилучшем распределении сложности приложения по разным сервисам в пределах архитектуры. Управление бессерверными приложениями выполняется на основе событий и абстрагировано облачным провайдером (например, SQS, S3-события или DynamoDB-потоки). Поэтому разработчикам достаточно лишь прописать бизнес-логику для реакции на определённые события, и можно не беспокоиться о том, как лучше реализовать базы данных и очереди сообщений, или как организовать оптимальную работу с данными в конкретных аппаратных хранилищах.
Код можно выполнять и отлаживать локально, как и при любом процессе разработки. Модульное тестирование остаётся прежним. Возможность развёртывать целую инфраструктуру приложения с помощью настраиваемой конфигурации стека позволяет разработчикам быстро получать важную обратную связь, не думая о стоимости тестирования или о влиянии на дорогие управляемые окружения.
И хотя бессерверный подход не лишён недостатков, однако существуют надёжные методики паттерны проектирования, с помощью которых можно создать устойчивые бессерверные приложения или интегрировать бессерверные элементы в имеющиеся архитектуры.