The Complete AWS Lambda Handbook for Beginners
dashbird.io
dashbird.io
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.
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.
Pretty much everyone moves on to one after getting introduced in AWS Console Web UI.
https://docs.aws.amazon.com/cli/latest/reference/lambda/inde...
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.
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...
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
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, 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