Serverless Reviews

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.

Serverless helps me with data processing in AWS by making infrastructure deployment very easy. With a single click, it automates everything when I am working inside AWS infrastructure. The development is also very fast and easy to implement, and it is not a complex architecture compared to Spring Boot, MVC, or other infrastructures.

The best features Serverless offers for me include automated deployments, which are very smooth and interesting. As a full-stack engineer, Serverless really helps me to reduce my DevOps cost. Another valuable feature is the offline mechanism, and I have used AWS LocalStack with Serverless Offline, which is really interesting and helps me to simulate cloud infrastructure without any cost on my machine.

Automated deployments and the offline mechanism impact my workflow positively because when I configure the Serverless application in the serverless.yml file, I can configure everything, such as AWS services I have used in my application, including S3 configuration, Cognito configurations, and database configuration as separate YAML files integrated into one Serverless file. Then I just click on the NPM deploy, develop, or any staging option, and it automatically deploys to my AWS CloudFormation stack, creating the entire service.

Serverless positively impacts my organization by allowing us to work as a startup with very limited resources and costs. When we go with a Serverless infrastructure, we reduce the need for specialized resources, especially on the DevOps side, because everything becomes automated, enabling our full-stack engineers to perform that work. Reducing resources means we reduce cost as well, and it is time-saving since deployment does not take hours but rather depends on our network speed.

Serverless helps with scaling my applications as the organization grows by not restricting the inclusion of more components or modules in the Serverless applications. However, there can be some restrictions. For example, AWS S3 only supports a maximum file upload of 250 MB using Serverless. Despite a few concerns, from a Serverless point of view, integration and implementation of our logic into applications remain very easy.

Serverless has many advantages, and it is very easy to handle with a cloud solution. However, there are a few concerns about the limitations. Especially when I work with Lambdas, there are maximum Lambda timeouts. Likewise, there are several things from Serverless, such as maximum file uploads.

Serverless can be improved by addressing the challenges faced when we have the first infrastructure. Sometimes it is hard because we need to manually create things such as Cognito pools. While 90 percent of the time is automated, more automation would be better. If Serverless provided CI/CD capabilities, that would also be great, as currently it only allows for manual deployments. Additionally, when working with cloud services, Serverless allows the use of LocalStack or Serverless Dev, but I think Serverless Dev might need simplification for easy access without organization registration.

When considering needed improvements, I get frustrated with Lambda time and similar issues, which are actually not related to Serverless but rather are AWS issues. However, when discussing Serverless, the main points I see require improvement from the Serverless end.

I have been using Serverless for almost close to two years.

Serverless is stable. With the arrival of Serverless v4, I observe it has good features and improvements over the past few years, hence it appears stable for specific domains and applications.

Serverless helps with scaling my applications as the organization grows by not restricting the inclusion of more components or modules in Serverless applications. However, there can be some restrictions. For example, AWS S3 only supports a maximum file upload of 250 MB using Serverless. Despite a few concerns, from a Serverless point of view, integration and implementation of our logic into applications remain very easy.

I have used several solution frameworks previously, including Java Spring Boot and NestJS with EC2, among others. The decision to switch to Serverless is based on the project or company requirements. If I was working in a very large enterprise application, I would choose Java over Serverless. However, for this startup, we determined that Serverless was the most suitable framework, and I am open to switching frameworks in the future as per the architecture needs of the application.

In terms of time or cost saved compared to before using Serverless, I save approximately 60 percent of my development time because everything is very lightweight and gives me the freedom to work within Serverless. Similarly, regarding cost, when I reduce time, I should automatically reduce cost as well. About deployment, we handle deployment more than 80 percent faster, so we do not need to have a specialized DevOps engineer as my full-stack skills cover it.

Regarding pricing, setup cost, and licensing experience, I find the application to be very cost-effective. The headcount needed is much lower compared to supporting services in software development, particularly in DevOps or technical writing roles. Overall, it is lightweight and should be cost-effective compared to other frameworks, which is why we choose Serverless for its suitability in small applications that need to be lightweight and quickly delivered.

Before choosing Serverless, I considered other solutions such as Express with AppRunners, but I found that version to be time-consuming compared to traditional Serverless with more manual interference, especially regarding deployment and DevOps. I also checked Spring Boot, but it did not match our application needs, focusing instead on AppRunners with Express as a viable alternative.

