I use Serverless to deploy back-end APIs and to run serverless applications, which are basically microservices.

I make use of AWS Lambda to deploy back-end for artificial intelligence applications. For instance, one example I deployed using AWS Lambda was for the back-end of an application where the front-end calls the back-end to return data. This helps ensure that the back-end operates separately, and resources are not being used when not needed.

I run serverless applications on AWS, and I believe the main use case is to ensure that application back-ends are not being used unless they are specifically called or unless they are specifically needed for use.

I believe the best features Serverless offers are the very quick ability that enables individuals to quickly make calls to their back-end or to quickly make calls to their services. Additionally, Serverless is very useful when it comes to running simultaneous jobs at the same time without breaking.

Serverless helps run simultaneous jobs. For instance, when you need to make a back-end API call, multiple people can make such calls at the same time. What happens at the Serverless back-end is it creates something similar to multiple instances or multithreading that allows each Serverless Lambda or each Serverless resource to run concurrently without affecting one another.

It has helped a lot in saving costs because, as I mentioned initially, it makes sure services are not being used unless they are being invoked. It has really helped in making sure costs are well managed and also making sure we do not make use of resources that are not needed at a particular point in time.

Making use of Serverless has at least helped us save 50% in cost spending on resources.

Because I believe Serverless has had a very positive impact on myself and also on the company I work for, especially on the cost side. It is very cost-effective and has helped us to save a lot, I believe up to 50% on cost savings and also has helped us to really save a lot of money when it comes to deploying back-end and managing back-end services.

Serverless can be improved by making it more independent from particular bigger providers. Serverless can be better if it is more decentralized and individuals are allowed to probably have full access to their own serverless machines.

I have been using Serverless for about five years.

Serverless is pretty much stable, but I believe the only downside is when it has to do some kind of cold warming, which might actually take some time.

It is very much scalable. As I mentioned earlier, it allows users to run multiple requests at the same time and is able to handle even thousands of requests concurrently.

I had not used a different solution.

I also evaluated making use of EC2.

I would tell them that if they want something quick, portable, and fast, they can make use of Serverless. However, if what they want is something that has to do with data that is needed in real time, then they should look for a different solution. I give this product a rating of 8.

My primary use case for Serverless is handling asynchronous data processing and event-driven workflows. I typically use it to trigger background tasks like image processing or data transformation whenever a file is uploaded to S3, which keeps our main application responsive.

In my last role, I used Serverless to address an issue where users were uploading high-resolution images that were slowing down our main site. I set up an S3 trigger that automatically invoked a Lambda function the moment a file hit the bucket, and the function resized the image into three different formats and stored them back to a separate bucket, which reduced our page load time by about 40% and significantly lowered our storage cost.

By offloading that processing to the background, we ensured that the main application remained responsive while the images were handled asynchronously, turning a major performance bottleneck into a seamless, automated workflow for our users.

The best features Serverless offers beyond image processing include building event-driven APIs and cron-like automations. For instance, I set up scheduled Lambda functions to handle daily database cleanup and report generation. For me, the biggest advantage is the automatic scaling and the pay-per-execution model, allowing us to handle massive traffic spikes without manual intervention.

During high traffic periods, I found that automatic scaling has helped us immensely. We had a major marketing campaign launch last year that drove a sudden 10x spike in traffic to our platform, and because our backend was built on Serverless functions, the infrastructure scaled out instantly to handle the concurrent requests without me having to provision a single extra server or worry about downtime.

Serverless has positively impacted my organization by shifting our focus from infrastructure management to pure product delivery. By offloading the operational overhead to the cloud provider, my team has been able to cut our time to market for new features by nearly 30%.

The biggest area for improvement in Serverless is around cold start latency, especially for applications that aren't constantly active. While providers are making strides, it still forces us to choose between cost efficiency and instant responsiveness, and I would love to see more mature, built-in support for pre-warmed instances or predictive scaling to bridge the gap.

Beyond latency, I believe better observability and debugging tools for distributed Serverless architecture are critical. It is often difficult to trace a single request across multiple functions, so having a more unified, native tooling would significantly reduce the time we spend troubleshooting complex event-driven flows.

I have been working with Serverless architecture for about a year and a half.

Serverless is incredibly stable for us. We have seen significantly higher uptime compared to our previous setup because the platform handles all the underlying patching and scaling automatically.

Scalability of Serverless is honestly one of the biggest wins for us, as it handles traffic spikes automatically without any manual intervention. We do not have to worry about over-provisioning or under-provisioning. Regarding customer support, it has been very responsive; we have found the documentation and resources to be thorough enough that we rarely run into blockers that we cannot solve quickly.

