Ask HN: What’s most challenging in development for AWS Lambda (and serverless)?
7 comments
Hard to say.
I've mainly written simple Lambdas in Python and for that it is easy to "get things done" with the AWS Management Console.
In some sense, when things "get hard" with Lambdas you probably shouldn't be using Lambdas anymore. The tough issues you address can best be addressed by having opinionated answers to them, but if those opinions don't jive with the rest of the systems somebody uses you can take your tool out of the running for some users.
Perhaps the most central idea in AWS architecture is how you keep track of connection information. (e.g. credentials to talk to Dynamo DB or SES or whatever) Life can be sweet if you have a good answer for this, but if you don't you are going to suffer, get hacked, etc.
I've mainly written simple Lambdas in Python and for that it is easy to "get things done" with the AWS Management Console.
In some sense, when things "get hard" with Lambdas you probably shouldn't be using Lambdas anymore. The tough issues you address can best be addressed by having opinionated answers to them, but if those opinions don't jive with the rest of the systems somebody uses you can take your tool out of the running for some users.
Perhaps the most central idea in AWS architecture is how you keep track of connection information. (e.g. credentials to talk to Dynamo DB or SES or whatever) Life can be sweet if you have a good answer for this, but if you don't you are going to suffer, get hacked, etc.
Yes, Python is easier as it doesn't need compiling. So, you can just copy-paste it to the Console. Yet, there's a lot to be wished. Like instant log access, handling multiple stages (dev, integration, production, demo) etc.
I think Lambdas can be, or better, soon will be suitable for almost all use cases. We are just missing proper tools and good design patterns. Those must to be opinionated.
I think Lambdas can be, or better, soon will be suitable for almost all use cases. We are just missing proper tools and good design patterns. Those must to be opinionated.
I often use Lambda in an unintended way with a whole Python based website for each Lambda. It works surprising well, is secure, and totally removes server (i.e. EC2) management effort.
Using the API Gateway is optional now but is was a pain to configure for simple cases.
AWS in general is painful to manually configure for simple project. Automation improves the situation but again is a waste of time for very simple projects.
Using the API Gateway is optional now but is was a pain to configure for simple cases.
AWS in general is painful to manually configure for simple project. Automation improves the situation but again is a waste of time for very simple projects.
That’s exactly the pain I felt. And that is what I am solving.
Every complex project starts as a simple one. I am trying to make them very easy to configure and launch.
i found a lot difficult, like:
- how to structure my code, esp wrt callbacks/ step functions
- are there any conventions? like, what should my handler be called?
- uploading libraries (into/via layers) was stupid
- no ability to decomission lambdas -- you just gotta delete 'em
- finding lambdas was painful; the console was slow
- linking them to api gateways and configuring was painful
This is where using a tool like the Serverless Framework helps solve a lot of these problems:
- Use async/await promises instead and the specific plugin for the Serverless Framework for configuring your Step Functions makes it easy!
- Nothing specific here but just call it hat makes sense.
- Use your runtimes dependancy management tool. NPM for Node for example
- Just us "serverless remove" (you used "serverless deploy" to set them up)
- No need for the console with the Serverless Framework
- Use Serverless Framework. Literally 3 lines of yml configuration and you are done. https://www.serverless.com/framework/docs/providers/aws/even...
The dev cycle can be super fast. I have never before built stuff so quickly. Using "serverless deploy function -f functionName" means I can push my code changes into the cloud in 3 seconds for testing purposes so need to even setup local testing environments which can get very complex and be totally inaccurate compared to the environment that exists in AWS
The dev cycle can be super fast. I have never before built stuff so quickly. Using "serverless deploy function -f functionName" means I can push my code changes into the cloud in 3 seconds for testing purposes so need to even setup local testing environments which can get very complex and be totally inaccurate compared to the environment that exists in AWS
Thanks. That's exactly the kind of answer I'd hope I would get. Precise and actionable.
Admittedly, I'm a fan of serverless. I believe serverless will soon become a dominant form of cloud computing. I think it is just a matter of immaturity of the platforms and lack of tools. While I can't do much about the platforms, I can try to build better tools.
That's what my team and I are doing with Mantil https://github.com/mantil-io/mantil
Admittedly, I'm a fan of serverless. I believe serverless will soon become a dominant form of cloud computing. I think it is just a matter of immaturity of the platforms and lack of tools. While I can't do much about the platforms, I can try to build better tools.
That's what my team and I are doing with Mantil https://github.com/mantil-io/mantil
While working on it, we found these things the hardest in serverless: * complex setup and deployment procedures * hard to debug * need to change thinking about the system architecture * management tools (AWS console) made for admins, instead developers
Have you been playing with serverless? How was your experience? What’s been hardest?