Working For M Bank at a financial services firm with 51-200 employees
Real User
Top 10
Apr 2, 2026
Serverless can be improved by adding more plugins, as they help to support many integrations and can facilitate integration with other tools, such as monitoring tools like Grafana. User experience with Serverless could be improved, particularly the UI, which can be a bit tricky; enhancing that UI experience would be very useful for us. I do not see any needed improvements for Serverless beyond what I mentioned, specifically concerning plugins; everything else seems fine.
Serverless can be improved by making it more readable, as the framework still has a different syntax than normal use cases. It can be made easier to use so that people coming from regular backend applications such as Node.js or others can transition to it more smoothly. That is what I felt personally, and that is one way Serverless could improve. Readability improvement is one area I felt could be enhanced; otherwise, I am satisfied.
There are several areas where Serverless can be improved. It is not feasible for a huge amount of codebases. That is one thing I noticed gradually. When the application is too large, you cannot use Serverless easily, which becomes tough to handle. If your APIs are rapidly increasing, there are Lambda limitations in AWS, and I am not sure how it works with other serverless options, but this is my experience with Serverless using Lambda. Monitoring and debugging are easier compared to others, in my belief, so I do not see any necessary improvements over there. The only improvement which can be made, which we mitigate by using some hacks, is the initial start time. However, I think we mitigated that using different hacks. The challenge lies in how to scale the code with respect to Serverless; for instance, if I have a huge legacy database, I need to think about how to migrate it to Serverless efficiently, even with a substantial codebase.
Improving Serverless is a difficult question because I am not deeply familiar with Serverless, so it is really difficult for me to judge. Probably they would introduce an alternative to the way they currently create the infrastructure with CloudFormation. By default, it uses CloudFormation, which sometimes can be a problem. Probably it would have an integration with something like Terraform or another alternative.
I struggled with wanting to put breakpoints throughout the code and then use the debugger. At the time, I was not able to step through the code with breakpoints, so if Serverless had that support, that would be great. The overall documentation is great, and I do not have anything else to add about needed improvements.
I choose eight out of ten because to go ahead with Serverless, we need to do YAML file creation and other format file creation. So it might not be having the idea. That is the only thing that I observed.
Product Manager at a tech vendor with 10,001+ employees
Real User
Top 10
Dec 2, 2025
I do not have any specific suggestion at this point on how Serverless can be improved for my use case. Perhaps down the line I will have more information. The reason I choose a seven is primarily resource-based scheduling. This is what we are not able to get around on Serverless. It solves a main use case, but it still does not solve our batch executing and batch simulation use cases. However, if this could be one solution to move away from a traditional HPC scheduler, I would have definitely given a ten.
Serverless revolutionizes application architecture by eliminating the need for server management, offering a scalable, cost-efficient approach for modern development needs. It enables developers to focus on writing code without the complexities of infrastructure handling.Originally designed for enhancing agility, Serverless provides on-demand function execution, ensuring seamless scalability and rapid deployment. As a back-end architecture, it allows businesses to execute code in response to...
Serverless can be improved by adding more plugins, as they help to support many integrations and can facilitate integration with other tools, such as monitoring tools like Grafana. User experience with Serverless could be improved, particularly the UI, which can be a bit tricky; enhancing that UI experience would be very useful for us. I do not see any needed improvements for Serverless beyond what I mentioned, specifically concerning plugins; everything else seems fine.
Serverless can be improved by making it more readable, as the framework still has a different syntax than normal use cases. It can be made easier to use so that people coming from regular backend applications such as Node.js or others can transition to it more smoothly. That is what I felt personally, and that is one way Serverless could improve. Readability improvement is one area I felt could be enhanced; otherwise, I am satisfied.
There are several areas where Serverless can be improved. It is not feasible for a huge amount of codebases. That is one thing I noticed gradually. When the application is too large, you cannot use Serverless easily, which becomes tough to handle. If your APIs are rapidly increasing, there are Lambda limitations in AWS, and I am not sure how it works with other serverless options, but this is my experience with Serverless using Lambda. Monitoring and debugging are easier compared to others, in my belief, so I do not see any necessary improvements over there. The only improvement which can be made, which we mitigate by using some hacks, is the initial start time. However, I think we mitigated that using different hacks. The challenge lies in how to scale the code with respect to Serverless; for instance, if I have a huge legacy database, I need to think about how to migrate it to Serverless efficiently, even with a substantial codebase.
Improving Serverless is a difficult question because I am not deeply familiar with Serverless, so it is really difficult for me to judge. Probably they would introduce an alternative to the way they currently create the infrastructure with CloudFormation. By default, it uses CloudFormation, which sometimes can be a problem. Probably it would have an integration with something like Terraform or another alternative.
I struggled with wanting to put breakpoints throughout the code and then use the debugger. At the time, I was not able to step through the code with breakpoints, so if Serverless had that support, that would be great. The overall documentation is great, and I do not have anything else to add about needed improvements.
I choose eight out of ten because to go ahead with Serverless, we need to do YAML file creation and other format file creation. So it might not be having the idea. That is the only thing that I observed.
I do not have any specific suggestion at this point on how Serverless can be improved for my use case. Perhaps down the line I will have more information. The reason I choose a seven is primarily resource-based scheduling. This is what we are not able to get around on Serverless. It solves a main use case, but it still does not solve our batch executing and batch simulation use cases. However, if this could be one solution to move away from a traditional HPC scheduler, I would have definitely given a ten.