Serverless Framework (Deprecated Listing. See New Listing)

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.

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.

The main use cases for Serverless are those products or project ideas in which we don't want running servers. For that, we have different frameworks available, such as Netlify, Cloudflare, and AWS serverless architecture. I am using that.

I have made a project for personal learning that was an MCP monitor in which I built observability that captures the logs provided by the MCP server and shows it on the platform itself. As we clearly know, it requires basic CRUD operations, as there is no need for running servers. Logs happen and are just sent into the server, such as normal edge functions, which is why I built this project in Serverless using Cloudflare functions.

Initially when I was working at a previous company, we were using a server with MongoDB and AWS EC2 instances, but the problem was that without any customers, they were paying huge charges for a medium-level server. After realizing that the product could be transitioned to Serverless architecture, they moved to Serverless and started using AWS Lambdas, leading to significantly lower costs. That transition allowed them to ship multiple features without worrying about costs. Initially, with a server costing without any initial customer base, after moving to Serverless, they shipped multiple features, started very early, and were able to deliver many things without the cost headache.

The best feature that Serverless provides is the pay-per-use model in which you only pay for what you have consumed. In short, if you haven't consumed anything, there are no charges. That is the best thing that I have found within Serverless architecture. It is very straightforward to begin, with different services such as Cloudflare, Netlify, and various others providing this functionality, which is very useful and efficient. The first thing I appreciate is the pay-per-use model. The second is that it's easier to begin, and the third is that we have plenty of resources available to get started with this.

If we talk about this project itself in relation to the pay-per-use model, it shows that you don't get charged for the initial setup. Most projects are built in the form of an MVP and later get converted into paid products as soon as users or customers get onboarded. With a server, we need to take a particular virtual machine, set up, and run the server, which is very costly and not cost-friendly. However, with Serverless, the cost depends entirely on how many function calls are happening, so the cost is zero in the initial phase. That is why it makes developers or product managers get started with any idea very seamlessly without the headache of cost.

The only improvement I want in Serverless is to address the cold start issues that exist, which is an obvious concern, but I would appreciate seeing improvements in this area.

I have been using Serverless for more than two and a half years.

Serverless is completely stable and performs very consistently.

Serverless is scalable, and the services connected to it generally have autoscaling. The container concept exists in Serverless, especially in AWS and GCP, where different containers execute functions. We can increase memory and timeout, and it autoscales itself depending on the cloud provider. They create different containers, with up to a thousand containers able to exist simultaneously, and each container can handle multiple invocations of any function.

I have not needed customer support for Serverless solutions I have used.

Initially when I was working at a previous company, we were using a server with MongoDB and AWS EC2 instances, but the problem was that without any customers, they were paying huge charges for a medium-level server. After realizing that the product could be transitioned to Serverless architecture, they moved to Serverless and started using AWS Lambdas, leading to significantly lower costs. That transition allowed them to ship multiple features without worrying about costs. Initially, with a server costing without any initial customer base, after moving to Serverless, they shipped multiple features, started very early, and were able to deliver many things without the cost headache.

I did not evaluate other options after moving to servers and instead moved to Cloudflare for Serverless, which offers a good number of functions and free tiers that make project building very straightforward.

Based on my experience with pricing, setup cost, and licensing, the offering is good.

I did not evaluate other options after moving to servers and instead moved to Cloudflare for Serverless, which offers a good number of functions and free tiers that make project building very straightforward.

The best feature that Serverless provides is the pay-per-use model in which you only pay for what you have consumed. In short, if you haven't consumed anything, there are no charges. That is the best thing that I have found within Serverless architecture. It is very straightforward to begin, with different services such as Cloudflare, Netlify, and various others providing this functionality, which is very useful and efficient. The first thing I appreciate is the pay-per-use model. The second is that it's easier to begin, and the third is that we have plenty of resources available to get started with this.

The only improvement I want in Serverless is to address the cold start issues that exist, which is an obvious concern, but I would appreciate seeing improvements in this area. I would rate this solution an eight out of ten.

My main use cases for Serverless include automation or chatbot implementations and real-time media processing.

A specific example of how I used Serverless for automation or media processing is a project in which we had to gather all the emails regarding our users that subscribed to our product. We get those emails from a third party and add them into our marketing system to use that for daily marketing, making a funnel for different scenarios in our product according to different people that subscribed based on our plan.