Serverless affects my team's productivity and collaboration by presenting some challenges. For instance, when we work in parallel, deploying two different versions at the same time can lead to issues or conflicts, where resources may not be generated successfully. However, these challenges are manageable since we typically avoid deploying two versions at the same time in actual production development.

Serverless handles monitoring and troubleshooting effectively by integrating with CloudWatch, allowing for easier understanding of logs. Serverless also possesses extensive documentation and references, making it easy to resolve any issues related to its functionality, although logic issues might require different handling.

My advice to others looking into using Serverless is that you need to understand your requirements and ensure Serverless aligns with your solutions. It depends on your application, the cloud solution being utilized, and the services required. Throughout my experience with Lambda, I always tie it back to that. While it works for me, others might have different needs or infrastructures, hence it is crucial to have an open mindset and determine what framework truly suits you rather than sticking to one blindly, as that could lead to frustrations. I would rate my overall experience with Serverless as a seven out of ten.

My main use case for Serverless is to build applications for businesses that want to start up creating or having automations, having some business processes automated, or having a digital presence with their own system online.

A quick specific example of an application I have built using Serverless is for a medical clinic, a health place where a hospital, for example, recovers patients from injuries in their joints. We built an application for them that replaces all their booking system. We used full Serverless so when nobody is using it or at night, there is no cost. When there is a lot of usage, it can scale up and have the resources to provide a smooth experience for the user.

Using Serverless improved that project compared to a traditional approach because implementing Serverless is quite fast. You can create a back end with just API Gateway and Lambda. You can have a very quick MVP built with three or four resources, of course including logs through CloudWatch. The user can start feeling how it is to have everything digitalized while we build the proper architecture and the whole system. That is something that would be much more costly if I spun up EC2 or would need more infrastructure if I started using Fargate, for example. Fargate is Serverless but still has too much power and infrastructure for what I needed in this clinic or the initial stage where we were starting the automation of the booking system as I mentioned.

Additionally, Serverless allows me to implement AI technologies at the same time. You do not need to have a server running full time for having inference or for having LLMs working for you. You can scale up accordingly to the requests of your AI agents and use directly the system that you built and pay for it as you go. If you use it too much, you pay more; if you do not use it, you do not pay basically. My summary would be that Serverless is helpful for building something fast and with a small or no cost if there is no demand.

Serverless has positively impacted my organization as I have built my own website fully with Serverless where I have a little CRM that records the potential clients in there. We do not pay for it if we are not using it. We also have a WhatsApp AI bot that uses Lambda, connects to Dynamo, and is also serverless. It has helped my business to manage and acquire more clients.

The positive outcomes or metrics I have noticed since using Serverless are related to costs and time savings. Before, a lot of people were involved in certain things, and now that you can automate and do with Serverless at a fraction of a cost, you can start replacing certain activities and focusing on more profitable activities.

One of the best features that Serverless offers in my experience is the scalability, the easiness to implement, and how quite fast it is to build something with it. The main features are scalability and easiness.

Also, the free tier is valuable. DynamoDB, Lambda, CloudWatch, and other Serverless resources have a free tier that is really generous. You actually can build something without spending anything.

Serverless can be improved as it is quite complex to test locally without using your portal.

One thing I would like to see improved in Serverless is to have more traceability for the requests and how the data flows through the system. Additionally, I would like to see improvements to local testing. There are already certain ways to use DynamoDB locally, but of course, it has to be on AWS to run a project in real life. Tracing is something that is not used that much in my experience in developer teams, but it still should be. Normally, I think we are trained to use just CloudWatch, but not exactly X-Ray, for example. A lot of people think that X-Ray is expensive, but it is not actually. It has a very generous free tier.

I would say there is a need for a quick and verifiable method so someone can have access to usage quotas and higher usage quotas. Right now, if you create a new account, it is quite difficult to get normal usage quotas. You receive ten Lambdas, for example, and you cannot do too much with ten Lambdas, so you have to request an increase of the usage quota, and normally it takes some time, so that could be improved.

I have been using Serverless for three years.

Serverless is fully stable in my experience. It has a service level agreement, so you can expect it can fail a bit over the year, but it is quite minimal. You do not care about infrastructure. You do not have to care about infrastructure, and you have a system where you can run your applications and trust that you do not need to do anything. You just have to focus on your application.