I would rate customer support around 8 out of 10 because it is consistently quick, the documentation is comprehensive, and all customer support is quite responsive, so there is not much of a blocker.

Before moving to Serverless, we were running a monolithic application on standard EC2 instances. We decided to switch because scaling was manual and reactive, which led to significant downtime during traffic spikes and high operational overhead for our engineering team.

We did not purchase Serverless through the AWS Marketplace; we manage our infrastructure directly through AWS accounts using Terraform for our IAC, which gives us better control over environment configuration and deployment pipelines.

We definitely saw a strong return on investment after moving to Serverless architecture. By reducing our monthly infrastructure spend by about 30%, we eliminated the idle capacity costs we were previously paying for underutilized EC2 instances.

Regarding pricing, setup cost, and licensing, I find the pricing model quite efficient for us, as we only pay for execution time in a pay-per-use model, eliminating the idle costs we saw with traditional servers. While some investment was needed in defining our Terraform modules and CI/CD pipelines, it significantly reduced our long-term licensing overhead compared to managing proprietary on-premise software.

Before choosing Serverless, we evaluated other options and looked into containerizing our monolith with Kubernetes on EKS. While Kubernetes offered great portability, we ultimately decided against it because the operational overhead of managing clusters did not solve our core problem of wanting to focus purely on feature development rather than infrastructure maintenance.

My biggest piece of advice for others looking into using Serverless is to prioritize observability from day one because you lose visibility into the underlying infrastructure, so you need to have robust logging and distributed tracing in place immediately, or debugging becomes a nightmare.

One final point about Serverless is that while it is incredible for scaling, I think it is crucial to be mindful of cold starts and vendor locking early on; if you design your architecture to be modular from the start, you keep your options open as the system grows. I would rate this product an 8 out of 10 overall.

Serverless stands out for easy deployment without any server hassle, and if we need scalability or efficiency, the Serverless framework is mostly cost-efficient because we integrated a Lambda function that charts user request steps, which is why it is cost-efficient. We do not need any high-profile developer for maintaining a server, which is the good thing about Serverless.

Serverless positively impacts my organization by saving time since we do not deal with deployment hassles, and Serverless costs less than other server maintenance options. The positive impact of Serverless is its ability to reduce the number of people needed for project deployment. As a software engineer working on DevOps for project deployment, I find that without Serverless, every project needs multiple workers, but I can handle both development and deployment easily, which reduces hassles for software.

My advice for developers considering using Serverless is that if they face any hassle with deployment, they can easily choose Serverless for automation, coding, and deployment, as well as local setup and project deployment in any server automatically.

Serverless is a great tool for every software engineer, and if any software engineer has not used this tool, they are lacking knowledge and a great opportunity. I tell every software engineer that if they have not used Serverless, it is important for every developer at some point to experience it. I give this review a rating of 9.

In my previous job and in my current job, I work as a cloud engineer, where I have been working with some clients who have provisioned Serverless architecture for their business, and I provide services to those customers as a cloud engineer.

I can give you a quick specific example of a project where I used Serverless: in my previous company, I worked on a fintech project where the services ran in Fargate, a Serverless service of AWS, deploying a microservices architecture within this Serverless framework. In my current job, I also provide support for a customer whose entire architecture is deployed in Serverless on AWS Cloud, which includes API Gateway, Lambda functions, DocumentDB, and S3 buckets; everything within this architecture is Serverless, and I provide maintenance and daily support for this project in my current job as well.

I mainly worked on these two projects with Serverless, but I know there are other Serverless services in AWS that I have not worked with in a production environment. Thus, I can say these two are the main projects I have been involved in with Serverless architecture.

The best feature that Serverless offers is that I do not have to manage any servers because the service providers, like AWS or other cloud providers, take full care of the servers behind the scenes, which means I do not have to manage maintenance, security, scalability, or anything about those servers. I focus my attention on application development rather than spending time on servers.

Serverless has helped me and my team by making our workflow easier and freeing up time for other tasks. If I focus on previous projects, particularly the fintech project, which operates like a Revolut application and is based in Haiti under the name MonCash, I deployed microservices in Fargate that are highly scalable. The application supports features like adding money, sending money, transfers, and bill payments, and I needed to avoid spending time troubleshooting infrastructure because everything was Serverless, making it very easy to manage, highly durable, and secure.

