Эволюция бессерверной архитектуры

Все началось в 1953 году, когда компания IBM выпустила свой первый коммерческий компьютер. И вот сегодня мы обсуждаем бессерверную архитектуру. За прошедшие годы вычислительная техника не только совершила настоящую революцию в том, как строится работа современных компаний, но и претерпела огромные преобразования сама по себе.

После ряда успешных (и не очень) проектов по развертыванию фреймворков на корпоративных инфраструктурах и в облаке, была сформулирована концепция фреймворка FaaS (Function as a Service). Его задача обеспечить запуск приложений в контейнерах без сохранения состояния. Это дает разработчикам возможность сконцентрироваться на самом коде, а не на управлении сложной инфраструктурой и связанными с ней ресурсами. Это привело к изобретению бессерверной архитектуры, ориентированной исключительно на исполнение двоичных файлов приложений, при этом все необходимые ресурсы управляются сторонним провайдером и принадлежат ему. По своей сути бессерверная архитектура позволила предприятиям не только сильнее сосредоточиться на разработке основных приложений, но и существенно снизить накладные расходы.

Однако платформы бессерверных вычислений не только позволили разработчикам быстрее создавать и развертывать приложения, но и привнесли ряд новых проблем с их отладкой по сравнению с традиционными платформами. В этой статье мы рассмотрим методы, проблемы и популярные инструменты отладки, используемые в бессерверной инфраструктуре.

Что такое отладка в бессерверной среде?

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

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

Различия в отладке бессерверных и монолитных приложений

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

В случае монолитных приложений все проблемы можно оттестировать и устранить в локальной среде. Точки отказа обычно возникают на уровне пользовательского интерфейса, серверной части или базы данных. Бессерверные приложения, наоборот, включают в себя множество распределенных, связанных друг с другом компонентов. Поэтому в локальной среде сложно настроить бессерверные приложения и устранить все проблемы, связанные с их работой.

Кроме того, монолитные приложения поддерживают удаленную отладку. Вы можете подключить IDE к удаленным серверам, дав разработчикам привилегированный доступ. Несмотря на то, что это в принципе возможно, применять этот метод целесообразно только в тех случаях, когда локальное моделирование вряд ли даст результаты. Бессерверные приложения по природе своей не поддерживают удаленную отладку в силу отсутствия доступа на уровне ОС и сервера.

Притом что организация процесса тестирования и устранения проблем может потребовать определенных усилий, для монолитного приложения это обычно сделать проще, поскольку каждая задача и функция выполняются в рамках какого-то одного процесса. С другой стороны, бессерверные приложения требуют перехода через границы процессов, при этом зависимость между компонентами обычно очень слаба. Это делает отладку непростой задачей, включающей в себя сбор и анализ огромных объемов данных.

Типы отладочных фреймворков для бессерверных приложений

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

Таким образом, отладочные фреймворки для бессерверных приложений основываются на двух различных подходах с использованием AWS Lambda:

1. Локальная отладка бессерверных приложений

2. Отладка бессерверных приложений для облака

Локальная отладка бессерверных приложений

При разработке ПО важнейшая часть отладки происходит при локальном запуске. Модель бессерверных приложений (SAM) это решение, которое позволяет разработчикам запускать свои приложения локально на бессерверной платформе Amazon на базе AWS Lambda. В пакет решения входит два компонента: спецификация шаблона (SAM Template Specification) и интерфейс командной строки (SAM Command Line Interface). Спецификация шаблона позволяет определить приложение с помощью прав доступа, событий, API-интерфейсов и функций. При этом интерфейс командной строки позволяет вызывать функции локально, осуществлять пошаговую отладку функций, а также упаковывать и развертывать приложения в облаке. Здесь можно ознакомиться с полным руководством по использованию AWS SAM для локальной отладки на платформе AWS Lambda.

Отладка бессерверных приложений для облака

После того как вы развернули приложение в облаке, вам необходимо понять, какие проблемы возникают при подключении функций к сервисам. Некоторые из этих подключений обычно невозможно смоделировать в локальной среде тестирования, поэтому требуется разработка процедуры для тестирования в реальном времени. Вот процедура, которая используется при тестировании в реальном времени для приложения, развернутого в облаке AWS:

• Первый этап тестирование API-шлюза. Вот некоторые из наиболее популярных инструментов для тестирования конечных точек API и шлюзов: SoapUI, Postman и Curl.

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

• На следующем этапе изучается поведение приложения с помощью логов AWS CloudWatch. Функции AWS Lambda по умолчанию настроены на отправку логов в CloudWatch. Затем решение создает для каждой функции класс LogGroup, включающий все события, вызываемые этой функцией. Еще для отслеживания событий приложений можно использовать такие решения как Splunk и ELK.

• На заключительном этапе вы можете провести анализ работы и отладку приложения с помощью AWS X-RAY. Это решение обеспечивает сквозной мониторинг событий и создает графическую визуализацию всех компонентов приложения. Именно эти возможности делают его идеальным инструментом отладки не только в процессе разработки приложений, но и в ходе промышленной эксплуатации.

Популярные средства отладки бессерверных приложений

Вы, конечно, можете отлаживать свое приложение с помощью встроенных средств, таких как CloudWatch и X-RAY, но все же это ручной и весьма утомительный процесс, требующий использования сразу нескольких решений. Однако существуют и самостоятельные инструменты для отладки бессерверных приложений. Они существенно упрощают процесс благодаря интегрированному интерфейсу и удобному процессу очистки всех используемых функций и сервисов. Вот некоторые из этих инструментов:

Faasly.io

FaaSly дает комплексное представление обо всех ваших запросах как на уровне функций, так и на уровне вызовов, используя единую панель. Кроме того, он включает интерактивную карту сервиса (Service Map), выполняющую функцию диспетчерского центра и позволяющую быстро выявить узкие места в работе приложения и легко устранить их.

Встроенная система безопасности Благодаря глубокой интеграции с таким решением корпоративного класса как Envoy, можно достичь высокой степени защиты и соответствия нормативным требованиям благодаря возможности перехватывать каждый сетевой запрос, отправляемый из рабочего приложения AWS Lambda. Если ваши функции в какой-то момент будут скомпрометированы, ваши настоящие учетные данные AWS всегда останутся в безопасности.

