Our main use case for Serverless is deploying APIs and background processing jobs without having to manage servers. We had several workloads triggered by API requests, S3 uploads, and scheduled events. Instead of maintaining EC2 instances, we could focus on the business logic and let AWS handle scaling. That was especially useful for workloads with unpredictable traffic patterns. A recent specific example of a project where I used Serverless is building a document processing workflow where users uploaded files to S3, and Serverless triggered Lambda functions to validate and extract metadata automatically. At peak times, we were handling a few thousand uploads per day, so automatically scaling was really useful. We initially had Lambda timeout issues because one function was doing too much work, so we split it into smaller steps using SQS. After that, the workflow became much more reliable and required less detailed operational maintenance. Beyond APIs, I use Serverless for scheduled reporting jobs and internal automation tasks. Some functions run every few minutes, while others only execute a few times per day. I also integrated with DynamoDB and SQS and CloudWatch. The flexibility was valuable because different teams could deploy and maintain services without stepping on each other.
My main use case for Serverless is that I mainly worked on Node.js serverless applications for my platforms, and I have worked with different domains, spanning three or four domains with Serverless. A specific example of how I used Serverless in one of those domains is that I mainly worked with AWS infrastructure using the AWS stack, including S3, AWS Auth, and Cognito. I use several AWS services with Serverless and Node.js.
Working For M Bank at a financial services firm with 51-200 employees
Real User
Top 10
Apr 2, 2026
My main use case for Serverless is to deploy Lambda functions from AWS. A specific example of how I use Serverless with Lambda functions is that we deploy Lambda functions for any transfer-related and wire-related things because we are a fintech company, and we use Serverless framework to deploy Lambda, API Gateway, and S3 buckets.
My main use case for Serverless is based around an application that was an internal application used to track cloud usage across all cloud platforms like AWS, GCP, OCI, and Azure. I used Serverless and Serverless APIs based upon the Serverless Framework, with Node.js and Python Lambda, to support that full backend application. A specific example of how I use Serverless in that application is that there have been many APIs which provide recommendations for cost analysis or utilization-related details. For each of them, multiple Lambdas were written, and with each Lambda, there were no provisioned compute resources, so each was handled with Lambda jobs through the API gateway.
My main use case for Serverless is that all the APIs we made in my previous project were serverless, so each API would be a microservice or kind of a thing, which deploys in a different Lambda together, and it runs as serverless. A quick example of one API I built as Serverless is one where we need to sync data on an interval basis, so the code for that is written in a Lambda where it connects, imports the secrets, and connects to the database, respects services, takes the data, and syncs it by defining some business logic there. I deployed that as a separate Lambda which helped me to trigger whenever it is required, even manually and on a sync basis using cron. This is one of the examples, and there are many APIs that we built. My main use case for Serverless was that initially when we started the application, we realized that the application code would be a minimal thing, so we started using Serverless to deploy easily without any downtime or without a fraction of a second of downtime. It really worked well; during business hours, we can deploy some changes because it affects only that particular API or only that particular build, and everything is kept out with no downtime. That is the main reason.
My main use case for Serverless is the deployment of web applications. For the deployment of web applications, I write the configurations, write the code, then execute it, and I get the lambdas deployed on AWS and all the surrounding services.
Our main use case for Serverless is to build Serverless APIs, and the complete back-end is built with Serverless. A specific example of an API or back-end workflow built using Serverless is a parts integration related to buying parts catalogs, which is a third-party integration API, and everything was built using Serverless.
My main use case for Serverless is deploying my services like API services. A specific example of how I use Serverless for my API services is that I need to create one API where I want to expose my services outside by creating that. For that, I don't have the server to deploy my application. Instead, I just create a YAML file and deploy Serverless application onto my Lambda without any server.
Product Manager at a tech vendor with 10,001+ employees
Real User
Top 10
Dec 2, 2025
My main use case for Serverless is to run simulation workloads currently. A quick specific example of a simulation workload I'm running with Serverless is that we have a product which runs circuit simulations. This can traditionally run on HPC clusters, but we are also working on running it on a serverless architecture for these simulation jobs. We are currently in the POC area and will spend more time to understand how our customers can use this architecture to achieve better turnaround time for their simulations instead of going the traditional HPC schedule-driven approach.
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...
Our main use case for Serverless is deploying APIs and background processing jobs without having to manage servers. We had several workloads triggered by API requests, S3 uploads, and scheduled events. Instead of maintaining EC2 instances, we could focus on the business logic and let AWS handle scaling. That was especially useful for workloads with unpredictable traffic patterns. A recent specific example of a project where I used Serverless is building a document processing workflow where users uploaded files to S3, and Serverless triggered Lambda functions to validate and extract metadata automatically. At peak times, we were handling a few thousand uploads per day, so automatically scaling was really useful. We initially had Lambda timeout issues because one function was doing too much work, so we split it into smaller steps using SQS. After that, the workflow became much more reliable and required less detailed operational maintenance. Beyond APIs, I use Serverless for scheduled reporting jobs and internal automation tasks. Some functions run every few minutes, while others only execute a few times per day. I also integrated with DynamoDB and SQS and CloudWatch. The flexibility was valuable because different teams could deploy and maintain services without stepping on each other.
My main use case for Serverless is that I mainly worked on Node.js serverless applications for my platforms, and I have worked with different domains, spanning three or four domains with Serverless. A specific example of how I used Serverless in one of those domains is that I mainly worked with AWS infrastructure using the AWS stack, including S3, AWS Auth, and Cognito. I use several AWS services with Serverless and Node.js.
My main use case for Serverless is to deploy Lambda functions from AWS. A specific example of how I use Serverless with Lambda functions is that we deploy Lambda functions for any transfer-related and wire-related things because we are a fintech company, and we use Serverless framework to deploy Lambda, API Gateway, and S3 buckets.
My main use case for Serverless is based around an application that was an internal application used to track cloud usage across all cloud platforms like AWS, GCP, OCI, and Azure. I used Serverless and Serverless APIs based upon the Serverless Framework, with Node.js and Python Lambda, to support that full backend application. A specific example of how I use Serverless in that application is that there have been many APIs which provide recommendations for cost analysis or utilization-related details. For each of them, multiple Lambdas were written, and with each Lambda, there were no provisioned compute resources, so each was handled with Lambda jobs through the API gateway.
My main use case for Serverless is that all the APIs we made in my previous project were serverless, so each API would be a microservice or kind of a thing, which deploys in a different Lambda together, and it runs as serverless. A quick example of one API I built as Serverless is one where we need to sync data on an interval basis, so the code for that is written in a Lambda where it connects, imports the secrets, and connects to the database, respects services, takes the data, and syncs it by defining some business logic there. I deployed that as a separate Lambda which helped me to trigger whenever it is required, even manually and on a sync basis using cron. This is one of the examples, and there are many APIs that we built. My main use case for Serverless was that initially when we started the application, we realized that the application code would be a minimal thing, so we started using Serverless to deploy easily without any downtime or without a fraction of a second of downtime. It really worked well; during business hours, we can deploy some changes because it affects only that particular API or only that particular build, and everything is kept out with no downtime. That is the main reason.
My main use case for Serverless is the deployment of web applications. For the deployment of web applications, I write the configurations, write the code, then execute it, and I get the lambdas deployed on AWS and all the surrounding services.
Our main use case for Serverless is to build Serverless APIs, and the complete back-end is built with Serverless. A specific example of an API or back-end workflow built using Serverless is a parts integration related to buying parts catalogs, which is a third-party integration API, and everything was built using Serverless.
My main use case for Serverless is deploying my services like API services. A specific example of how I use Serverless for my API services is that I need to create one API where I want to expose my services outside by creating that. For that, I don't have the server to deploy my application. Instead, I just create a YAML file and deploy Serverless application onto my Lambda without any server.
My main use case for Serverless is to run simulation workloads currently. A quick specific example of a simulation workload I'm running with Serverless is that we have a product which runs circuit simulations. This can traditionally run on HPC clusters, but we are also working on running it on a serverless architecture for these simulation jobs. We are currently in the POC area and will spend more time to understand how our customers can use this architecture to achieve better turnaround time for their simulations instead of going the traditional HPC schedule-driven approach.