Должен ли я использовать AWS SAM для «простых» лямбда-функций? - PullRequest
Новая
       32

Должен ли я использовать AWS SAM для «простых» лямбда-функций?

1 голос
/ 07 января 2020

В настоящее время я использую SAM для некоторых из моих серверных приложений. У меня также есть «более простые» лямбда-функции, для которых не требуется API-шлюз или более сложная интеграция со службами AWS.

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

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

Есть ли хороший способ управлять этими маленькими лямбда-функциями? Или мне нужно просто принять использование SAM для них?

Ответы [ 2 ]

2 голосов
/ 08 января 2020

Вы должны взглянуть на безсерверный фреймворк, потому что, как вам, мне не очень нравятся шаблоны SAM, для меня безсерверный фреймворк - это более быстрый и простой способ работы со сценарием ios, как этот, который вы описываете .

https://serverless.com/

Я использую его в некоторых своих проектах, он очень прост и функционален.

2 голосов
/ 07 января 2020

AWS SAM идеально подходит для этого случая использования! Если вы сравните его с CloudFormation, то вы сможете писать лямбда-функции и их триггеры более компактным способом намного . Я не уверен, что вы считаете сложным, но просто посмотрите на следующий пример. Это один AWS шаблон SAM, который определяет две AWS лямбда-функции, одна из которых запускается событиями S3, а другая - с запланированным выполнением каждые пять минут: 

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Globals:
  Function:
    Runtime: python3.8
Resources:
  Bucket:
    Type: AWS::S3::Bucket
  ProcessorFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: s3_processor.handler
      CodeUri: src/
      Policies: AmazonS3ReadOnlyAccess
      Events:
        PhotoUpload:
          Type: S3
          Properties:
            Bucket: !Ref Bucket
            Events: s3:ObjectCreated:*
  ScheduledFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: scheduled_function.handler
      CodeUri: src/
      Events:
        Timer:
          Type: Schedule
          Properties:
            Schedule: rate(5 minutes)

Я не буду включать, как то же самое определение выглядело бы как с чистым CloudFormation, так как в нем было бы более ста строк.

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

Что касается кода, вы можете видеть, что я использовал два разных обработчика, так что вы просто s3_processor.py и scheduled_function.py в своем src/ -каталоге, и вы хороши для go. Вы можете легко хранить все это в одном git-хранилище и пользоваться преимуществами AWS возможностей локального тестирования SAM.

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

...