Мониторинг без изменения кода Вы можете мгновенно оценить работоспособность своих распределенных систем в режиме реального времени, даже не прикасаясь к отлаживаемому коду.

AWS Cloudwatch

AWS CloudWatch это мощная платформа для мониторинга инфраструктуры и приложений. Она обеспечивает прозрачное представление данных через единый интерфейс, сбор метрик с низким уровнем задержки, возможности анализа данных логов и данных по загруженности ресурсов. CloudWatch также ведет сбор данных, предоставляя достоверную информацию о производительности системы, уровне оптимизации ресурсов, а также работоспособности вашего приложения. Удобные информационные панели, расположенные на одном экране, дают доступ к информации о запущенных сервисах, приложениях и ресурсах.

Инструменты SLS-Dev

Инструментарий Serverless Development Tools это открытый фреймворк с набором инструментов для разработчиков бессерверных платформ и приложений. Этот набор инструментов следует парадигме cloud-native, что способствует ускоренному развитию инноваций и их внедрению в промышленную эксплуатацию. Поскольку этот набор подразумевает оплату по мере использования, вы платите только за фактическое время работы и тестирования своего приложения на платформе. Притом что базовая версия включает почти весь критически важный функционал инструментария, расширенная версия под названием SLS-DevTools Guardian помогает оперативно обнаруживать проблемы по мере их возникновения и проводить отладку в режиме реального времени.

Lumigo

Lumigo это интерфейс для мгновенного доступа к логам и устранения неполадок бессерверных приложений. Платформа предлагает возможности сквозного логирования и мониторинга, что позволяет разработчикам глубже разобраться в тонких моментах выполнения функций и изолировать первопричину проблем в работе приложения. В этот инструмент входит функционал, позволяющий идентифицировать критический путь работы приложения и его точки отказа. Это позволяет повысить эффективность приложения благодаря сокращению задержек.

Dashbird

Если ваше приложение разработано на базе AWS Lambda, то Dashbird должен стать одним из ваших самых любимых инструментов отладки и оптимизации кода. Этот инструмент нацелен на обнаружение ряда распространенных сбоев в работе AWS Lambda, включая проблемы с памятью, тайм-ауты, ошибки времени выполнения, исключения и ошибки конфигурирования. Dashbird также оперативно предупредит вас о сбоях через Slack или по электронной почте и поможет сохранить непрерывную доступность сервиса. Помимо этого, можно интегрировать Dashbird с AWS X-RAY и получать информацию обо всех событиях и вызовах функций.

SignalFX

SignalFx это решение для облачного мониторинга, способное интегрироваться с основными поставщиками услуг, включая Google Cloud Functions, Azure Functions и AWS Lambda. Этот инструмент обеспечивает мониторинг производительности в режиме реального времени и непрерывную прозрачность для всех ваших бессерверных функций. Благодаря обширному списку функций, включающему метрики с малой задержкой, оптимизацию затрат, обнаружение холодного запуска и мониторинг времени выполнения, SignalFx неуклонно набирает популярность в сообществах разработчиков.

Заключительные мысли

Несмотря на то, что бессерверные технологии еще сравнительно молоды, они уже начали трансформировать способы доставки и предоставления приложений. Несмотря на растущую популярность, отладка бессерверных приложений все еще находится в процессе становления, поскольку большинство доступных инструментов пока не интегрировано с другими сервисами и комплексное тестирование на данный момент не реализуемо.

В этой статье мы рассмотрели различные способы выполнения бессерверной отладки как при локальном внедрении, так и в облаке. Мы также рассмотрели ряд наиболее популярных и простых инструментов для отладки бессерверных приложений.

По мере более широкого распространения бессерверных вычислений, мы уже в ближайшие годы наверняка увидим ряд новых подходов и инструментов для отладки. На текущий момент мы рекомендуем использовать инструменты, упомянутые выше. Будем рады узнать, для каких сценариев вы используете бессерверные технологии.

В преддверии старта курса "Microservice Architecture" подготовили для вас традиционный перевод материала.

При проектировании и планировании новой архитектуры на основе (микро) сервисов бывают моменты, когда архитекторам приходится думать о стратегии развертывания и, следовательно, задаваться вопросом: Должны ли мы развернуть этот (микро) сервис как бессерверную функцию или лучше поместить его в контейнер? Или, быть может, лучше использовать выделенную виртуальную машину (VM)?

Как это часто бывает в наши дни, есть только один ответ: Это зависит от обстоятельств. Даже больше это не только зависит, это также может меняться в зависимости. Сегодняшнее оптимальное решение может стать очень неоптимальным через несколько месяцев. При запуске нового приложения выбор бессерверных функций может быть целесообразен, поскольку они быстро настраиваются и требуют относительно небольших предварительных вложений.

Кроме того, их модель оплаты по мере использования (pay per use) очень привлекательна, когда мы не уверены, какая нагрузка придется на наше приложение. Позже, когда сервис станет зрелым и нагрузка станет предсказуемой, может оказаться целесообразным перейти к более традиционной топологии развертывания, основанной на контейнерах или выделенных серверах.

Поэтому при разработке новых систем облачной эпохи важно закладывать некоторое пространство для маневров, то бишь изменений стратегии развертывания различных (микро) сервисов с наименьшими затратами. Правильная инфраструктура в правильное время может результировать в значительной экономии на облачных расходах.

Бессерверные функции

Бессерверные функции (Serverless Functions, также известные как FaaS, функция как сервис) - это блоки определенной логики, которые создаются и выполняются в ответ на заданные события, такие как HTTP-запросы или сообщения, полученные в топике Kafka. По завершении своего выполнения такие функции исчезают, по крайней мере, логически, и их стоимость возвращается к нулю.

Все крупные общедоступные облака имеют FAAS предложения (AWS Lambda, Azure Functions, Google Functions, Oracle Cloud Functions). Кроме того FAAS также могут быть доступны в локальных вариациях с помощью таких фреймворков, как Apache OpenWhisk. У них есть некоторые ограничения с точки зрения ресурсов (например, для AWS максимум 10 ГБ памяти и 15 минут времени выполнения), но они могут покрыть многие варианты использования современных приложений.

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

