I am using Serverless to deploy small applications in the cloud. I am deploying small applications with Serverless. Normal functional applications such as calculators and similar tools are what I am building with my small applications using Serverless. I am using Serverless for hosting small applications that I am developing.
Serverless Framework (Deprecated Listing. See New Listing)
Serverless, Inc.External reviews
10 reviews
from
and
External reviews are not included in the AWS star rating for the product.
Serverless hosting has reduced costs and effort but still needs better support for large apps
What is our primary use case?
How has it helped my organization?
Serverless has saved me a lot of money and time in my organization.
The workflow time and cost improve with Serverless because previously we had to assign a person to manage the server, but currently, there is no server, so no management is required.
What is most valuable?
Serverless is helpful because it completely eliminates the need to manage a cloud VM and control panel and manage the server. I only have to host the application and do not need to manage everything else.
What needs improvement?
Serverless is not completely effective for large-scale applications. For large-scale applications, Serverless will not work well. If it were possible to improve that, then it would completely replace the server.
For how long have I used the solution?
I have been using Serverless for the last six months.
What do I think about the stability of the solution?
Serverless is stable in my experience.
What do I think about the scalability of the solution?
The scalability of Serverless for my applications is good.
How are customer service and support?
I did not connect with customer support for Serverless, so I do not have feedback about that.
Which solution did I use previously and why did I switch?
I did not use any previous solution other than the native VM. Serverless is good now and will replace the server.
How was the initial setup?
I purchased Serverless through the AWS Marketplace.
What about the implementation team?
I did not evaluate another option before choosing Serverless.
What was our ROI?
Serverless has saved me a lot of money and time in my organization.
Serverless will save time and reduce the number of employees needed because previously, we had to manage the server, which is not necessary now.
What's my experience with pricing, setup cost, and licensing?
Serverless is helpful because it completely eliminates the need to manage a cloud VM and control panel and manage the server. I only have to host the application and do not need to manage everything else.
Which other solutions did I evaluate?
I did not evaluate another option before choosing Serverless.
What other advice do I have?
I rate Serverless seven out of ten because it is good and performs well for small applications, but it does not perform well for large applications.
I will advise anyone considering Serverless that if you have a small application running on a server, you can switch it to Serverless, and that will save you significant effort and money. My overall rating for this product is seven out of ten.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Serverless deployment has cut idle costs and now needs to handle larger applications better
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
Serverless can be improved by effectively handling large scale applications, as large scale applications would save more money.
For how long have I used the solution?
In my current field, I have been working for more than five years. I have been using Serverless since one year.
What do I think about the stability of the solution?
Serverless is stable.
What do I think about the scalability of the solution?
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.
How are customer service and support?
I did not attend any customer support yet because it does not require, as my IT team handles it very well.
Which solution did I use previously and why did I switch?
Previously, I was using servers and VMs for hosting the application, and we switched due to cost cutting.
What was our ROI?
I have seen a return on investment, as Serverless saves a lot of idle time money.
What's my experience with pricing, setup cost, and licensing?
I do not know about the pricing, setup cost, and licensing, as that is handled by the sales team, my other team.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Event-driven platform has handled real-time financial workflows and delivers faster with smaller teams
What is our primary use case?
In my current project, my main use case for Serverless at Gateway Ticket System is a financial platform, and in one of my previous projects, we built a high-scalable financial platform that processed a large volume of events every day while needing to react almost in real-time to different business events, such as customer actions, account updates, transactions changes, and integration messages from other services. Everything was good with my use case and my experience with Serverless in this project.
What is most valuable?
I find working with AWS Lambda for this kind of event-driven platform has benefits such as scalability where we don't need to manually manage the services or worry too much about the infrastructure capacity. One of the best features Serverless offers is automatic scalability because you don't need to worry about that, and no server management is another big plus since we don't need to manage instances, patch, runtime services, or capacity planning.
Serverless has positively impacted my organization because the outcome was very positive in most of the projects we used it, especially with the fast delivery made possible by clear boundaries for each function and the ability to resize the team constantly without needing to think too much about that, while the price remains very reasonable.
When mentioning faster delivery and resizing teams, we noticed specific improvements in project timelines and cost savings. We initially had about twenty developers and after building out the necessary infrastructure, we could focus our team on individual tasks and reduce to around eight developers, achieving a reduction of about forty percent in our overall costs.
What needs improvement?
Serverless could be improved if we had more flexibility in how we use memory and could manage memory usage ourselves, especially for background tasks.
What surprised me is not a feature, but more a problem that I faced, especially when using Serverless in the old version of Lambda before having the AWS Proxy to connect with RDS or any other kind of database.
For how long have I used the solution?
For my entire career, I have been using Serverless for probably six years, but here at this company, I have just used it for four or five months in a very specific project.
How are customer service and support?
I rate customer service a four out of ten.
What other advice do I have?
I do not have any improvements needed for Serverless that I have not mentioned yet. I do not have anything else to add about the needed improvements and will not expand on observability or debugging. My advice for others looking into using Serverless is to be cautious with your database connection and try not to use prior connections inside your handler while being a good documentation reader. I rate Serverless an eight out of ten.
Serverless workflows have boosted rapid AWS development but still need better CI and automation
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Serverless for almost close to two years.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
Which solution did I use previously and why did I switch?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Auto-scaling has ensured reliable order processing and has reduced costs for unpredictable traffic
What is our primary use case?
The main use case we are using is auto-scaling and cost-effectiveness. Some of our use cases involve unpredictable traffic. For example, during Eid events, I am from the QSR domain, so traffic on Eid day is not predictable. When using Serverless, it auto-scales, and I pay based on actual usage.
In my case, I use everything on my main server for what we build, but for order processing, we are using Serverless where we do not want any hassle of server management, such as upscaling. Order processing is the key part of my application. I preferred to use Serverless for this part so that none of my customers face any problems processing orders, because if any order fails, it loses the customer's confidence or trust.
I suggested my team use auto-scaling and Serverless for order processing and notifications, with auto-adjusting features to auto-manage traffic. For this feature, we are using Serverless.
What is most valuable?
There is a huge impact as my traffic gets auto-adjusted. I do not have to worry about whether my server is capable of handling the traffic or not. Serverless servers are much more capable. I do not have to bear the cost burden. I just need to pay for whatever I am using.
Serverless has definitely improved cost savings and there are fewer order failures due to high traffic.
What needs improvement?
Serverless is a very comprehensive platform. I have not explored everything, but I use it only for traffic management and the auto-scaling features. That is why I deducted one point.
For how long have I used the solution?
My team has been using Serverless for the last three to four years.
What other advice do I have?
If you are a startup or have any stable product and you want on-traffic payment, then you should definitely use Serverless. If you are not able to predict your traffic, then you should definitely use Serverless. For example, some days we have one hundred orders, but on a big day, we may have hundreds of thousands of orders. You cannot upscale your server from day one. You should definitely shift to Serverless. It will definitely help you reduce your costs and you can easily manage your traffic. I would rate this product as a 9 out of 10.
Serverless architecture has reduced idle resource costs and supports concurrent backend AI workloads
What is our primary use case?
I use Serverless to deploy back-end APIs and to run serverless applications, which are basically microservices.
I make use of AWS Lambda to deploy back-end for artificial intelligence applications. For instance, one example I deployed using AWS Lambda was for the back-end of an application where the front-end calls the back-end to return data. This helps ensure that the back-end operates separately, and resources are not being used when not needed.
I run serverless applications on AWS, and I believe the main use case is to ensure that application back-ends are not being used unless they are specifically called or unless they are specifically needed for use.
What is most valuable?
I believe the best features Serverless offers are the very quick ability that enables individuals to quickly make calls to their back-end or to quickly make calls to their services. Additionally, Serverless is very useful when it comes to running simultaneous jobs at the same time without breaking.
Serverless helps run simultaneous jobs. For instance, when you need to make a back-end API call, multiple people can make such calls at the same time. What happens at the Serverless back-end is it creates something similar to multiple instances or multithreading that allows each Serverless Lambda or each Serverless resource to run concurrently without affecting one another.
It has helped a lot in saving costs because, as I mentioned initially, it makes sure services are not being used unless they are being invoked. It has really helped in making sure costs are well managed and also making sure we do not make use of resources that are not needed at a particular point in time.
Making use of Serverless has at least helped us save 50% in cost spending on resources.
Because I believe Serverless has had a very positive impact on myself and also on the company I work for, especially on the cost side. It is very cost-effective and has helped us to save a lot, I believe up to 50% on cost savings and also has helped us to really save a lot of money when it comes to deploying back-end and managing back-end services.
What needs improvement?
Serverless can be improved by making it more independent from particular bigger providers. Serverless can be better if it is more decentralized and individuals are allowed to probably have full access to their own serverless machines.
For how long have I used the solution?
I have been using Serverless for about five years.
What do I think about the stability of the solution?
Serverless is pretty much stable, but I believe the only downside is when it has to do some kind of cold warming, which might actually take some time.
What do I think about the scalability of the solution?
It is very much scalable. As I mentioned earlier, it allows users to run multiple requests at the same time and is able to handle even thousands of requests concurrently.
Which solution did I use previously and why did I switch?
I had not used a different solution.
Which other solutions did I evaluate?
I also evaluated making use of EC2.
What other advice do I have?
I would tell them that if they want something quick, portable, and fast, they can make use of Serverless. However, if what they want is something that has to do with data that is needed in real time, then they should look for a different solution. I give this product a rating of 8.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Event-driven workflows have transformed image processing and now reduce load times effortlessly
What is our primary use case?
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.
What is most valuable?
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%.
What needs improvement?
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.
For how long have I used the solution?
I have been working with Serverless architecture for about a year and a half.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and support?
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.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Serverless functions have transformed how we deploy APIs quickly and pay only for actual usage
What is our primary use case?
My main use case for Serverless is to deploy functions which we can scale as our user base grows. I am currently using Vercel in my company where I deploy our API functions to these specific Vercel services, so we can scale as our user base grows. I deploy these API endpoints and all.
What is most valuable?
In my experience, the best features Serverless offers are that for many of the serverless services, you don't need to pay upfront. You can pay as your usage grows. As your user base grows for the particular function or your application, you just pay whatever you use instead of paying upfront like other VPS or VPC services.
The flexibility of Serverless has helped us very much. We can freely do POCs, Proof of Concepts, and we don't need to worry about deploying. We can just deploy it and test it before going live. As it is pay-as-you-go, we don't need to first set up a server instance. We can just get up and running with this serverless function.
Serverless has positively impacted my organization by helping us deploy our application quickly to the web and the internet. We don't need to first set up the infrastructure. We can quickly set up a serverless function and deploy our app without paying an upfront amount.
I can share specific outcomes and metrics I have noticed since using Serverless. Previously, when we were deploying it on VPS, our whole day was spent on setting up a VPS and setting up all the CI/CD pipelines. With Serverless, it is instant. In just 10 to 15 minutes, you are up and running.
What needs improvement?
I don't know how Serverless can be improved. I am not thinking about any such instance of improving Serverless.
I would say in the debugging, we could maybe improve or in monitoring. In the monitoring aspect, we can improve. It would be helpful to get holistic information about your Serverless app that you have deployed. I cannot think of any specific instance at this moment to add more about the needed improvements, especially around monitoring.
For how long have I used the solution?
I have been using Serverless for the past one year.
What do I think about the stability of the solution?
In my experience, Serverless is mostly stable.
What do I think about the scalability of the solution?
Serverless is quite scalable. As your user base grows, your serverless functions are incredibly scalable, and they can adapt quickly. They can spin up instances quickly and as fast as possible, so they are quite scalable.
How are customer service and support?
For Vercel and Cloudflare, customer support is good.
Which solution did I use previously and why did I switch?
I did not use a different solution. From the start, I was using Serverless only.
How was the initial setup?
My experience with pricing, setup cost, and licensing was good. I did not have any issues with that. It was acceptable with no issues.
What was our ROI?
I have seen a return on investment. Previously, we needed one full DevOps person to handle all of that, but now with Serverless, our developers can easily and quickly get the application up and running. With Serverless, we needed fewer employees and also saved time.
Which other solutions did I evaluate?
From the start I was using mostly Serverless, so I did not have to evaluate much. I know about Serverless and its benefits and drawbacks.
What other advice do I have?
For POCs and for setting up your application quickly, you should definitely consider Serverless. However, if you have an application which you know from the start will be very popular, then you should consider a VPS. My overall review rating for Serverless is 8 out of 10.
Automation has simplified API deployment and now reduces time, cost, and team size
What is our primary use case?
The main use case for Serverless is to enable seamless serverless operations. I use Serverless for building an API that serves native IoT devices, which serves as our use case where we use Serverless for seven days. The API I built for the project includes login and registration functionalities, and it automatically changes the user experience accordingly.
What is most valuable?
Without managing a server, we can utilize Serverless in various aspects of our work. Without managing a server, we can automatically deploy and manage AWS Lambda functions, allowing us to complete everything without job-related hassles.
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.
What needs improvement?
I see that the local development setup in Serverless is more complex, so if you provide examples or automation that we can test and deploy locally on a local machine, then automatically shifting all methods or functions into production would significantly improve efficiency.
For how long have I used the solution?
I am using Serverless for about one year.
What do I think about the stability of the solution?
Serverless is stable in my experience.
How are customer service and support?
Serverless has customer support, which I have found helpful.
Which solution did I use previously and why did I switch?
Before Serverless, I used manual deployment methods such as Docker to create container images and deploy them on a VPS server or AWS EC2, but with Serverless, we no longer deal with that hassle, and this led me to choose Serverless.
What was our ROI?
I have seen a return on investment with Serverless. As I mentioned, it saves money, time, and requires fewer people for a project because one person can handle everything, deploying using a single command, with testing and running all managed seamlessly without needing multiple people for various purposes. When a company chooses Serverless, I consider it a great investment.
What other advice do I have?
I did not face any challenges while using Serverless for my login and registration APIs, as we integrated storing user credentials and user information in the AWS relational database, so every coding infrastructure we are deploying works smoothly.
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.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Automated testing and cost control have improved while production readiness still needs work
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Serverless for around five or more years.
What do I think about the stability of the solution?
Serverless is stable most of the time, though we occasionally face issues, but that is primarily due to our usage of the public cloud.
What do I think about the scalability of the solution?
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.
How are customer service and support?
Customer support from AWS is marvelous.
Which solution did I use previously and why did I switch?
Previously, I used Kubernetes and OpenShift as production solutions before switching to Serverless for staging.
How was the initial setup?
My experience with pricing, setup cost, and licensing for Serverless spans around five or more years.
What was our ROI?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
showing 1 - 10