In the previous project, monitoring was done solely on AWS CloudWatch, despite not having access to servers or SSH. Still, I had monitoring capabilities for our services. For example, if a service reached 90% capacity, I could set auto-scaling limits, ensuring costs remained manageable. Integration was handled through AWS Cloud Map, managing the networking of new IPs for our microservices, which is also a Serverless service.

Serverless has positively impacted my organization, particularly through its scalability. Developers can deploy at any time thanks to blue-green deployment available in this architecture, allowing for bug fixes or new features to be pushed into production without any downtime, which has helped not only my organization but also the fintech application MonCash, which has enjoyed uninterrupted service, meeting SLAs consistently.

I can share specific metrics indicating Serverless's positive impact: I achieved 100% uptime, an impressive feat compared to traditional servers that often experience downtime during peak usage. With Serverless, I had 100% uptime SLA, which was excellent for my portfolio and essential for end users.

There can be improvements in the AWS architecture of Serverless, particularly regarding features like blue-green deployment, where automation could simplify tasks. If I had easier options for these deployments, such as assigning specific traffic percentages to various versions, it would enhance Serverless architecture usability for both professionals and beginners.

Transitioning from servers to Serverless results in a price increase due to the additional maintenance and patches AWS provides, but if costs could be reduced, more customers would consider moving to Serverless architecture.

I have been using Serverless architecture for the last four years.

Serverless is very stable and highly scalable; I set limits for invocations, RAM, and CPU usage on Lambda functions, and AWS ensures stability and availability. With five years of experience using Serverless services from AWS, I have encountered no outages or issues.

My experience with AWS support regarding Serverless is mixed; while I appreciate the interaction, I lack deep visibility into the monitoring and logging of Serverless components. When issues arise, I rely on AWS for detailed insights, but the lack of direct access can be limiting.

I migrated from using Docker containers on EC2 instances to Serverless due to numerous challenges in DevOps, including complex monitoring setups and the extensive automation needed to scale infrastructure. Serverless simplified my architecture, making it highly available and scalable without managing servers.

Serverless is not available on the AWS Marketplace; it consists of a collection of services already available on the AWS console, allowing me to use any service I need like Lambda for compute, DocumentDB for databases, S3 for file storage, and API Gateway for serverless APIs. There is no single service to purchase, and setup is straightforward, with no licensing required—however, costs remain higher than desired to attract more customers.

I have seen a return on investment with Serverless, as moving from servers means requiring fewer cloud engineers and DevOps staff for maintenance, patches, and infrastructure management, resulting in reduced time and effort.

I would rate Serverless an 8 out of 10.

I choose an 8 out of 10 because of the pricing, which should be reduced, even though a higher price makes sense due to the services provided, but AWS pricing is significantly higher than traditional servers. Additionally, access to Serverless offerings must be more accessible for all users to become the first choice for customers.

I advise others to consider Serverless as their first option, as it saves effort and money despite the higher costs, but the reduction in maintenance and deployment costs from traditional servers is significant. My overall review rating for Serverless is 8 out of 10.

My main use case for Serverless is hosting applications and running code.

I can provide a specific example of how I'm using Serverless for stream applications or running code: I am running applications without servers, executing ad hoc tasks, Lambda tasks, or function tasks.

I have additional context about my main use case with Serverless. We did not want to host servers and pay for idle servers just to run code and ad hoc tasks, so we switched to Serverless. We now only pay for the amount of time we are running applications or the amount of time we are using the application.

Serverless has positively impacted my organization, and we are seeing a positive response in terms of pricing and scalability.

Serverless offers valuable features including ad hoc task execution, event-based triggers, integration with other features, other functions, and other applications.

The integration with other features and applications has particularly helped me. When something arrives in my S3 bucket or any other source, it triggers an event and runs Serverless applications to execute tasks.

Serverless can be improved with more stability, more scalability, and more integration with other applications.

There are improvements needed around triggers and event-based functionality. Sometimes we see old results instead of new results when events trigger. This area requires improvement.

I rate Serverless an eight because it can be improved in stability. Sometimes we see older results, and sometimes it doesn't trigger based on the event. Additionally, sometimes we get charged more money than we actually use, so these areas require improvement.

I have been using Serverless for two to three years.

Serverless is stable, but it can be improved.

Serverless can scale on demand.

Serverless customer support is good.

We have not used any other solution before this.

My experience with pricing, setup cost, and licensing demonstrates that pricing is good because we only get charged for the amount of time we use and the amount of time we trigger events. Setup cost is minimal because it is easy to use. It requires only some code, which is why it is easy to set up.