Преимущества FaaS

Когда бессерверные функции простаивают, они ничего вам не стоят (модель Pay per use). Если бессерверная функция вызывается 10 клиентами одновременно, 10 ее инстансов запускаются почти одновременно (по крайней мере, в большинстве случаев). Полное предоставление инфраструктуры, управление, высокая доступность (по крайней мере, до определенного уровня) и масштабирование (от 0 до лимитов, определенных клиентом) полностью предоставляются командами специалистов, работающих за кулисами.

Бессерверные функции обеспечивают эластичность на стероидах и позволяют сфокусироваться на том, что выделяет ваш бизнес среди других.

Таким образом, FaaS подразумевает два больших преимущества.

• Эластичность на стероидах: масштабирование вверх и вниз по необходимости и оплата только за то, что используется.

• Фокус на том, что отличает ваш бизнес: сконцентрируйте силы на разработке наиболее важных приложений, не тратя драгоценную энергию на сложные области, такие как современные инфраструктуры, которые FaaS предлагает вам в качестве товара.

Эластичность и затраты

Хорошее сервис подразумевает, помимо прочего, стабильно хорошее время отклика. Ключевым моментом здесь является согласованность: она должна быть хорошей как при нормальной, так и при максимальной нагрузке приложения.

Новый сервис должен быстро выходить на рынок с минимально возможными стартовыми вложениями и с самого начала должен быть хорошим сервисом.

Когда мы хотим запустить новый сервис, модель FaaS, вероятно, будет лучшим выбором. Бессерверные функции можно быстро настроить и минимизировать затраты на инфраструктуру. Их модель pay per use подразумевает отсутствие стартовых вложений. Их возможности масштабирования обеспечивают стабильное время отклика при различных уровнях нагрузки.

Если по прошествии некоторого времени нагрузка станет более стабильной и предсказуемой, тогда ситуация может измениться, и более традиционная модель, основанная на выделенных ресурсах, будь то кластеры Kubernetes или виртуальные машины, может стать более удобной, чем FaaS.

Различные профили нагрузки могут вызвать резкую разницу в счетах за облако при сравнении FaaS с решениями, основанными на выделенных ресурсах.

Но насколько большой может быть разница в затратах? Как всегда, это зависит от конкретного случая, но что не вызывает сомнений так это то, что неправильный выбор может иметь большое влияние на счет за облако.

Бессерверные функции могут СЭКОНОМИТЬ ВАМ МНОГО ДЕНЕГ, ровно также как и могут СТОИТЬ ВАМ БОЛЬШИХ ДЕНЕГ

Оценка затрат на облако сама по себе уже становится отдельной наукой, но все равно мы можем почувствовать потенциальные преимущества одной модели над другой, используя прайс-лист AWS на момент написания стаьи.

Пример приложения. Рассмотрим приложение, которое получает 3.000.000 запросов в месяц. Обработка каждого запроса с помощью Lambda с 4 ГБ памяти занимает 500 мс (ЦП назначается автоматически в зависимости от памяти).

FaaS имеет модель pay per use, поэтому, независимо от кривой нагрузки (будь то пиковая или фиксированная), стоимость в месяц является фиксированной: 100,60 долларов США.

С другой стороны, если мы рассмотрим модель, основанную на выделенных виртуальных машинах, все будет по-другому, и стоимость сильно зависит от формы кривой нагрузки.

Сценарий с пиками нагрузки. Если для нагрузки характерны пиковые моменты, и мы хотим гарантировать постоянное хорошее время отклика для наших клиентов, нам необходимо определить размер инфраструктуры, чтобы выдерживать пиковую нагрузку. Если на пике у нас есть 10 одновременных запросов в секунду (что вполне возможно, если 3.000.000 запросов сосредоточены в определенные часы дня или в определенные дни, например, в конце месяца), вполне возможно, что нам понадобится виртуальная машина (AWS EC2) с 8 процессорами и 32 ГБ памяти, чтобы обеспечить ту же производительность, что и Lambda. В этом случае ежемесячная стоимость подскочит до 197,22 долларов США (можно сэкономить при заключении многолетнего контракта, но это снижает финансовую гибкость). Затраты увеличились почти вдвое. Эту разницу можно уменьшить путем динамического включения и выключения экземпляров EC2 в зависимости от нагрузки, но для этого требуется, чтобы нагрузка была предсказуемой, что увеличивает сложность и стоимость решения.

Сценарий с равномерной нагрузкой. Если нагрузка в основном равномерная, то дела обстоят совсем по другому. Если нет пиков, то мы можем легко выдержать нагрузку с помощью гораздо более дешевой машины. Вероятно, будет достаточно виртуальной машины с 2 процессорами и 8 МБ памяти, а ежемесячные затраты в этом случае составят 31,73 доллара США, что меньше трети стоимости Lambda.

Реалистичное экономическое обоснование намного сложнее и требует тщательного анализа, но, просто глядя на эти упрощенные сценарии, становится ясно, что модель FaaS может быть очень привлекательной в некоторых случаях, но может стать очень обременительной при других обстоятельствах. Поэтому очень важно иметь возможность изменять модель развертывания соответствующим образом.

Тут возникает вопрос: как мы можем достичь такой гибкости? Насколько это будет сложно?

Анатомия кодовой базы современного приложения

При использовании современных методов разработки кодовая база приложения обычно разбивается на логические области

• Логика приложения. Код (обычно написанный на таких языках, как Java, TypeScript или Go), который реализует то, что должно делать наше приложение

• DevSecOps (CI/CD). Обычно это скрипты и файлы конфигурации, которые автоматизируют сборку, тестирование, проверки безопасности и развертывание приложения.

Логика приложения

Мы можем разделить логику приложения бэкенд сервиса на логические части

• Бизнес-логика. Код, который реализует поведение службы, выраженное в форме логических API (методов или функций), которые обычно ожидают некоторые данные, например, в формате JSON, в качестве входных и возвращают некоторые данные в качестве выходных. Этот код не зависит от технических механизмов, связанных с реальной средой, в которой он выполняется, будь то контейнер, бессерверная функция или сервер приложения. Находясь в контейнере, эти логические API могут быть вызваны чем-нибудь наподобие Spring Boot (если языком является Java), Express (с Node) или Gorilla (с Go). При вызове в бессерверной функции он будет использовать конкретный механизм FaaS, реализованный конкретным облачным провайдером.

