Category: AWS Serverless Application Model

Распространённый функционал в Amazon SQS – это очереди необрабатываемых сообщений (DLQ). DLQ используется для хранения сообщений, которые не могут быть обработаны потребителем. Данный пост описывает как добавить отказоустойчивости в автоматизированном режиме к вашим SQS очередям. Этот механизм мониторит DLQ и отправляет сообщения обратно в основную очередь, чтобы проверить возможность их повторной обработки.

В этом посте, я приведу пример архитектуры на основе событий, и покажу как её построить на основе Amazon SNS FIFO топиков и Amazon SQS FIFO очередей. Бывает, что события должны передаваться всем приложениям-адресатам в строгом порядке. При помощи Amazon SNS FIFO топиков и Amazon SQS FIFO очередей, вы можете построить приложение, с требованиями по строгой очередности доставки сообщений, фильтрации, дедупликации и шифрованию.

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

В этой статье мы рассмотрим три наиболее полезные паттерна обмена сообщениями, используемые разработчиками бессерверных приложений, – это очереди, модель «издатель – подписчик» (Pub/Sub) и шина событий. В AWS, эти паттерны реализованы в соответствующих сервисах: Amazon SQS, Amazon SNS и Amazon EventBridge. Все эти сервисы являются полностью управляемыми и высоко-доступными, без необходимости управлять базовой инфраструктурой.

Из этой статьи вы узнаете, как создавать приложения на PHP без необходимости использования веб-сервера. Мы покажем, как настроить Amazon CloudFront, чтобы безопасно обслуживать запросы пользователей и кэшировать статические файлы из приватного бакета Amazon S3. Динамические запросы направляются в Amazon API Gateway, а из него – в функцию AWS Lambda. Комбинация этих сервисов используется для замены традиционного веб-сервера в приложениях на PHP.

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

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

В первой части этой серии было представлено веб-приложение Ask Around Me, которое позволяет пользователям в реальном времени отправлять вопросы другим пользователям, находящимся поблизости. В этом посте мы рассмотрим архитектуру бэкенда, HTTP API в Amazon API Gateway, а также имплементацию гео-хеширования (geohashing).

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

Рассказываем о HTTP API для Amazon API Gateway — сервисе для построения безопасных, масштабируемых API, созданном с нуля, чтобы быть быстрее, дешевле и проще в использовании.