Так получилось, что до 2020 года я не имел дело с облаками. Когда же, наконец, углубился в эту тему, то немного потерялся от обилия сервисов, предлагаемых в AWS.  Необходимо было создать приложение с такими фичами: В этой статье описаны сервисы, которые понадобились мне для реализации проекта и ощущения от процесса.
 Бизнес-логика нашего приложения реализована в виде веб-сервиса и помещена в докер-контейнер. Для запуска контейнеров в AWS можно использовать два сервиса Fargate и Elastic Beanstalk. Модный PaaS поверх ECS или EKS (EKS-Elastic Kubernetes Service, ECS-Elastic Container Service — проприетарная альтернатива kubernetes). Конфигурация выполняется путем описания высокоуровневой абстракции — задачи (Task), в которой указывается необходимое количество вычислительных ресурсов для ваших контейнеров. Появился задолго до Fargate. Позволяет запустить приложение на виртуалках (EC2). В том числе есть конфигурация и для старта докер-контейнера. Из недостатков — сложен в конфигурировании, виртуалки медленно создаются. Из преимуществ — цена. Elastic Beanstalk значительно дешевле при небольших средних нагрузках. Еще один небольшой плюс Elastic Beanstalk — возможность мониторить сетевой трафик виртуалок. В Fargate я так и не разобрался как это сделать. И Fargate, и Elastic Beanstalk предусматривают возможность горизонтального масштабирования. В обоих случаях балансировщик нагрузки конфигурируется автоматически. Предполагается, что вы не меняете настройки балансировщика напрямую. В Fargate масштабирование описывается в Task Definition, Elastic Beanstalk создает Auto Scaling Group. Application Load Balancer работает на уровне HTTP. В принципе он может обрабатывать и HTTPS, но, так как он находится за CloudFront, то нам это не требуется. От ALB на инстансы идет уже только HTTP. Для хранения состояния используются три сервиса. NoSql база данных. Работает очень быстро (в пределах 10–20 миллисекунд на запрос). Поддерживает условные обновления, что позволяет организовать оптимистическую транзакционность. Хранилище файлов. Практически безразмерное. Позволяет открыть прямой доступ из интернета. Таким образом пользователи могут заливать и скачивать контент без использования вычислительных ресурсов сервиса нашего приложения. Хранилище настроек сервиса. Позволяет хранить ключи в зашифрованном виде. Технически, в облаке каждый сервис выставлен в интернет, так что, при наличии прав, клиент может обращаться к нему напрямую. Например, в нашем приложении, клиент напрямую заливает медиа-файлы в S3.  В остальных же случаях взаимодействие клиента с бэкендом идет через описанные ниже сервисы. DNS от AWS. CDN от AWS. В настройках CloudFront задаются правила по перенаправлению запросов к медиа-контенту на S3, а api-вызовов на наш веб-сервис. Также здесь можно настроить редирект с Http на Https (понадобится отдельный публичный S3 bucket с правилом редиректа). AppSync — часть большой перспективной концепции — AWS Amplify. Позволяет быстро разрабатывать мобильные приложения с serverless-бэкендом или даже no-code-бэкендом. Наше приложение не такое “модное”, но мы не могли пройти мимо AppSync, так это чуть ли не единственный сервис AWS, позволяющий публиковать и подписываться на сообщения. Отвечает в aws за регистрацию и авторизацию пользователей. Позволяет создать User Pool c привязкой к аккаунтам в Google, Amazon, Facebook и не только.  Сервисы для базовых девелоперских операций представлены на следующей схеме.

Управление доступом к сервисам и ресурсам осуществляется с помощью IAM-Identity and Access Management. Для автоматизации развертывания ресурсов используется CloudFormation, как с помощью шаблонов, так и из программного кода, с помощью SDK. Единица управления ресурсами называется стеком. Конвейер обновления версий кода создается с помощью группы сервисов: Все логи накапливаются в CloudWatch. Там же, в пару кликов мыши, можно настроить алерты и дашборды для мониторинга. Итак, для того, чтобы запустить веб-приложение, понадобилось 9 сервисов AWS, а для того, чтобы настроить девелоперские операции — еще 8 сервисов. Следует отдать должное AWS, они максимально уменьшили порог вхождения, документации и примеров — предостаточно, но все же 17 раз пришлось разбираться с логикой проприетарного сервиса!  Когда я начинал, то не думал, что мне это может понравится. Я сопротивлялся. Так, например, закодил самостоятельно механизм jwt-аутентификации, вместо того, чтобы использовать Cognito.  Но я поменял свое мнение. Все же приятно сбросить с плеч груз инфраструктурного кода и сконцентрироваться на бизнес-логике. Немного освоившись, я начал испытывать чувства ребенка в парке аттракционов. Каждый новый сервис — новое веселье. Я рад, что этот парк пока не исследован до конца. Для себя я принял решение, что я здесь надолго.