• Код, связанный с развертыванием. Код, который касается механики среды выполнения. Если необходимо поддерживать более одной модели развертывания, должны быть разные реализации этой части (но только этой части). В случае развертывания в контейнерах это та часть, где сосредоточены зависимости от аналогов Spring Boot, Express или Gorilla. В случае FaaS эта часть будет содержать код, реализующий механизмы, определенные конкретным облачным провайдером (функции AWS Lambda, Azure или Google Cloud, которые имеют собственные проприетарные библиотеки для вызова бизнес-логики).

Для обеспечения гибкости стратегии развертывания с минимально возможными затратами крайне важно четко разделять эти две части, что подразумевает:

• Кода, связанный с развертыванием импортирует модули бизнес-логики

• Бизнес-логика никогда не импортирует какие-либо модули/пакеты, которые зависят от конкретной среды выполнения.

Следуя этим двум простым правилам, мы максимизируем объем кода (бизнес-логики), пригодного для использования всеми моделями развертывания, и, следовательно, минимизируем стоимость перехода от одной модели к другой.

Невозможно абстрактно оценить относительные размеры частей бизнес-логики и кода, связанного с развертыванием. Но на примере, анализируя одну простую интерактивную игру, развертываемую как на AWS Lambda, так и на Google Application Engine, выясняется, что код, связанный с развертыванием, составляет 6% от кодовой базы (всего около 7 200 строк кода). Таким образом, 94% кодовой базы одинаковы, независимо от того, работает ли служба в Lambda или в контейнере.

DevSecOps (CI/CD)

Это часть кодовой базы, отвечающая за автоматизацию сборки, тестирования (включая шлюзы безопасности) и развертывания приложения.

Этапы сборки и развертывания по своей природе сильно зависят от фактической среды выполнения, выбранной для выполнения сервиса. Если мы выберем контейнеры, то на этапе сборки, скорее всего, будут использоваться инструменты Docker. Если мы выберем поставщика FaaS, этапа сборки как такового не будет, но будут команды для загрузки кода в механизм FaaS и инструктирования на точке входа при вызове бессерверной функции. Точно так же могут быть проверки безопасности, специфичные для модели FaaS.

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

По-прежнему существует потребность в некоторых этапах тестирования после завершения развертывания, но основная часть тестовой работы, которая является проверкой правильности бизнес-логики, может быть выполнена независимо от развертывания, что значительно повышает продуктивность разработчиков.

Стремитесь изолировать то, что не зависит от модели развертывания, и максимизировать это

Если мы хотим быть гибкими в выборе модели развертывания, мы должны сохранять четкие границы между тем, что относится к коду, связанному с развертыванием, и тем, что является независимым. Это означает, что наши решения нужно продумывать заранее, чтобы минимизировать первое и максимизировать второе, а также обеспечить четкое разделение этих частей на протяжении всего жизненного цикла проекта/продукта, возможно, используя регулярные ревью дизайна и кода.

Заключение

Бессерверные функции представляют собой отличное решение для современных архитектур. Они предлагают самое быстрое время выхода на рынок, самую низкую стоимость входа и самую высокую эластичность. По этим причинам они являются лучшим выбором, когда нам нужно вывести на рынок новый продукт или когда нам приходится сталкиваться с очень непостоянными нагрузками.

Но со временем все может измениться. Нагрузки могут стать более стабильными и предсказуемыми, и в таких обстоятельствах модели FaaS могут оказаться намного дороже, чем более традиционные модели, основанные на выделенных ресурсах.

Поэтому важно сохранять гибкость для изменения моделей развертывания приложений с минимально возможными затратами. Это может быть достигнуто путем обеспечения четкого разделения между тем, что является ядром логики приложения, которое не зависит от платформы, на которой оно работает, и тем, что зависит от конкретной выбранной модели развертывания.

Следуя этим нескольким простым рекомендациям по архитектуре с самого начала и включив регулярные процессы экспертной оценки, мы можем сохранить эту гибкость.

Узнать подробнее о курсе "Microservice Architecture".

Довольно распространенная задача создание превью картинок для сайта из полноразмерных изображений. Автоматизируем этот процесс с помощью триггера для Yandex Object Storage с функцией в Yandex Cloud Functions, которую он будет запускать с наступлением определенного события в бакете в нашем случае, появлением в нем картинки. Функция сделает из нее превью и сохранит в соседний бакет. Возможна вариация сохранения превью в тот же бакет, но с другим префиксом.

Также с помощью триггера в Yandex.Cloud можно задавать действия не только для объектов в хранилище, но и для событий в очереди.

Триггер для Object Storage и Cloud Functions

Для решения этой задачи необходим настроенный бакет в Object Storage, в него будут загружаться файлы и в нем же будет лежать архив с кодом функции. Репозиторий с примером кода можно скачатьтут. После выполнения инструкций из репозитория у вас будет готовая функция, к которой необходимо подключить триггер, срабатывающий на загрузку новых файлов.

В настройках триггера задаем его параметры: название, описание и тип в нашем случае Object Storage. Также указываем бакет, в который будут загружаться картинки. Если дополнительно указать префикс и суффикс объекта, то можно обойтись одним бакетом и для исходных файлов, и для превью.

Далее указываем имя нашей функции, интервал повторных запросов и создаем триггер. Готово, теперь после загрузки картинке будет автоматически создаваться ее превью.

Превью на лету

Но у такого решения есть пара ограничений.

1. Превью создаются только для новых изображений, если картинка уже лежала в бакете, то для нее превью не будет создано.

2. Необходимо заранее определять высоту и ширину превью, чтобы внести изменения в соотношение сторон или размер необходимо заново масштабировать все картинки.

Воспользуемся новой возможностью Yandex.Cloud - runtime для функций C#, чтобы доработать нашу функцию на csharp.

Теперь схема будет работать так.

При первичном обращении за превью:

1. Пользователь запрашивает картинку, указав в URL ее желаемые размеры.

2. Объектное хранилище не находит нужного файла и согласно настроенным правилам, переадресует запрос в функцию.

