aws-sam-cli VS Previous Serverless Version 0.5.x

aws-sam-cli-linux

No, it's not just muscle memory. It doesn't work with podman. That's what I'm talking about https://github.com/aws/aws-sam-cli/issues/1668

AWS SAM CLI with the support of Typescript is still in Beta. If you want more advanced features maybe you should not use it. Lately, in version 1.49.0 External and Loader properties have been added. If you want to share your feedback and/or requests this issue has been created.

I spent a while creating a custom runtime to use the native-image agent to harvest config from my Lambda, and then patching sam cli to work in Docker user networks... after pushing through all that, I still didn't get a working build - the native-image compiler just doesn't support everything (or didn't support my feature set, at the time - there has been a new release since then). In my case I think it was Guice that defeated me.

SAM support for TypeScript has been lagging for some time, but a pull request was just merged that should change that. It looks like we'll be able to add an aws_sam key in the package.json file to enable building within the SAM engine as part of sam build. Although this PR has been merged to aws-lambda-builders, the engine behind sam build, it will still need to be added to aws-sam-cli and released (to much fanfare, one expects) before it can be used with SAM.

sem-version java 8 wget https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip unzip aws-sam-cli-linux-x86_64.zip -d sam-installation sudo ./sam-installation/install checkout cd java-app-backend cache restore build-java-app-backend-$SEMAPHORE_GIT_BRANCH sam deploy --no-confirm-changeset --stack-name serverless-web-application-java-backend --capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_IAM

#!/usr/bin/env bash set -e if [ "$(id -u)" -ne 0 ]; then echo -e 'Script must be run as root. Use sudo, su, or add "USER root" to your Dockerfile before running this script.' exit 1 fi curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install rm -rf ./aws rm ./awscliv2.zip echo "AWS CLI version `aws --version`" curl -L "https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip" -o "aws-sam-cli-linux-x86_64.zip" unzip aws-sam-cli-linux-x86_64.zip -d sam-installation sudo ./sam-installation/install echo "SAM version `sam --version`" rm -rf ./sam-installation rm ./aws-sam-cli-linux-x86_64.zip wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb rm packages-microsoft-prod.deb sudo apt-get update; \ sudo apt-get install -y apt-transport-https && \ sudo apt-get update && \ sudo apt-get install -y dotnet-sdk-3.1 # Installing lambda tools was required to get lambda to work while I was testing different approaches. It may have become redundant after so many iterations and changes to the script, but probably does not hurt dotnet tool install -g Amazon.Lambda.Tools export PATH="$PATH:$HOME/.dotnet/tools"

workflow: variables: AWS_DEFAULT_REGION: "eu-west-1" WORKSPACE: "dev" TF_ENVIRONMENT: "terraform" stages: - terraform-apply terraform-apply: image: google/cloud-sdk:slim stage: terraform-apply before_script: - apt-get install -y unzip make jq - curl https://releases.hashicorp.com/terraform/0.12.29/terraform_0.12.29_linux_amd64.zip --output /tmp/terraform.zip - unzip /tmp/terraform.zip -d /tmp - chmod +x /tmp/terraform - mv /tmp/terraform /usr/local/bin/ - curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.0.30.zip" -o "awscliv2.zip" - unzip -q awscliv2.zip - ./aws/install - aws sts get-caller-identity - curl --location "https://github.com/aws/aws-sam-cli/releases/download/v1.18.1/aws-sam-cli-linux-x86_64.zip" -o "awssamcli.zip" - unzip -q awssamcli.zip - ./install - sam --version - curl --location https://github.com/terraform-linters/tflint/releases/download/v0.21.0/tflint_linux_amd64.zip -o /tmp/tflint.zip - unzip /tmp/tflint.zip -d /tmp - chmod +x /tmp/tflint - mv /tmp/tflint /usr/local/bin/ script: - echo yes | make tf-apply

Github | Website

- With Lambda, you manage creating and building the container yourself, as well as updating the Lambda function code. There are tools out there such as sst or serverless.com which help streamline this.

If you'd like to use Lambda, usually you need to engineer FOR it, from day one, you don't (often) get to choose some other framework and shoehorn it into Lambda and Serverless. There's some great frameworks to help deploy code into Lambda easily and create REST endpoints for things, one such frameworks is serverless.com that helps easily deploy to it, but it lacks a framework for doing REST that also supports local emulation (as easily). For that, I recommend a framework by AWS called Chalice. This is an amazing REST framework that runs a proxy that works locally and deploys exactly the same on Lambda, it is Python however.

After knocking out a README with a set of goals and a list of TODOs to check off as I made progress, I spent about 10 hours over a weekend trying to get something to work. I used serverless for making Lambda easier, Github Actions for the deploy pipeline and store my credentials; and sadly I rolled my own access_token refresh logic because I couldn't find a helper that just did that for me! wtf!?

The backend is built with serverless.com (lambda, dynamodb, sqs, appsync). The good thing is that all the backend is stored in a file and you can deploy multiple stacks on the same account using seed.run . You don't really need EC2/Fargate when you have lambdas and you know that most of the time will be idle time. The same with cache I wouldn't think of it right now until you see the workload you are facing. Dynamodb once you understand it and have a proper design it's the fastest thing you can have. On my appsync calls I'm using Dynamodb as a cache because it's cheaper...

Apache Kafka allows for asynchronous communication in a distributed ecosystem. It allows producers to publish messages on topics that are then ingested by consumers interested in those topics. As a concept, pub-sub models have been around for ages. However, the beauty of Kafka is in the how — using partitions and consumer groups, Kafka can scale the rate of consumption of messages with minimal dev and economic overhead. In this tutorial, I’ll take you through how to provision a managed Kafka cluster using the AWS Managed Stream for Kafka (MSK) service. We’ll use the serverless framework to create and maintain the infrastructure for MSK and the supporting VPCs, subnets, etc.

I run my personal project on AWS. I has been running for 4+ years now and I never had a local environment. I took the serverless route. That is appsync, lambda, dynamodb, sqs to build the stack. I'm using serverless.com to have all the resources defined in a yaml files which will deploy multiple stacks. I'm using seed.run to manage that part because it's much more simple than to do it manually.

The solution is deployed using serverless.com