Serverless's scalability for my needs is one of my topics because suddenly, when you use an application much less, we can build a feature that explodes over the internet. I just see the system; if it is built correctly, it will scale and provide the functionality that I need without having a homogeneous experience for everybody. That is great.

The customer support for Serverless is something I only needed to reach for usage increment. Sometimes it can be complicated when the account is new, but when the account is already established over time, or when you use a corporate email, it can be quite fast.

I have not used a different solution before Serverless. I have always used Serverless since I have been in the business since 2020, and Serverless existed already. However, I did not use anything related to the cloud at that time. I started moving into the cloud in 2023 and 2024, and that is where I got all the scalability power from AWS.

I have seen a return on investment as we are a team of four developers and my company is eight people worldwide. We have built full projects amounting to around eight full projects in one year, or let us say six. That is something that without Serverless would not be possible because we would have needed to implement servers here, servers there, on-premises, for example, and the cost would have been much more and not accessible for normal business owners.

My experience with pricing, setup costs, and licensing for Serverless is quite easy. Everything is in the documentation now, and with AI, you can start planning costs for different ranges of usage. I did not have any kind of problem.

I have checked also to implement EC2. However, the problem there is that you are responsible for the maintenance.

My recommendation to others reading reviews on PeerSpot is that you should start building fast; you can start building on it and test its limits compared to other technologies. Also, receive proper training. It is easy to implement, but it is not necessarily easy to correctly implement things in Serverless. For example, there are certain DynamoDB access policies that have to be respected or followed. Otherwise, you would be left with a chunky API and application, and you do not want that because your users may think it is not good.

Regarding Serverless's AI capabilities, I think governance and security are important aspects. Governance of data is something that is not explained that much. What I understand is that it is behind AWS servers. I am not sure if you have to sign a business agreement that states they will not use your data for training models, but the option is there, so it is okay. Security, I think, is also okay because you can restrict access using IAM permissions. You can restrict the access to the models and to your information. You can create policies, roles, and create a really good structure for not allowing anybody to access your volume incorrectly, including using VPCs.

Regarding Serverless's AI capabilities, the accuracy and reliability of output depend on the model, actually. It can be not necessarily good. Systems have to be implemented in order to validate accuracy, for example, having an agentic process that reviews what another AI generated because there can be errors in what was generated by AI.

I have not purchased Serverless through the AWS marketplace. I only have access to Anthropic models.

I would rate Serverless overall as a ten out of ten.

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.

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 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.

The best features Serverless offers include that you do not have to envision the whole architecture; you can work with the AWS resources through the codebase. It will still look like the whole backend is a normal application, while it is not being deployed as a single application. It basically interacts with services such as DynamoDB or IAM, depending upon the use cases. That is really valuable.

What I appreciate most about the framework are both the flexibility and the integration with AWS resources. I also appreciate that we do not have to envision any cluster, so Lambda takes care of itself by definition, which is a beneficial feature to have.

Serverless has positively impacted my organization as it has become the de facto standard for any POCs I have been doing, unless something specific is required that demands an on-demand instance. Otherwise, basic POCs and all internal applications have been using Serverless.

A specific outcome related to Serverless's impact is that it saved time because I did not have to delve much into DevOps or pay external tools such as Kubernetes to manage the cluster, and it also reduced costs from the Serverless Framework.

Serverless integrates with my existing tech stack and other tools seamlessly; it works flawlessly and is a service of its own, so it does not really affect anything else.

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.

I have used Serverless for around four to five years.

Serverless has been stable.

The scalability of Serverless depends on the kind of Lambda being used; it varies based on each of the services, but it has been good, and the configuration defined with the YAML files supports it.

The customer support has been moderate; sometimes there are delays, but overall, it has been fine when I have needed to reach out.

Before Serverless, I used normal backend and frontend full-stack applications. The switch was needed to accommodate certain endpoints or services that had been used excessively while others were utilized less, requiring me to scale the applications differently. Adopting Serverless was the right decision for that.

I have seen a return on investment through the money saved and time saved to quickly adopt Serverless.

My experience with pricing, setup cost, and licensing has been straightforward.

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.

Our main use case for Serverless is that we deployed our back-end software which is based on Node fully on Serverless which is on Lambda.

A specific example of how I use Serverless for my back end is that we put our code for API in Node and upload the JAR file into Lambda. After that, when we call the API, Lambda triggers and provides the required output.