3. Функция идет за оригинальным изображением в объектное хранилище.

4. Масштабирует его до нужных размеров и сохраняет по ключу, содержащему эти размеры.

5. Сразу отдает готовый файл пользователю.

При последующих обращениях за файлом пользователь будет сразу получать файл из объектного хранилища без вызова функции.

Особенности технической реализации

Прописываем правила переадресации для бакета, чтобы Object Storage и Cloud Functions смогли работать в связке.

s3.putBucketWebsite({ Bucket: "%bucket_name%", WebsiteConfiguration: { IndexDocument: { Suffix: "index.html" }, RoutingRules: [ { Condition: { HttpErrorCodeReturnedEquals: "404", KeyPrefixEquals: "images/" }, Redirect: { HttpRedirectCode: "302", HostName: "functions.yandexcloud.net", Protocol: "https", ReplaceKeyPrefixWith: "%function_id%?path=", } } ] }})

Если объектное хранилище не найдет (HttpErrorCodeReturnedEquals: "404") запрошенный файл с указанным KeyPrefixEquals, то применит указанный ниже редирект. Подробнее можно посмотреть в документации к AWS S3, а скачать готовый код функции можно в репозитории тут.

В Yandex.Cloud удобно реализовано создание функций с помощью CLI. Вам не надо архивировать код и загружать его в объектное хранилище, достаточно лишь сложить все файлы в директорию и указать на нее при создании версии функции в ключе --source-path. Так же вы можете не передавать все node_modules, а загрузить только package.json и выбрать --runtime nodejs12 или --runtime nodejs14. Все зависимости будут подтянуты в момент создания версии функции.

Обращаться к фалам надо не по обычному хосту %bucket_name%.storage.yandexcloud.net, так как редиректы обрабатываться не будут, а через %bucket_name%.website.yandexcloud.net/PREFIX/%width%x%height%/%path%.

Например, при обращении к %bucket_name%.website.yandexcloud.net/images/500x500/cats/meow.png вы получите картинку которую положили в бакет %bucket_name% по ключу images/cats/meow.png но отмасштабированную до размеров 500x500px.

Чтобы не выстрелить себе в ногу

Если не задать значение переменной окружения ALLOWED_DIMENSIONS, то в функции не будут накладываться ограничения на размеры. Это значит, что если будут запрошены много разных вариантов размеров, то все они будут созданы и загружены в объектное хранилище. Поэтому если вы точно знаете, что вам понадобятся определенные размеры картинок лучше их указать. В противном случае, вы быстро израсходуете все свободное пространство хранилища.

Так же, если у вас очень много изображений, можно задать некоторое значение TTL, создать LRU схему кэширования.

P.S.

Любые вопросы по Serverless и Yandex Cloud Functions обсуждаем у нас в Telegram: Yandex Serverless Ecosystem

Полезные ссылки:

• Создание триггера для Object Storage

• Документация по Cloud Functions

• Документация по Yandex Object Storage

Serverless-вычисления и работающие на их основе решения Function-as-a-Service помогают разработчикам развивать продукты, ориентируясь на бизнес-фичи. Мы поэкспериментировали с этими технологиями и пришли к выводу, что для боевого применения существующие решения сыроваты. Пойдём по порядку.

Термин бессерверные вычисления отчасти вводит в заблуждение конечно, в основе продукта сервера остаются, но разработчикам не приходится о них заботиться. По сути своей Serverless продолжает те же идеи виртуализации, что и более ранние aaS-технологии: позволить команде сосредоточиться на коде и развитии функций. Если IaaS это абстракция оборудования, контейнеры абстракция приложений, то FaaS это абстракция бизнес-логики сервиса.

Идея в том, чтобы не паковать в контейнер сервер приложения, базу данных, средства балансировки нагрузки. Разработчики могут изолировать функцию в коде, загрузить её на облачной платформе и запускать её в тот момент, когда она нужна. Выделение инстансов, развёртывание кода и распределение ресурсов, запуск веб-интерфейсов, мониторинг работоспособности, обеспечение безопасности всё это происходит автоматически.

FaaS обеспечивает максимальную гибкость в управлении производительностью во время простоя функция вообще не потребляет ресурсы, а если потребуется, платформа быстро выделяет мощности, которых будет достаточно практически с любой нагрузкой. Обслуживает приложение одного пользователя или сразу сто тысяч производительность системы с FaaS-архитектурой фактически не страдает, а у продукта с традиционной архитектурой обязательно начались бы проблемы.

Команда не беспокоится о бэкенде и процессах деплоя, В идеальных условиях реализация новой фичи сводится к загрузке одной функции на сервер. В результате разработка двигается быстрее, Time-to-Market ползёт вниз. А в компании в целом внедрение FaaS помогает развить платформенный подход для Serverless-вычислений нужен либо пул облачных ресурсов от провайдера, либо Kubernetes-кластер.

Как это работает на практике

На рынке есть уже целый набор Serverless-платформ. Мы внимательно изучили два решения: Lambda от Amazon и KNative. Первое представляет собой проприетарный сервис для работы с облаком Amazon, второе работает поверх Kubernetes.

Amazon Lambda вполне рабочий вариант со всеми возможностями, о которых мы говорили выше. Платформа выполняет все рутинные операции с продуктом, разворачивает приложения, мониторит работоспособность и производительность групп инстансов, обеспечивает отказоустойчивость и масштабирование.

Главное но это проприетарный продукт, а значит вы ограничены амазоновским облаком и вынуждены использовать другие продукты их экосистемы. Если захотите сменить платформу, скорее всего, вам придётся сильно перестраивать продукт, поскольку в новой инфраструктуре правила могут сильно отличаться.

KNative для нас решение более интересное, поскольку оно работает поверх Kubernetes.

В отличие от Lambda, в этом случае используется собственная платформа, приходится глубже погрузиться в архитектуру процесса. Выглядит она так:

• Event source сущность FaaS-платформы, которая взаимодействует с внешними источниками событий. Триггером может быть HTTP-запрос, сообщение от брокера сообщений, событие самой платформы

• Broker корзина, которая принимает и хранит информацию о событиях от Event Source. Брокер может представлять собой модуль Kafka, работать в оперативной памяти и т.п.

