fl-aws
serverless-application-model
Our great sponsors
fl-aws | serverless-application-model | |
---|---|---|
1 | 98 | |
15 | 9,235 | |
- | 0.3% | |
0.0 | 8.9 | |
over 7 years ago | 8 days ago | |
Python | ||
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
fl-aws
-
Ask HN: Does anyone else find the AWS Lambda developer experience poor?
Living in my team's bubble i thought everyone runs or tries to run parallel environments: prod, staging, dev, but also an individual (person) or feature env. Why? Because there's no emulator or documentation that will teach you real behavior. Like others have said, AWS seems out of this world. Just like GCP and Azure i might add. Some things you don't expect and they mesmerize you how smart they are. Some you expect and you can't fathom how come you're the "only" one screaming. Random thought: this is how i ended up logging all I bumped into into "Fl-aws" https://github.com/andreineculau/fl-aws
Back to the point: reality is that many build their AWS environment (prod) manually, maybe they duplicate once (dev) also manually, maybe they use some automation for their "code" (lambda) but that's it. This implies it's practically impossible to run end-to-end tests. You can't do that in prod for obvious reasons and you can't do it in dev either - you have many devs queueing, maybe dev is not in sync with prod etc.
My team ran cloudformation end-to-end. We actually orchestrated and wrapped cloudformation (this is yet another topic for not using terraform etc) so that if smth couldn't be done in CFN, it would still be automated and reproducible. Long story short, in 30 minutes (it was this long because we had to wait for cloudfront etc) we had a new environment, ready to play with. A total sandbox. Every dev had their own and it was easy to deploy from a release artifact or a git branch to this environment. Similarly you could create a separate env for more elaborate changes to the architecture. And test in a live environment.
Finally to your question: how do you test end-to-end?
If we talk about lambdas because that's where the business logic lies in a "serverless" architecture, then the answer is by calling the system which will eventually call your lambda/s along the way. If your lambda ia sitting behind AWS gateway, then fire an http request. Is it triggered when objects land on S3? Then push some object to S3. How do you assert? Just the same - http response, S3 changes etc. Not to mention you can also check cloudwatch for specific log entries (though they are not instant).
With this type of a setup, which sounds complex, but it is not since it is 100% reproducible (also from project to project - I had several), adding this proxy-to-my-dev-machine lambda would mean I can make local changes and then fire unit AND end-to-end tests without any changes pushed to AWS, which is the main time/energy consumer imo.
PS: sorry for the wall of text. Like i said i recently realized that the development realities have huge discrepancies, so i tried to summarize my reality :)
serverless-application-model
-
Simple and Cost-Effective Testing Using Functions
The complete solution with SAM is available here.
-
Deploying a Serverless Dash App with AWS SAM and Lambda
There are many options to deploy Serverless Applications in AWS and one of them is SAM, the Serverless Application Model. I chose to use it here, because it doesn't add too many layers of abstraction between what's being deployed and the code we write and our infrastructure is quite simple.
-
Serverless Apache Zeppelin on AWS
The solution uses AWS SAM with the global configuration for Lambda functions and the public API you can use to access Apache Zeppelin. The stack deployment provides the URL as an output value.
-
Using design patterns in AWS Lambda
When you combine this with the AWS Serverless Application Model you can also very easily include your dependencies. Or use a compiled language like golang for your Lambda functions. You simply run sam build before you run the aws cloudformation package and aws cloudformation deploy commands. SAM will build the binary and update the template to point to the newly built binary. Package will then upload it to S3 and replace the local reference to the S3 location. Deploy can then create or update the stack or you can use the CloudFormation integration in CodePipeline.
-
Serverless Site Health Check Notification System
I'm a big fan of using an Infrastructure as Code (IaC) approach for any project. My go to tools for this are the Servlerless Application Model (SAM) and it's associated CLI (SAM CLI). For more official use cases and for cross platform apps I typically use Terraform.
-
Starting My AWS Certification Journey as a Certified Cloud Practitioner
AWS SAM
-
API Gateway, Lambda, DynamoDB and Rust
Kicking off the tour and not starting a war, but I'm going to be using the Serverless Application Model.
-
Consuming an SQS Event with Lambda and Rust
The diagram here is super simple. I'm going to write something a little later that shows how this code could fit into a bigger workflow, but for now, I'm keeping it basic. And yes, that's the SAM Squirrel in there.
-
AWS Data Engineer Associate Certification - Coming Soon
Interestingly, AWS CDK and SAM are both explicitly mentioned. While CDK broadly addresses Infrastructure as Code, SAM is highlighted for its role in developing serverless data pipelines - a hugely underrated concept.
-
A Beginner's Guide to the Serverless Application Model (SAM)
Naturally, there are several options available to declare your cloud resources. The options with the most popularity are the CDK, AWS CloudFormation, SST, Serverless framework, Terraform, and AWS SAM. There are others, but when talking about Infrastructure as Code (IaC), these are the ones you hear about most often.
What are some alternatives?
aws-lambda-runtime-interface-emulator
aws-elastic-beanstalk-cli - The EB CLI is a command line interface for Elastic Beanstalk that provides interactive commands that simplify creating, updating and monitoring environments from a local repository.
LocalStack - 💻 A fully functional local AWS cloud stack. Develop and test your cloud & Serverless apps offline
Moto - A library that allows you to easily mock out tests based on AWS infrastructure.
sst-start-demo - A simple SST app to demo the new `sst start` command
openvscode-server - Run upstream VS Code on a remote machine with access through a modern web browser from any device, anywhere.
aws-sam-cli - CLI tool to build, test, debug, and deploy Serverless applications using AWS SAM
serverless-offline - Emulate AWS λ and API Gateway locally when developing your Serverless project
aws-lambda-java-libs - Official mirror for interface definitions and helper classes for Java code running on the AWS Lambda platform.
aws-cross-account-lambda-authorizer - Example repository for how to implement a cross account lambda authorizer
sst - Build modern full-stack applications on AWS