The best features Serverless offers are that I can move it to Lambda, which is serverless, and it is a compute function. We don't have to worry about the static server such as an EC2 instance, where we have to manage the server manually and scale it when needed. In the case of Lambda, it automatically scales up and scales down according to its need. So we don't have to worry about monitoring the server.

Serverless has made my day-to-day work easier because we don't have to set up an extra team. For example, in many projects we have to keep an L1 support team which monitors the server continuously. In our case, with fewer resources, we can use it effectively.

With Serverless, I can easily connect with the other features of AWS, such as S3 and DynamoDB. So it will work more efficiently.

Serverless has positively impacted my organization, and I have noticed changes since adopting it. For instance, we had work where we needed to refactor DynamoDB. By using Lambda, we could write a script in Python for DynamoDB. We updated approximately 150,000 records. It was easier because we extended the runtime of Lambda to ten minutes and ran the script multiple times. It was very helpful.

To improve Serverless, I think if the AWS team provided more common examples of how to implement in our current project, along with some demos, it would be very helpful for us.

I would also appreciate documentation on how to implement in our current project because when I initially began to work on this AWS Serverless framework, I was not able to get any accurate results on YouTube or any other site. I could only take help from the team members who earlier worked on them. This is the only drawback because every team member has their own task, and I need some extra time to learn the flow. It was difficult for me in the early days.

I have been using Serverless for approximately one and a half years.

In my experience, Serverless is stable.

Serverless automatically handles large requests coming to any Lambda and will automatically scale. If there is no usage, then it goes into sleep mode and doesn't charge for that time.

For customer support, I think it was quite good. Whenever we reach out to them, they quickly reply to us.

Actually, I have not set up the full Serverless because I am a junior developer, so it is the work of an architect. My senior helped me with that.

I have seen a return on investment with Serverless while doing the refactor of the database. In DynamoDB, we have many records. By removing the records and updating the TTL, Time To Live, in every data that we didn't need, we reduced the cost from approximately forty to forty-five percent overall. So it was very helpful for reducing cost.

Comparing to my old process, I can say that each time if we run Lambda, we update ten to fifteen thousand records. It would take more than a week if we did it manually in the other way around. However, using the script and the features of AWS, which provided us the ability to update in batch, was very helpful and reduced the time as well.

Regarding setup cost and pricing, I actually don't have much knowledge because it is handled by the client side. We are only using its features.

Before choosing Serverless, I evaluated other options, and I think we were considering the EC2 instance. However, we thought that sometimes during the night, we didn't use our software. So we decided that it is better to go with Serverless because we are only paying when we use it.

I advise others looking into using Serverless because it is quite helpful and easy to use in day-to-day work and will change a lot of work that we used to do manually or used to require an extra team member for, which will be reduced. Also, in the cost-cutting scenario, we have reduced the overall cost of the project. I would rate this product an eight out of ten.

My main use case for Serverless in my last company involved using Lambda and the AWS Fargate service, and for my current organization, we are migrating some services to Serverless.

A specific example of how I used Serverless in one of my projects is when my last company, a product-based company, had to test our product on a microservice level. On that occasion, we used the EKS Fargate service to conduct short-term testing.

Regarding my main use case for Serverless, we have also set some alert alarms on AWS for compliance breaches, which trigger Serverless to execute scripts or actions.

Serverless offers the best features including automatically scaling resources based on requirements, such as needing only one core and two gigabytes of RAM, making it cost-saving, especially in terms of FinOps where we focus on saving company costs without needing to specify any hardware.

Serverless positively impacts my organization by being really cost-effective and serving as a production performance testing tool. As we increase the load, it automatically increases the CPUs and RAM without needing any manual intervention or heavy servers for this type of testing.

I have seen specific outcomes where we set compliance parameters, providing only two cores and four gigabytes of RAM for testing. If anyone uses more than four or eight, our Serverless Lambda function gets triggered, causing Serverless to take action to reduce those specifications.

Serverless can be improved by making it available across all cloud platforms. Implementing it in a local environment would be really helpful as well, since outside of Kubernetes and OpenShift, it is not a proper example of Serverless.

I have been using Serverless for around five or more years.

Serverless is stable most of the time, though we occasionally face issues, but that is primarily due to our usage of the public cloud.

