Serverless Framework (Deprecated Listing. See New Listing)

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.

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.