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

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.

The best features Serverless offers include the biggest advantage of infrastructure as code combined with simplified deployments. I also appreciate how easy it was to create event-driven architecture without building a lot of custom infrastructure.

Serverless has freed our developers to build and deploy features faster. Developers could experiment with new features because the cost was low. It also reduced the number of operational tickets.

We also spent much less time patching and maintaining servers. We estimated we reduced infrastructure-related maintenance work by around thirty to forty percent after moving some services to Serverless. Our team was spending several hours each week on server patching, scaling configuration, and deployment coordination, and most of that went away. For smaller projects, we could get new services into production much faster than before because there was less setup.

Debugging distributed Serverless applications can still be frustrating. When multiple functions, teams, and events are involved, tracing a failure is not always straightforward. Cold start latency is also noticeable for some workloads. The framework also has many configuration options that can become overwhelming for new users.

I would prefer to see better debugging and tracing tools built in by default when a request passes through multiple Lambda functions, which can lead to surprises after deployment. If observability and troubleshooting were more streamlined out of the box, it would make the experience for new users much better.

I have been using Serverless for a little over two years, mostly for backend APIs and event-driven workloads on AWS. This is more streamlined than what we were doing before.

Before Serverless, even a small API change often involved coordinating. Another feature that I find useful is how well Serverless fits event-driven architecture. As we built more workloads, we connected services through S3 events and SQS. I would rate this review as eight out of ten.

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.

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.

My main use case for Serverless is to deploy the application and save the cost of the servers. I have deployed some simple React-based applications and React and Node-based applications using Serverless. I have developed some extractors such as Google extractor in our team, which will be hosted in Serverless to save the cost of the server.

The best feature of Serverless is cost; when the application is in use, then it will incur cost, unlike traditional servers where it is the cost of all the uptime. Using Serverless saves the cost of my team. Serverless has positively impacted my organization by doing cost cutting, as we had achieved cost cutting of more than 50,000 using this.

We achieved that cost cutting mainly through less maintenance, and it incurs cost only during the running time, not during idle time as normal servers do.

Serverless can be improved by effectively handling large scale applications, as large scale applications would save more money.

In my current field, I have been working for more than five years. I have been using Serverless since one year.

Serverless is stable.

Serverless scalability is very good; however, for large applications, I think it is not working well, but for small functions and small applications, it is very good.

I did not attend any customer support yet because it does not require, as my IT team handles it very well.

Previously, I was using servers and VMs for hosting the application, and we switched due to cost cutting.

I have seen a return on investment, as Serverless saves a lot of idle time money.

I do not know about the pricing, setup cost, and licensing, as that is handled by the sales team, my other team.

We did not evaluate another option before choosing Serverless because we had taken all of the demos and it was very cost effective for us.

Serverless is good for small based applications, but for large applications, it will not perform very well. If you have any small application, then you can go ahead with Serverless, as it will save you a lot of money and a lot of effort in managing and securing servers; you only need to secure hosting the application. I would rate this product a 7.