• Trigger подписанный на Broker компонент, который достаёт сообщения из корзины и передаёт их на исполнение в Service.

• Service рабочая функция, изолированная бизнес-логика.

С точки зрения разработчика процесс выглядит практически так же, как с уже привычными контейнеризированными приложениями, меняется только объект: (1) написать функцию, (2) упаковать её в Docker-образ, (3) загрузить.

Главный недостаток KNative нет средств логирования и мониторинга, а для FaaS-решений это критически важно. Если ваш продукт разбит на функции, без эффективного мониторинга и логирования быстро установить источник сбоя невозможно, поскольку придётся смотреть на каждую функцию отдельно.

Преимущества FaaS

Лучше всего подход показывает себя, когда не требуется мгновенный ответ пользователю и когда нагрузка может колебаться от 0 до 100%:

• Задачи, которые выполняются по расписанию. Операции экспорта/импорта в системах финансовой отчётности, учётных системах, решениях для создания резервных копий.

• Асинхронная отправка уведомлений пользователю (push, email, СМС).

• Машинное обучение, Интернет вещей, системы ИИ все эти отрасли точно оценят такие возможности. Serverless позволяет выполнять вычисления ближе к эндпойнту, т.е. к пользователю. А значит, у продукта уменьшается задержка, сокращается нагрузка на передачу данных.

Какие можно выделить недостатки Serverless:

1. Такая архитектура плохо подходит для долгосрочных процессов. Если функция используется в приложении практически постоянно, то и потребление ресурсов будет таким же, как у традиционных продуктов.

2. Лучшие платформы на данный момент привязывают компанию к тому или иному облачному провайдеру будь то AWS, Microsoft Azure или Google Cloud. Решениям для Kubernetes ещё предстоит подрасти до этого уровня.

3. FaaS это не волшебная таблетка, с которой разработчики могут забыть об инфраструктуре и просто отправлять на прод фичи. Всё равно нужно продумывать архитектуру, проектировать функции и их взаимодействие с помощью DDD. Иначе продукт превращается в массу сильно связанных между собой функций, в которых будет сложно разобраться. Разработчики не смогут деплоить такие функции и менять по отдельности. В худшем случае при обработке пользовательских запросов пользователя придётся поднимать все функции.

Наш вывод до эпохи Serverless ещё несколько лет

При условии, что разработчики будут развивать это направление, в частности развивать open source платформы до уровня того же Amazon Lambda.

Мотивацией таких проектов может быть сокращение затрат на ресурсы, улучшение управления большими энергозатратными продуктами. Но на данный момент разработчикам может быть проще работать по старинке. Владение Serverless и умение использовать эти инструменты это хороший багаж, до боевого применения компаниям стоит подождать пару лет.

Когда мы говорим о бессерверной архитектуре, мы обычно выходим далеко за рамки модели функция как услуга (FaaS), одной из реализаций которой являются функции AWS Lambda.

Причин высокой привлекательности AWS Lambdaдве: первая автоматическое масштабирование (причем в обе стороны), вторая возможность оплаты по факту использования. Тем не менее, чтобы в полной мере использовать эти возможности и все преимущества бессерверной архитектуры, другие компоненты инфраструктуры должны обладать такой же гибкостью.

Как же будет выглядеть такого рода архитектура в интернет-проекте?

Мы вTheodo очень любим бессерверные технологии и внедряем их во всё новые и новые проекты. Какие-то сервисы и модели мы применяем наиболее широко. Поэтому мы решили поделиться опытом в разработке архитектуры веб-приложений. Если бессерверные технологии вам в новинку и хотелось бы получить общие рекомендации и ответы на вопросы, то вы обратились по адресу!

Откровенный и вопиющий спойлер (не бойтесь, мы успеем погрузиться в каждый аспект темы):

На схеме вверху каждый блок это стандартная четко выделенная область применения или техническая возможность, характерная для большинства бессерверных архитектур. Это необязательно будут микросервисы или стеки, если говорить на языке CloudFormation (это мы обсудим чуть позже).

Мы рекомендуем полномасштабный переход на AWS Lambda c использованием событийных микросервисов, написанных на TypeScript

Наша задача создать надежную, полностью управляемую систему, с которой разработчикам будет удобно работать. Чтобы ее построить, мы выбрали:

Amazon Web Services

Конкурентный рынок облачных технологий весьма насыщен: AWS, GCP, Azure, IBM Cloud, Alibaba Cloud каждая из этих компаний предлагает свое замечательное решение и развивается беспрецедентно высокими темпами.

Бен Эллерби (Ben Ellerby) сравнил трех крупнейших облачных провайдеров в этой статье: мы отдали предпочтение решениям AWS. С точки зрения бессерверных технологий они оказались самыми продвинутыми. Именно решения AWS позволяют нам максимально приблизиться к полностью бессерверной архитектуре. Чтобы это проиллюстрировать, в следующей части статьи мы подробно рассмотрим каждый из AWS-сервисов, входящих в состав наших архитектурных блоков.

Node.js с использованием TypeScript

JavaScript это один из самых популярных языков программирования в мире, с огромным сообществом разработчиков (посмотрите статистику на GitHub). Мир бессерверных вычислений не сильно выпадает из этой статистики. Например,по данным Datadog, 39% всех развернутых сегодня систем AWS Lambda работает на JavaScript, хоть Python и лидирует с 47%. TypeScript делает еще один шаг вперед и добавляет к JavaScript еще один замечательный уровень защиты. И наконец, JavaScript отлично работает в AWS Lambda с подавляющим большинством сценариев использования!

Serverless Framework

Именно в этом фреймворке по большей части реализуется практика IaC (инфраструктура как код) поверхCloudFormation. Задав функцию AWS Lambda, которая будет реагировать на HTTP-событие, Serverless Framework автоматически развернет связанный ресурс API-шлюза, а также соответствующий маршрут вместе с новой функцией AWS Lambda. Затем, когда будет достигнута предельная емкость фреймворка и нам понадобится более сложная конфигурация сервисов, мы сможем легко добавить CloudFormation.

C гордостью сообщаем: команда Theodo настолько уверовала в Serverless Framework, что решиластать официальным партнером фреймворка!