Serverless offers easy scalability whenever I want it, with no problem when there are many requests. I really appreciate that there is mostly no management of the servers that I have to do and that it is basically available all the time. Automatic scaling is another key feature that I really value as it helps manage resources whenever my project or audience grows over time.

Automatic scaling and always-on availability have helped me in my day-to-day work and on specific projects because without Serverless, I would not have been able to handle everything on my own. With Serverless, since I have to do no server management and do not need a specific person for DevOps, it becomes easy for me to focus my energy on the high-end tasks that I really want to do. Regarding automatic scaling, it really helps the resources to scale up or down instantly based on incoming traffic, and it also addresses our budget constraints since we do not have to buy a large server initially, but rather it helps extend the time.

Serverless has positively impacted my organization concerning constraints, as we teach everyone about DevOps and how it will scale. Now we need fewer people to perform the types of tasks that Serverless could easily manage and execute, allowing us to take advantage and do the work we have to do in our specific spaces and focus on high-impact tasks rather than working on things that would not be as impactful.

In my opinion, Serverless could improve its performance regarding the major drawbacks when functions are idle, as it takes a bit of time to start over and begin a new container. This delay could really help performance. Another consideration is cost since if your team does not have experience with the financial implications of DevOps, the high volume could end up being more expensive compared to buying a dedicated server. I also feel vendor lock-in is an issue that is not very large but can become a problem if teams become overly reliant on one cloud service, making migration more difficult in the future. If this aspect could be managed properly, it would be great.

Regarding the needed improvements related to developer experience, debugging, or monitoring, it is easy to start things out, but tracing errors across distributed third-party functions can be challenging without special tools. Cold starts, unexpected costs, vendor lock-in, and debugging difficulties are major issues that we have to address.

Other improvements needed for Serverless include performance enhancements across various cloud server providers. Every Serverless company has its benefits, pros, and cons. Some may not scale well with AI and GPU integration right now, while others, such as Cloudflare, perform exceptionally well. It really depends on what you want to achieve, and there are numerous Serverless providers you can utilize to meet specific use cases.

I have been working in my current field for almost six years.

Serverless is stable in my experience.

Serverless's scalability is really easy for me.

Customer support does not tend to help quickly, typically taking three to four hours in my experience.

I previously used containers and virtual private servers (VPS), which I still have, when we were building demo products and small or medium persistent applications. When things became complex, involving more microservices, I would use Kubernetes, depending on the service or the specifics of what we wanted to create.

Regarding return on investment, I think AWS offers numerous resources when we need to start a new product, which has greatly assisted us.

There is nothing to consider regarding pricing, setup costs, or licensing as you do not need traditional software licenses or computing engines with Serverless; you simply pay as you go.

Before choosing Serverless, I evaluated other options, and it really depends on the project I am working on because their constraints vary. If the constraints require a product that can scale easily and uncertainty about potential breakdowns exists, I would lean toward Serverless. However, if the project had different constraints, I would consider other options, as it all comes down to use cases and budget.

I rate Serverless an eight out of ten.

I give it an eight because it is working for me, and I am fully invested in it. I use it directly every day and have not encountered many difficult tasks that I need to manage, either directly or indirectly.

Regarding Serverless's AI capabilities, I think there would obviously be automated guardrails, and if we talk about AWS, they monitor runtime, identity access, and prompt injection strictly. They really provide good Serverless capabilities while acknowledging there are security risks and controls.

I consider Serverless reliable concerning accuracy and output for my specific needs, as I did not see any issues with the services I am utilizing. However, I faced some issues with vendor lock-in since all of our infrastructure was managed in one account. When that account was temporarily blocked for an unjustified reason on their side, it became an issue for our whole project and caused significant costs and loss of users because of that single incident.

My advice for others looking into using Serverless is that you should not use Serverless if you do not understand its constraints, such as cost and scalability with respect to cold starts and vendor lock-in. If you are completely new, you should first learn about your use case and then proceed carefully. My overall rating for Serverless is eight out of ten.

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

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.

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.

I have been using Serverless for the last six months.

Serverless is stable in my experience.

The scalability of Serverless for my applications is good.

I did not connect with customer support for Serverless, so I do not have feedback about that.

I did not use any previous solution other than the native VM. Serverless is good now and will replace the server.

I purchased Serverless through the AWS Marketplace.

I did not evaluate another option before choosing Serverless.

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.

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.

I did not evaluate another option before choosing Serverless.

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.

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

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

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

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

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

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

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

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

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

I have been using Serverless for about five years.

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

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

I had not used a different solution.

I also evaluated making use of EC2.

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