Scalability of Serverless depends on our specific use case. If the code requires more CPU or RAM, Serverless automatically provides it. For instance, when I launch an app using Serverless and the load increases, the necessary CPU and RAM scale automatically without requiring any additional configuration from me.

Customer support from AWS is marvelous.

Previously, I used Kubernetes and OpenShift as production solutions before switching to Serverless for staging.

My experience with pricing, setup cost, and licensing for Serverless spans around five or more years.

I have seen a return on investment since, as I mentioned, it is a product-based tool that minimizes human effort. We do not need to approach the infrastructure team for specific testing resources, as developers and testers can directly load code, test, fetch results, and set up production environments based on those results.

I did not evaluate other options before choosing Serverless. In production, we use Kubernetes, while for staging and development, we see the advantages of using Serverless for small use cases, and for larger applications, we revert to Kubernetes.

I would rate Serverless a seven out of ten for testing. Serverless is not suited for production environments. It is designed for stage, testing, or development environments, while we use Kubernetes, OpenShift, and several other tools for production deployments. My advice for others looking into using Serverless is to be very careful. If we create a loop in the code, it can require thousands of CPUs and RAM, which could cost much more than expected, so writing the code requires careful consideration when using Serverless.

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.

We primarily run jobs on Serverless, specifically on AWS Lambda, using short-running jobs triggered by events. We can connect to an API Gateway for various purposes. For instance, if a client wants to process data and the data volume is not large, we decide to run that job on Serverless using AWS Lambda. In my previous role, we used it to build four backends because we expected API requests to be completed in microseconds. This represents a full range of applications.

Serverless's best features are quite impressive. You don't have to provision anything and it comes with a self-contained environment. The time limit is also beneficial because it forces you to work within certain constraints to build fast applications.

With a self-contained environment, you build things for specific purposes. You build technology to support what you currently have. The time limit depends on your needs. Sometimes you build something and later realize it's going to take more than 15 minutes, and at that point, you can move it to a container or a long EKS job. However, with the self-contained environment, it helps that you already know you have your language and it comes with some dependencies already installed, so you don't need to have a Docker container. Even with that, you can still have a CI/CD workflow and build with packages that are not pre-provisioned with the container itself. This is the Lambda container, and then you have them in there. The process is quite seamless.

Serverless has positively impacted my organization. In my previous company, it helped them save a lot. In my current company, we use the technology to achieve what the job needs. This helps us know that we save money because not every job demands you run a long-running job or have a container, as instances are expensive. With Serverless, it's on-demand, so you only use and pay for what you've used, which is very beneficial.

I think we are moving in the right direction because AWS recently announced something regarding VMs and Lambda VMs for long-running Lambdas. There are also SnapStart and a few other things available. Cold starts are generally getting better, and even for some jobs, cold starts aren't really a significant issue. In its current state, I don't know what Serverless can do better because I think it's already excellent at what it's supposed to do.

I've been using Serverless since late 2020, so approximately six years, give or take.

Serverless is stable.

Serverless scales to the point that if you're not careful, you may pay for more than what you're expecting because Serverless is extremely scalable.

AWS provides the customer service.

It wasn't a switch. It was just using a particular technology for a particular job. We still run multiple workloads, some on instances and some serverless, some on servers, and various other configurations.

It's pretty accurate and reliable most of the time regarding Serverless's AI capabilities. We use it currently to read data off bank statements and then try to determine what kind of transactions were made, whether it was an income or a payment or something else. It's pretty accurate most of the time, around 80 percent.

An implementation team was involved.

The experience with pricing, setup cost, and licensing was pretty straightforward and smooth. AWS has a number of in-built Serverless options, so you didn't really need to go to the marketplace. They are open with the cost upfront.

Serverless was the right option for us at that point.

I would give Serverless a rating of 9 out of 10. I think it's solid.

For what Serverless promises, I think it delivers on all fronts.

Regarding Serverless's AI capabilities, I think it operates the same way. We just need to be careful once you limit the access you give to your agents and the models, and even to the users themselves. It still boils down to the same principles of least privilege and what you give access to what the job is supposed to do. If you over-give the access, it will do something it's not supposed to do, and that's on you.

People should use the right tool for the right job. If Serverless doesn't work for them, they shouldn't use Serverless. If it works for them, they should go ahead because it's very beneficial.

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.