Узкоспециализированные функции AWS Lambda

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

разделение на микросервисы

Чтобы не заставлять команды разработчиков толкаться и мешать друг другу, не раздувать файлы package.json и serverless.yml до немыслимых размеров (кстати, в CloudFormation довольно щедрое ограничение на число ресурсов 500), не тратить много времени на развертывание CloudFormation, а также лучше ориентироваться в базе кода и четко разграничивать ответственность между функциями AWS Lambda, мы устанавливаем границы и разделяем проект на отдельные микросервисы.Бен Эллерби написал здесь о полезной методологии мозгового штурма под названием EventBridge Storming, которая как раз и помогает определить эти границы.

В нашем монорепозитории: 1 микросервис = 1 стек CloudFormation = 1 файл serverless.yml + 1 файл package.json. Кроме того, микросервисы управляют своими собственными сущностями данных и не предоставляют их в общее пользование другим микросервисам.

Раньше мы рекомендовали переходить на полноценный JavaScript, однако есть множество причин, по которым вам, возможно, захочется использовать другой язык. А может быть, вы предпочтете поэтапно перейти на бессерверные вычисления на чистом JavaScript. Неоспоримое преимущество микросервисов при бессерверных вычислениях заключается в том, что можно легко комбинировать технологии в рамках архитектуры, сохраняя ее простоту и согласованность, а также не зависящие от используемых технологий интерфейсы между микросервисами.

взаимодействие на языке событий

Эти микросервисы должны быть полностью независимыми друг от друга если один из них перестанет работать или претерпит кардинальные изменения, остальные компоненты системы не должны из-за этого сильно страдать. Чтобы это стало возможно, функции Lambda общаются друг с другом исключительно через бессерверную шину событий EventBridge. Вэтой статье Бен Эллерби (это снова он) подробно рассказывает о том, что делает сервис EventBridge таким полезным.

Для каждого типа функций требуется особая бессерверная архитектура с конкретным набором AWS-сервисов

Установив контекст, давайте пройдемся по архитектурным блокам приведенной выше устрашающей диаграммы и посмотрим, какие самые бессерверные сервисы можно найти в AWS.

Фронтенд (разработка)

Наш сияющий бессерверный бэкенд должен каким-то образом скармливать данные фронтенду. Чтобы облегчить фронтенд-разработку при использовании AWS, мы используемAmplify.

Amplify это сразу несколько полезных вещей: инструмент CLI, инструмент IaC, SDK, а также набор UI-компонентов. Мы используем при разработке фронтенда JS SDK, чтобы ускорить интеграцию с ресурсами (например, Cognito для аутентификации), развернутыми при помощи других инструментов IaC, таких как Serverless Framework.

Хостинг сайтов

Большинство современных веб-сайтов это одностраничные приложения (Single Page Applications, SPA). Это полнофункциональные динамические приложения, упакованные в единый набор статических файлов, которые загружает пользовательский браузер, когда он впервые обращается к URL-адресу. В среде AWS мы размещаем эти файлы на файловом хранилищеS3и предоставляем к нему доступ через CDN-сетьCloudFront.

Тем не менее тенденция явно склоняется в пользу SSR-сайтов, использующих отрисовку на стороне сервера, как в случае технологии Next.js. Для настройки SSR-сайта в бессерверной инфраструктуре мы используемLambda@Edgeвнутри CloudFront. Это позволяет реализовать отрисовку на стороне сервера, располагая функции AWS Lambda как можно ближе к конечным пользователям. Чтобы погрузиться в тему, прочитайтеэту статью.

Домен и сертификат

Разумеется, для нашего сайта мы не можем довольствоваться необработанным автоматически сгенерированным S3-адресом, поэтому мы формируем сертификаты и привязываем их к CloudFront с помощьюCertificate Manager, а затем для управления доменами используемRoute 53.

Бизнес-API

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

Как мы уже говорили, мы используем событийную логику, то есть быстро отвечаем пользователям, а параллельно, так сказать за кадром, продолжаем обрабатывать пользовательский запрос в асинхронном режиме. DynamoDB, например, предоставляет доступ к потокам, которые могут асинхронно вызвать Lambda-функции в качестве реакции на любое изменение данных. Большинство бессерверных сервисов поддерживают аналогичную возможность.

DynamoDB это огромная отдельная тема, и вэтой статьеРоб Кронин (Rob Cronin) дает обнадеживающий комментарий о классических проблемах, связанных с широко известной базой данных NoSQL.

Асинхронные задачи

Управление нашей архитектурой устроено при помощи событий, поэтому многие Lambda-функции асинхронны и запускаются событиями EventBridge и S3, потоками DynamoDB и так далее. Например, у нас может быть асинхронная Lambda-функция,которая будет отвечать за отправку пользователю приветственного письма после успешной регистрации.

Обработка отказов играет решающую роль в распределенной асинхронной системе. Поэтому в случае асинхронных Lambda-функций мы используем DLQ очередь недоставленных сообщений и передаем окончательное сообщение об отказе сначала в службу уведомленийSNS (Simple Notification Service), а затем в службу очередейSQS (Simple Queue Service). Сейчас нам приходится поступать так, потому что на данный момент невозможно привязать SQS напрямую к DLQ-очереди Lambda-функций.

Передача пуш-сообщений от бэкенда к фронтенду

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

Загрузка файлов

Поскольку обработка потока загружаемых файлов из Lambda-функции может оказаться весьма дорогостоящим делом, в S3 Lambda-функции могут сгенерировать подписанный (защищенный) URL-адрес загрузки, который будет использоваться нашим фронтендом для прямой загрузки файлов в S3. Приятный момент заключается в том, что в данном случае (как и в большинстве сервисов AWS) можно сделать другую асинхронную Lambda-функцию, которая будет слушать изменения файла S3 и обрабатывать любые последующие операции.

Пользователи и аутентификация

В Cognitoесть все, что нам нужно: аутентификация, управление пользователями, контроль доступа, а также интеграция с внешним поставщиком удостоверений. Хоть этот сервис и славится тем, что с ним сложновато работать, это компенсируется большим набором возможностей. Ну и как обычно, у него есть выделенный SDK для взаимодействия с Lambda-функциями и он умеет отправлять события, запускающие Lambda-функции.

