Working For M Bank at a financial services firm with 51-200 employees
Real User
Top 10
Apr 2, 2026
I find plugins such as VPC plugins most valuable or that my team relies on the most, and for security, we use Lambda's code authentication plugins, such as code sign plugins. I advise others to use Serverless due to the many supported plugins for cloud infrastructures such as AWS and various integrations, as well as its beneficial debugging capabilities; if you have issues, you can clearly see the debugging logs on the console. The deployment time is very quick, taking hardly two to five minutes for some Lambda functions, and overall, I strongly recommend it to others. I chose a rating of nine instead of a ten or something lower because some integrations need to be hardcoded manually, and there are no supported plugins for those integrations, such as monitoring tools like Grafana, requiring changes at the code level, indicating that some plugins are still missing.
The biggest challenges I have faced while adopting or using Serverless include the different syntax, syntactical understanding, and the steep learning curve with team members. Ensuring everyone has the right access and preventing direct interaction with AWS resources can be tricky if not managed properly, leading to challenges. For handling monitoring and security for my Serverless applications, I use the ELK stack to push the logs that have been generated. With that, it gets published to Grafana and Kibana, and through that, I utilize monitoring and performance. For managing version control and deployments for my Serverless applications, I have used Git for version control and GitHub Actions workflows for deployments. I ensure compliance or governance when using Serverless in my organization by following SOC 2 practices, which includes all necessary security protocols and application-related services. Serverless has influenced my organization's approach to innovation and digital transformation by allowing access and the ability for all team members to jump in quickly and contribute on an ad hoc basis without needing much infrastructure details. That has been a positive influence. I have not used Serverless for DevOps, so there is no real impact on that process. My advice for others looking into using Serverless is to first check what kind of requirements you have that make you consider Serverless: it should really fit your needs. Also, consult the team, as cost and time savings should not be the only metrics. Understanding the use cases and how the features can be applied in the Serverless framework is equally important. I would rate this product a seven overall.
When I say I can test independent Lambdas separately, it has helped my development or deployment process because, for example, when using an OpenAI API to do some data, if the API key is expired, instead of blocking all other APIs in production, I just need to update that particular Lambda or that particular API. I can do that and test it, with no need to regression test all the other code or even with respect to user interfaces; they will see only that one API, which may be failing, but they will not see any blockers in production until I fix this. I think that is the best use case. Even though there are drawbacks when the code increases rapidly, at a minimal level when you have optimized and minimal code, this could be a good scenario. If you have a huge code, there is a chance to use Serverless Lambdas in scenarios where you want to trigger jobs or perform jobs on a regular interval and host them separately so that they do not interact with or disturb your code working flow. If there is any mismatch in the sync of the data, I can go and change that Lambda code, deploy it, and test it as serverless, with no need for regression testing. You can separate the actual code and these kinds of jobs. Serverless has positively impacted my organization because I can deploy without any downtime in the majority of cases. I do not say in all cases, but in most. The most significant impact is how developers control it; if something goes wrong, they focus only on that particular Lambda or API or the sync job instead of worrying about the entire codebase and checking whether everything is fine. My advice to others considering Serverless is that if their codebase is simple, they can migrate in the future. If there are concerns about codebase growth, they might want to consider migrating back to EKS or another solution, but they can use Serverless for the time being if it makes their life easier. I would rate this product a nine out of ten.
My advice to others looking into using Serverless is that you don't need to worry about the server maintenance, the servers, and where you host the servers. All these headaches go away. Definitely it's good to use. All the headaches that we have been doing for all these years can be gotten rid of, definitely. This has been a great initiative taken by AWS. Previously, we thought that we cannot host our applications without any server, but AWS proves us wrong by creating a Serverless application, the option to deploy our applications without any server. This is a really great initiative done by AWS. I rate this solution an eight out of ten.
Product Manager at a tech vendor with 10,001+ employees
Real User
Top 10
Dec 2, 2025
The transition from HPC clusters to a serverless architecture is going so far by facing the biggest difference where the traditional HPC schedulers have quite a bit of customization when it comes to scheduling jobs. It is traditionally a batch execution. Going for Serverless, we are looking at far quicker scheduling of jobs, but we currently are facing some issues when it comes to using the resources for the jobs and getting the image loaded because the image is very huge. It is too early to tell if I have any numbers or specific metrics on how much the turnaround time has improved since moving towards Serverless. We are still working on optimization of this entire workflow. We are still trying to figure out all the use cases we can work with. We still need to benchmark the results, so it is too early to provide that information. The advice I would give to others looking into using Serverless is to especially focus on any traditional HPC application, try to modularize your application and figure out specific workflows which are well suited for Serverless and migrate those into Serverless. I definitely see cost saving, quick scheduling of jobs and the overall improvement in efficiency. I gave this review a rating of seven out of 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...
I find plugins such as VPC plugins most valuable or that my team relies on the most, and for security, we use Lambda's code authentication plugins, such as code sign plugins. I advise others to use Serverless due to the many supported plugins for cloud infrastructures such as AWS and various integrations, as well as its beneficial debugging capabilities; if you have issues, you can clearly see the debugging logs on the console. The deployment time is very quick, taking hardly two to five minutes for some Lambda functions, and overall, I strongly recommend it to others. I chose a rating of nine instead of a ten or something lower because some integrations need to be hardcoded manually, and there are no supported plugins for those integrations, such as monitoring tools like Grafana, requiring changes at the code level, indicating that some plugins are still missing.
The biggest challenges I have faced while adopting or using Serverless include the different syntax, syntactical understanding, and the steep learning curve with team members. Ensuring everyone has the right access and preventing direct interaction with AWS resources can be tricky if not managed properly, leading to challenges. For handling monitoring and security for my Serverless applications, I use the ELK stack to push the logs that have been generated. With that, it gets published to Grafana and Kibana, and through that, I utilize monitoring and performance. For managing version control and deployments for my Serverless applications, I have used Git for version control and GitHub Actions workflows for deployments. I ensure compliance or governance when using Serverless in my organization by following SOC 2 practices, which includes all necessary security protocols and application-related services. Serverless has influenced my organization's approach to innovation and digital transformation by allowing access and the ability for all team members to jump in quickly and contribute on an ad hoc basis without needing much infrastructure details. That has been a positive influence. I have not used Serverless for DevOps, so there is no real impact on that process. My advice for others looking into using Serverless is to first check what kind of requirements you have that make you consider Serverless: it should really fit your needs. Also, consult the team, as cost and time savings should not be the only metrics. Understanding the use cases and how the features can be applied in the Serverless framework is equally important. I would rate this product a seven overall.
When I say I can test independent Lambdas separately, it has helped my development or deployment process because, for example, when using an OpenAI API to do some data, if the API key is expired, instead of blocking all other APIs in production, I just need to update that particular Lambda or that particular API. I can do that and test it, with no need to regression test all the other code or even with respect to user interfaces; they will see only that one API, which may be failing, but they will not see any blockers in production until I fix this. I think that is the best use case. Even though there are drawbacks when the code increases rapidly, at a minimal level when you have optimized and minimal code, this could be a good scenario. If you have a huge code, there is a chance to use Serverless Lambdas in scenarios where you want to trigger jobs or perform jobs on a regular interval and host them separately so that they do not interact with or disturb your code working flow. If there is any mismatch in the sync of the data, I can go and change that Lambda code, deploy it, and test it as serverless, with no need for regression testing. You can separate the actual code and these kinds of jobs. Serverless has positively impacted my organization because I can deploy without any downtime in the majority of cases. I do not say in all cases, but in most. The most significant impact is how developers control it; if something goes wrong, they focus only on that particular Lambda or API or the sync job instead of worrying about the entire codebase and checking whether everything is fine. My advice to others considering Serverless is that if their codebase is simple, they can migrate in the future. If there are concerns about codebase growth, they might want to consider migrating back to EKS or another solution, but they can use Serverless for the time being if it makes their life easier. I would rate this product a nine out of ten.
The advice I would give to others looking into using Serverless is to not be afraid and to try it. I would rate this review an 8 out of 10.
Our customer support experience has been straightforward as we have not really had to contact them. I would rate this review an 8.
My advice to others looking into using Serverless is that you don't need to worry about the server maintenance, the servers, and where you host the servers. All these headaches go away. Definitely it's good to use. All the headaches that we have been doing for all these years can be gotten rid of, definitely. This has been a great initiative taken by AWS. Previously, we thought that we cannot host our applications without any server, but AWS proves us wrong by creating a Serverless application, the option to deploy our applications without any server. This is a really great initiative done by AWS. I rate this solution an eight out of ten.
The transition from HPC clusters to a serverless architecture is going so far by facing the biggest difference where the traditional HPC schedulers have quite a bit of customization when it comes to scheduling jobs. It is traditionally a batch execution. Going for Serverless, we are looking at far quicker scheduling of jobs, but we currently are facing some issues when it comes to using the resources for the jobs and getting the image loaded because the image is very huge. It is too early to tell if I have any numbers or specific metrics on how much the turnaround time has improved since moving towards Serverless. We are still working on optimization of this entire workflow. We are still trying to figure out all the use cases we can work with. We still need to benchmark the results, so it is too early to provide that information. The advice I would give to others looking into using Serverless is to especially focus on any traditional HPC application, try to modularize your application and figure out specific workflows which are well suited for Serverless and migrate those into Serverless. I definitely see cost saving, quick scheduling of jobs and the overall improvement in efficiency. I gave this review a rating of seven out of ten.