I have seen a return on investment. Money and time are saved, and it is deployed in a public cloud on AWS.

We have not evaluated any other option before choosing Serverless.

My advice to others looking into using Serverless is that you can use it if you want to save money, if you don't want to manage servers, if you only want to be charged for the amount of time you use, and if you want to run code and ad hoc tasks. Serverless offers great scalability. I rate this product an eight.

My main use case for Serverless is developing full stack applications and APIs.

The best features Serverless offers is the ease of going to market. It is easy to simply go and deploy your code. You just focus on the functionality while the infrastructure is already set up there, so I do not have to spend hours setting up the infrastructure.

Serverless is easy to start with, especially for features like minimum viable products. If I want to develop a full set of applications and go to market immediately, then I prefer Serverless. Also, if you want to scale up, then Serverless is the best way. It is scalable and more secure, and it is on-demand, so it is easy to reduce or increase the load based on our needs. It is automated and very cost-effective. We are not billed per second like with provisioned services. Serverless offers a great pay-as-you-go model that is really excellent. It also has very good integration with all services from front-end to back-end, following a microservices concept. I love this concept and the supporting features including X-ray to find any issues in terms of failures, or CloudWatch to gather logs. It is an amazing set of components and microservices working together to provide solutions to single problems.

The most important feature is time-saving. When we have an idea and want to test it, we need to go to market quickly. Developing and deploying the MVP to check the idea is really a time-saving approach that has impacted our organization.

Almost 60% of time was saved when we considered Serverless. Because we always had to wait for server provisioning and other provisions if we wanted to do something else or pursue other projects using non-serverless methods. But in Serverless, the infrastructure is already set up, so we just need to go and deploy and start using it. We almost saved 60% of time. Cost-wise, we also saved a lot of money by not buying provisions and not paying for idle time. In Serverless, there is no need to pay for idle time. That is the core advantage of using Serverless.

Serverless can be improved with more usage videos. I found a lot of online tutorials using Serverless, but it could have more use cases with more detailed videos. For example, videos on DynamoDB single-table design and how to develop efficiently would be helpful. Additionally, detailed content on how to improve Lambda debugging and comprehensive documentation would be helpful for developers.

I have been using Serverless for the last four to five years.

I can provide details of a recent project called Project Creative Gifts, which I developed fully with AWS Serverless technology. It is an online gift e-commerce store developed using Angular as the front-end and Node, NestJS as the back-end. The complete solution is deployed in Serverless on AWS. I used various Serverless technologies and tools to deploy this application. For the front-end, I used S3 bucket web hosting and CloudFront as a CDN. For the back-end deployment, I used API Gateway, Lambda, and DynamoDB. For authentication purposes, I used Cognito to authenticate the users.

It is an e-commerce online store with a lot of access points to store and retrieve data. I considered various options to save money and keep a single table design. I conducted a lot of research and created multiple access points to securely store and retrieve data in a more effective and cost-effective manner while maintaining performance. This presented a challenge, but I finally managed to solve it by placing the design appropriately.

So far, I am satisfied with Serverless. Everything is integrated and everything is set up perfectly. I would rate this review an eight out of ten.

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.

Currently, I do not see any issues regarding our main use case with Serverless; we have written this framework in the YAML language, and everything is going smoothly, so we are enhancing the scripts.

Serverless offers many available plugins that support the workflow. Serverless impacts my organization positively in many ways by enabling us to easily debug issues when any pipelines break; we can get errors, debug them, and address issues. It can support many ways using its unique plugins that we cannot find in other tools, basically working end-to-end for our Serverless projects.

A specific outcome is that Serverless improves the release speed and deployment speed significantly compared to earlier when we used to deploy using Lambda SAM, reducing deployment time and becoming less error-prone, making it very useful.

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.

I have been using Serverless for around four years.

Serverless is stable and very responsive; it offers many debugging plugins, so overall, it is stable and good.

We have been using this tool for many years, so I think it is very useful for us and also scalable.

The customer support experience has been good; we tried to reach out for some issues and received quick responses, so overall, it is good.

Serverless is the first tool we are using and are still using, and I have not used any different solutions.

We have seen a return on investment, particularly regarding optimal cost optimization, and we need to monitor aspects such as yearly licensing costs. We have been using this framework for a long time but now feel the cost is expensive, so we need to improve in this area.

My experience with pricing, setup cost, and licensing is that I recently feel the licensing is a bit expensive; we need to renew the license, but we are still renewing it. In the future, a lower licensing cost would be very beneficial for us.

I did not evaluate any other options before choosing Serverless.

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.