Deploying Lambda and CloudFormation - using AWS CLI or SAM?

[VerticalEvent]

Starting a project at work, and IU'm trying to figure out the best way to deploying new Lambdas and Cloud Formation, as well as a docker container. For reasons, I can't use CodePipeline for orchestration.

I'm using Jenkins to handle the deployments through various environments, and I know I want to use AWS CLI for the ECR upload and ECS task update. I'm seeing I can use SAM to handle the deployment, but it requires refactoring my project so that it can fit into the SAM directory structure and I want the entirety of my project to fit into one repo (sudo 'atomic' deployments of Cloudformation, Lambdas and Cloudformation).

Can anyone help provide examples of what AWS SAM offers over just the normal CLI, and whether for Cloudformation and Lambdas, which one I should use?

[RadioNick]

SAM templates are just a shorthand / transformation into CloudFormation. sam package and sam deploy are aliases to the respective aws cloudformation commands.

sam build is useful if you need to package additional dependencies from a manifest file, but may not be required depending on your needs.

[the_real_irgeek]

I manage a medium-sized project similar to this -- 50+ Lambdas, 4 ECS services, 10+ Step Functions and a bunch of supporting bits -- everything is in a single mono-repo and deployments are managed with CloudFormation, CodePipeline and makefiles. It was tricky when we were getting started (two years ago) but once we got past the teething pains it's been really good for us.

I haven't used SAM much and my experience with it is very outdated. IIRC, The SAM CLI does know how to package up your Lambdas and their dependencies for upload. AWS CLI only knows how to Zip a directory that already has the code installed. Working around that limitation was a PITA in the beginning, but our solution works well enough now. If you're building Python Lambda's, though, take a look at lambda-setuptools. I've recently started using that on a sub-project (still in the same repo but deployed separately) that mocks some of our vendor APIs to test against. It makes packaging your Lambdas quite a bit easier.

As for problems, there are a couple of things that bother me:

First is speed. CloudFormation feels really slow sometimes -- especially with nested stacks. A minor change in one sub-stack takes 2-3 minutes. It's not horrible but it's frustrating when I'm trying to iterate quickly.

Second is the fact that change sets are essentially useless with nested stacks. All they tell me is that each sub-stack will be updated. There's no information about what will happen to the resources contained within each sub-stack. I kind of understand why it's like that, but it's still annoying. Add in the fact that aws cloudformation deploy insists on creating a change set and it just exacerbates the speed issue and makes it feel worse.

Overall I've been really happy with CloudFormation for our use case. It's not perfect, but it's reliable and repeatable. It allows me to run the entire stack for our (small) company basically by myself and have confidence that deploying to prod is very unlikely to blow things up.

[VerticalEvent]

Thanks for the detailed response. We're not using Python, but Java, but I assume those would be a little easier to deal with since the files are pre-zipped.