Although true, I have found it to be frustrating in practice compared to the simplicity of running a standard API locally. I have even seen some people rig their lambdas to accept a boolean param which changes it to a standard server to get around this.
I think lambdas are great but the current tooling needs to advance a bit more for adoption to really take off imo
> At least AWS SAM supports local debugging and testing.
I'm still new to SAM but coming from a more regular style of web development it still feels brutally inefficient.
Changing 1 line of code requires waiting multiple seconds to build + run your new lambda so you can see the changes even with a local invoke of it.
That and if you really want to keep things local you need to mock out all calls to other AWS resources that you might be using in the lambda. Although you'd run into this same problem with a regular style app too.
I'm so glad I don't have to do serverless development full time. Just so happens I'm doing a small service for contract work but yeah, it's like taking 100 steps backwards for development friendliness IMO.
I've tried using LocalStack for mocking AWS services locally, but it's never worked quite the way I want it to. At this point I just set up "local" versions of the resources I need in a non-prod account and set up the service to use those when I'm developing.
The real problem is the development lifecycle for a lambda. It's a constant loop of changing the code, building it and then invoking it. This process takes a bunch of seconds even for the smallest change in a tiny code base.
It's much slower than writing code and immediately going to a browser to reload to see the changes which is something a lot of dev environments were able to pull off since about 1998.
The most impressive thing (for us) that you could do with AWS Lambda is easily scale your functions without being worried about scaling.
For example, we [1] have an API that runs Lambda functions to extract the structured content out of the news article. At some point, we have very few new articles being discovered by our system (night time in the US, for example). Other time, there are ~100 new articles every second. And, we do not have to worry about our infrastructure: 100 Lambdas will be executed concurrently, and we'll pay for just 100 Lambdas like if they were one after one.
Also, for many startups/side-projects when you don't know what would be your workload in advance, Lambda can save you money. And, if you somehow have a huge workload your solution won't be crashing.
Lambda scales well... until it does not. If your traffic pattern is very spiky and unpredictable, the burst limit can be a real pain in the neck. It ranges between 500 and 3.000 Lambda instances, depending on the region, and when that threshold is reached it can only spin up 500 more each minute. This is sufficient in most cases, indeed, but it's important to be aware of the implications of this limitation before believing that you can throw anything at Lambda and it'll just scale up to accommodate any workload.
The thing I always want from AWS tutorials which I can never find is guidance that doesn't involve using their web console.
I have a weird hang-up about configuring ops stuff through web interfaces. I will go to extraordinary lengths to avoid them - I want to get to the point where my deployment is controlled entirely from scripts in source control as quickly as possible, because that I can trust - I know that web interfaces will change in the future.
But unfortunately this means that most tutorials leave me frustrated. At this point I think this is more of a personal failure - I need to get over this hangup so I can actually follow the documentation that exists out there and learn to use the tools!
Agreed. The AWS developer docs are great but the first few chapters in e.g. SQS and SNS were "here's how to do it manually". Cloudformation is more of an appendix. Though, devils advocate, if they all started with "install Terraform" that might be a tall order and put people off.
We recently looked into AWS MSK (managed Kafka). Many of the crucial tasks, such as creation of topics, were more or less left as an exercise to the reader with some pretty distant dots to join.
If they'd been forced to explain how to automate all the necessary tasks in MSK, they might have had to make better tools. Or we might have given up on it sooner.
That’s how Transit Gateway documentation was in the beginning as well. A LOT of information was left out and it took them more than a year to provide a best practices page.
Easily my favourite feature of Google Cloud is every(?) web console action has the CLI command, or API RPC to achieve the same action.
It means I do every task the first time in the web console, where it's easy and discoverable, the second time in the web console again but I take note of the commands/RPC's, but the third->infinite times I've automated it.
> Easily my favourite feature of Google Cloud is every(?) web console action has the CLI command, or API RPC to achieve the same action.
I believe that's true of the AWS console, also; there's even a(few?) Chrome extensions to generate CFN and/or TF to replay console actions because the API calls are present in XHRs from the console. I often use the dev tools as a cheatsheet for what params to plug in for things, or to find out how AWS APIs relate to one another
It is because there are many ways to configure AWS. Should the tutorial use aws cli, cloudformation, terraform, cdk, sam? The Management Console tutorials get you familiar with the concepts quickly, but it is up to the developer use that knowledge with the tools of their choice.
>It is because there are many ways to configure AWS ... it is up to the developer use that knowledge with the tools of their choice.
I see this as a huge negative of AWS, personally. While the "freedom" of being able to choose whichever Infra-as-Code tool I personally prefer is nice, it's also a huge negative that there isn't one single tool that has the full backing and endorsement of AWS.
CloudFormation is the "official" tool, but it's basically a second class citizen in AWS rife with bugs and gotchas, and often lags in adding support for new AWS features. CDK is the up-and-coming "official" tool that seems like it might take the spotlight, but it's still in pre-release and because it relies on CloudFormation under the hood, it too is less than ideal.
Terraform is probably the most feature-complete and most frequently updated IaC tool, but since it's technically third party it isn't going to be included in official AWS docs/tutorials or get first party support from AWS.
Then you throw in the other stuff like the Beanstalk CLI, Copilot, SAM, Chalice, Amplify CLI... there are so many tools for creating resources in AWS that it's overwhelming when trying to decide which one to use.
I've found AWS Lambda and Google Cloud Functions super useful to run automations, especially when used with the Shortcuts app on iOS.
For example, I have a GCF that checks my clipper card's balance[1] when I touch it with my phone[2], and displays the amount in large font on the screen. It only took an hour or so to write with no experience with it, and costs nothing at all to host since I send only a few requests a month.
Being able to run custom code on demand without having to deal with hosting, config, security or any of this cruft is a game-changer. I prefer GCF to AWS Lambda, but they're pretty much interchangeable for most use cases.
35 comments
[ 858 ms ] story [ 1261 ms ] threadAlthough true, I have found it to be frustrating in practice compared to the simplicity of running a standard API locally. I have even seen some people rig their lambdas to accept a boolean param which changes it to a standard server to get around this.
I think lambdas are great but the current tooling needs to advance a bit more for adoption to really take off imo
I'm still new to SAM but coming from a more regular style of web development it still feels brutally inefficient.
Changing 1 line of code requires waiting multiple seconds to build + run your new lambda so you can see the changes even with a local invoke of it.
That and if you really want to keep things local you need to mock out all calls to other AWS resources that you might be using in the lambda. Although you'd run into this same problem with a regular style app too.
I'm so glad I don't have to do serverless development full time. Just so happens I'm doing a small service for contract work but yeah, it's like taking 100 steps backwards for development friendliness IMO.
The real problem is the development lifecycle for a lambda. It's a constant loop of changing the code, building it and then invoking it. This process takes a bunch of seconds even for the smallest change in a tiny code base.
It's much slower than writing code and immediately going to a browser to reload to see the changes which is something a lot of dev environments were able to pull off since about 1998.
For example, we [1] have an API that runs Lambda functions to extract the structured content out of the news article. At some point, we have very few new articles being discovered by our system (night time in the US, for example). Other time, there are ~100 new articles every second. And, we do not have to worry about our infrastructure: 100 Lambdas will be executed concurrently, and we'll pay for just 100 Lambdas like if they were one after one.
Also, for many startups/side-projects when you don't know what would be your workload in advance, Lambda can save you money. And, if you somehow have a huge workload your solution won't be crashing.
[1] https://newscatcherapi.com/
So long as your RPS is low enough and you fit into the fairly tight APIGw+ Lambda edge cases box.
https://docs.aws.amazon.com/apigateway/latest/developerguide...
I have a weird hang-up about configuring ops stuff through web interfaces. I will go to extraordinary lengths to avoid them - I want to get to the point where my deployment is controlled entirely from scripts in source control as quickly as possible, because that I can trust - I know that web interfaces will change in the future.
But unfortunately this means that most tutorials leave me frustrated. At this point I think this is more of a personal failure - I need to get over this hangup so I can actually follow the documentation that exists out there and learn to use the tools!
We recently looked into AWS MSK (managed Kafka). Many of the crucial tasks, such as creation of topics, were more or less left as an exercise to the reader with some pretty distant dots to join.
If they'd been forced to explain how to automate all the necessary tasks in MSK, they might have had to make better tools. Or we might have given up on it sooner.
https://docs.aws.amazon.com/cli/latest/reference/lambda/inde...
Pretty much everyone moves on to one after getting introduced in AWS Console Web UI.
It's much more trouble to take and maintain web console screenshots than code snippes.
And as you said, it doesn't even make sense in the long run...
Taking them is the easy part.
It means I do every task the first time in the web console, where it's easy and discoverable, the second time in the web console again but I take note of the commands/RPC's, but the third->infinite times I've automated it.
I believe that's true of the AWS console, also; there's even a(few?) Chrome extensions to generate CFN and/or TF to replay console actions because the API calls are present in XHRs from the console. I often use the dev tools as a cheatsheet for what params to plug in for things, or to find out how AWS APIs relate to one another
Most things are available under alpha or beta gcloud CLI, but I couldn't find any public reference for the RPC calls.
I see this as a huge negative of AWS, personally. While the "freedom" of being able to choose whichever Infra-as-Code tool I personally prefer is nice, it's also a huge negative that there isn't one single tool that has the full backing and endorsement of AWS.
CloudFormation is the "official" tool, but it's basically a second class citizen in AWS rife with bugs and gotchas, and often lags in adding support for new AWS features. CDK is the up-and-coming "official" tool that seems like it might take the spotlight, but it's still in pre-release and because it relies on CloudFormation under the hood, it too is less than ideal.
Terraform is probably the most feature-complete and most frequently updated IaC tool, but since it's technically third party it isn't going to be included in official AWS docs/tutorials or get first party support from AWS.
Then you throw in the other stuff like the Beanstalk CLI, Copilot, SAM, Chalice, Amplify CLI... there are so many tools for creating resources in AWS that it's overwhelming when trying to decide which one to use.
https://www.alec.fyi/set-up-serverless.html
For example, I have a GCF that checks my clipper card's balance[1] when I touch it with my phone[2], and displays the amount in large font on the screen. It only took an hour or so to write with no experience with it, and costs nothing at all to host since I send only a few requests a month.
Being able to run custom code on demand without having to deal with hosting, config, security or any of this cruft is a game-changer. I prefer GCF to AWS Lambda, but they're pretty much interchangeable for most use cases.
[1] https://pypi.org/project/clippercard/
[2] https://gototags.com/blog/understanding-nfc-shortcuts-iphone