В нашем примере мы проиллюстрируем возможность привязать собственныеавторизаторы Cognito к нашим маршрутам API-шлюза. Мы также назначили одну Lambda-функцию для обновления аутентификационных токенов, а другую для получения списка пользователей.

Здесь я бы хотел предостеречь: Cognito еще не готов к тому, чтобы ему можно было полностью доверить управление сущностью пользователя. У него есть ряд ограничений, например по числу поддерживаемых атрибутов. Если для вас важна гибкость, пожалуй, лучше хранить пользовательские атрибуты в DynamoDB.

Машина состояний

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

Мы объявляем машину состояний через CloudFormation включая любые последующие шаги и состояния, все ожидаемые либо неожиданные результаты и назначаем этим шагам некие стандартные действия (например, wait или choice) либо Lambda-функцию (выбираем изподдерживаемых интеграций). Затем мы можем в реальном времени, используя интерфейс AWS, следить за работой машины (на основе логов). На каждом из этих шагов мы можем задать обработку повторных и неудачных попыток. Бен Эллерби более подробно описал сервис в этой статье.

Чтобы привести более конкретный пример, предположим, что мы хотим реализовать email-рассылку помощью SaaS и убедиться, что все сообщения были высланы адресатам.

• Шаг 1 Lambda: дает SaaS указание выполнить email-рассылку и получает в ответ идентификатор рассылки.

• Шаг 2 Task Token Lambda: получает callback-токен от Step Function, связывает его с идентификатором рассылки, а затем ждет обратного вызова от SaaS.

• Шаг 3 (внепотока) Lambda: вызывается перехватчиком из SaaS при изменении статуса рассылки (ожидание, архивация, неудача, успех) и возобновляет поток по статусу кампании, используя соответствующий callback-токен.

• Шаг 4 выбор: в зависимости от статуса, если рассылка еще не была успешно выполнена, вернуться к шагу 2.

• Шаг 5 (заключительный) Lambda: обновляет данные о пользователях после рассылки.

В этой статье хорошо объяснено, как работают токены Task Token.

Безопасность

Управление идентификацией и доступом (Identity & Access Management, IAM) эта система нужна для того, чтобы филигранно управлять всеми AWS-доступами со стороны разработчиков, конвейеров CI/CD, а также сервисов AWS, которые обращаются друг к другу. Поначалу это может выглядеть пугающе, однако преимущество тут в широких возможностях тонкой настройки. Они позволяют нам хорошо продумать и детализировать любое действие, которое мы хотим разрешить конкретному потребителю. Это означает, что каждый уровень нашей инфраструктуры защищен по умолчанию.Бен Эллерби выступал на ServerlessDays Nashville на эту тему.

Что касается данных повышенной секретности, таких как API-ключ SaaS, то мы безопасно храним их вSystems Manager (в Parameter Store). Запрашиваем мы эти данные из наших файлов в Serverless Framework или в CloudFormation или даже напрямую из исходного кода (при помощи соответствующего SDK). Полезно упомянуть, что системаSecrets Managerвыполняет аналогичные действия. Такжев данном случае полезен сервисKey Management Service (KMS) он помогает нам управлять ключами шифрования.

Если вас заинтересовала эта тема,Sat G написалотличную обзорную статью о безопасности в бессерверной среде там можно найти более полную информацию.

Мониторинг

Мы де-факто используем CloudWatchв качестве службы мониторинга. Все сервисы AWS автоматически поддерживают простейшие метрики и логи, которые отсылаются в CloudWatch и дают нам базовую информацию. Однако мы можем пойти гораздо дальше: отправлять пользовательские метрики и логи, создавать информационные панели, устанавливать срабатывание сигналов тревоги при достижении пороговых значений, выполнять сложные запросы вглубь данных и отображать их на графиках произвольного формата.

Мы не прекращаем поиск альтернативных вариантов.X-Ray, например, комплексно отслеживает весь путь запросов в рамках нашей распределенной системы, а затем красочно отображает его в динамике. Иногда, правда, он сбивается со следа, поскольку пока еще не поддерживает некоторые сервисы, такие как EventBridge (а это как раз центральный элемент нашей архитектуры). Еще один сервис,ServiceLens, развертывается поверх X-Ray и CloudWatch и выглядит потрясающе. Есть также ряд перспективных внешних (с точки зрения AWS) решений: Thundra, Epsagon, Lumigo. Однако мы еще не успели в полной мере их опробовать.

Команда Theodo гордится тем, что добавила собственный компонент в экосистему: если вы хотите повысить у себя качество разработки и уровень наблюдаемости, вам обязательно стоит попробовать инструментServerless-Dev-Tools.

Бессерверные вычисления это потенциал, способный перерасти в успех, и мы хотим вам помочь сделать решительный шаг в его сторону

Мир бессерверных вычислений развивается не просто быстро, а очень быстро. Вступая в этот мир, вы словно открываете для себя совершенно новую вселенную, полную ошеломляющих возможностей, где столько всего еще предстоит сделать, и это поистине захватывающе!

Команда Theodo каждую неделю открывает для себя новые сервисы, инструменты и модели. Вот почему я намерен постоянно обновлять и актуализировать эту статью, чтобы идти в ногу со временем и делиться нашими лучшими передовыми наработками.Подпишитесь на меня в Твиттере обещаю, будет много всего интересного!

Рассказав вам об основных понятиях бессерверной архитектуры, мы хотим продемонстрировать, насколько она дешевле классической!Для этого мы создаликалькулятор расходов: заполните всего несколько полей, и вы узнаете, во сколько обойдутся вам бессерверные вычисления.

Я, безусловно, продолжу работать над всеми этими темами, поэтому, если вам интересно,напишите мне в твиттер.

Надеюсь, что в этой статье вы нашли ответы на интересующие вас вопросы. Я буду чрезвычайно рад ответить на любые вопросы, получить ваши отзывы и улучшить рекомендации, предложенные в этой статье.

П.С. От переводчика

Присоединяйтесь к сообществу Serverless в Telegram:Yandex Serverless Ecosystem. Мы регулярно встречаемся в виртуальном пространстве и похоже созревает потребность в очной встрече.