My main use case for Serverless is that all the APIs we made in my previous project were serverless, so each API would be a microservice or kind of a thing, which deploys in a different Lambda together, and it runs as serverless.

A quick example of one API I built as Serverless is one where we need to sync data on an interval basis, so the code for that is written in a Lambda where it connects, imports the secrets, and connects to the database, respects services, takes the data, and syncs it by defining some business logic there. I deployed that as a separate Lambda which helped me to trigger whenever it is required, even manually and on a sync basis using cron. This is one of the examples, and there are many APIs that we built.

My main use case for Serverless was that initially when we started the application, we realized that the application code would be a minimal thing, so we started using Serverless to deploy easily without any downtime or without a fraction of a second of downtime. It really worked well; during business hours, we can deploy some changes because it affects only that particular API or only that particular build, and everything is kept out with no downtime. That is the main reason.

The best features Serverless offers are the fact that there is no need to bother about the servers and no need to worry about downtime, which is only a fraction of a second when deploying using Serverless. You can also work on independent Lambdas and even test independent Lambdas separately.

When I say developers have more control, I have noticed changes in productivity or deployment speed; it feels faster because in one of my projects, where all the code is hosted in EKS clusters, the cron jobs and post-trigger events were separated using Lambda. Whenever developers wanted to fix these things, it was easier to test only this particular job or these particular events and push them to production instead of worrying about the other code.

There are several areas where Serverless can be improved. It is not feasible for a huge amount of codebases. That is one thing I noticed gradually. When the application is too large, you cannot use Serverless easily, which becomes tough to handle. If your APIs are rapidly increasing, there are Lambda limitations in AWS, and I am not sure how it works with other serverless options, but this is my experience with Serverless using Lambda.

Monitoring and debugging are easier compared to others, in my belief, so I do not see any necessary improvements over there. The only improvement which can be made, which we mitigate by using some hacks, is the initial start time. However, I think we mitigated that using different hacks. The challenge lies in how to scale the code with respect to Serverless; for instance, if I have a huge legacy database, I need to think about how to migrate it to Serverless efficiently, even with a substantial codebase.

I have been using Serverless for the past four years.

Serverless is stable.

The scalability of Serverless is limited; as you increase your code, it is not scalable, and we need to think out of the box to solve several problems.

We have never used a different solution prior to Serverless.

My experience with pricing, setup cost, and licensing was fine; pricing is very good for minimal or moderate application code. Pricing increases with larger codebases, but for a normal moderate codebase, it is good. The setup is minimal, and licensing is also acceptable since it is handled by Amazon.

I can confidently say we have seen a return on investment, but I do not have specific metrics to share.

I think they evaluated options before choosing Serverless, but I was not part of that process. They looked into hosting on EC2 and deploying on the EC2 EKS cluster.

When I say I can test independent Lambdas separately, it has helped my development or deployment process because, for example, when using an OpenAI API to do some data, if the API key is expired, instead of blocking all other APIs in production, I just need to update that particular Lambda or that particular API. I can do that and test it, with no need to regression test all the other code or even with respect to user interfaces; they will see only that one API, which may be failing, but they will not see any blockers in production until I fix this. I think that is the best use case. Even though there are drawbacks when the code increases rapidly, at a minimal level when you have optimized and minimal code, this could be a good scenario. If you have a huge code, there is a chance to use Serverless Lambdas in scenarios where you want to trigger jobs or perform jobs on a regular interval and host them separately so that they do not interact with or disturb your code working flow. If there is any mismatch in the sync of the data, I can go and change that Lambda code, deploy it, and test it as serverless, with no need for regression testing. You can separate the actual code and these kinds of jobs.

Serverless has positively impacted my organization because I can deploy without any downtime in the majority of cases. I do not say in all cases, but in most. The most significant impact is how developers control it; if something goes wrong, they focus only on that particular Lambda or API or the sync job instead of worrying about the entire codebase and checking whether everything is fine.

My advice to others considering Serverless is that if their codebase is simple, they can migrate in the future. If there are concerns about codebase growth, they might want to consider migrating back to EKS or another solution, but they can use Serverless for the time being if it makes their life easier. I would rate this product a nine out of ten.

My main use case for Serverless is the deployment of web applications. For the deployment of web applications, I write the configurations, write the code, then execute it, and I get the lambdas deployed on AWS and all the surrounding services.

Serverless offers many best features; it is really easy to use, very developer-friendly, and has a great community.

The developer-friendliness of Serverless shows up in my day-to-day work because it is easier for developers to understand what they are doing and what they need to do.

Regarding features, it is scalable and has integrations with many things.

Serverless has impacted my organization positively, but I used it on just one project, so it is difficult to judge at the organization level. For that one project, I noticed a specific positive outcome as a time saver because not all the infrastructure needs to be done by the architects. It can be done by developers.

Improving Serverless is a difficult question because I am not deeply familiar with Serverless, so it is really difficult for me to judge. Probably they would introduce an alternative to the way they currently create the infrastructure with CloudFormation. By default, it uses CloudFormation, which sometimes can be a problem. Probably it would have an integration with something like Terraform or another alternative.

I have been using Serverless for around half a year.

Serverless is stable as I perceive it.

The scalability of Serverless is great, and I have nothing to complain about because it actually depends on the cloud that is used.

Serverless does not have customer support.

I previously used Terraform sometimes, but it was just a client's requirement.

I have not seen a return on investment.

My experience with pricing, setup cost, and licensing is that it is free, so I have no experience with costs.

Before choosing Serverless, I did not really evaluate other options.

The advice I would give to others looking into using Serverless is to not be afraid and to try it. I would rate this review an 8 out of 10.

Our main use case for Serverless is to build Serverless APIs, and the complete back-end is built with Serverless. A specific example of an API or back-end workflow built using Serverless is a parts integration related to buying parts catalogs, which is a third-party integration API, and everything was built using Serverless.

Serverless offers the ability to test locally, as it can spin up a bunch of AWS resources and mock them as if they were deployed onto the cloud, allowing development locally without having to spin up the resources into an actual AWS account.

The local testing feature has helped speed up development for my team without having to wait for deployment into the cloud, and for debugging purposes, it has been beneficial to find out when things are not working properly as I can step through the code and see or log local errors.

Serverless has positively impacted my organization as it has been a good experience for the team overall because it is a new framework that we had to learn, and cost-wise, it helps because moving to Serverless means you do not have resources spinning all the time. It only uses Lambdas, and it is infinitely scalable, so you only use resources as the quota is used up or as the Lambda is invoked, with team collaboration being mostly about everyone learning something new together and giving each other tips.

I struggled with wanting to put breakpoints throughout the code and then use the debugger. At the time, I was not able to step through the code with breakpoints, so if Serverless had that support, that would be great.

The overall documentation is great, and I do not have anything else to add about needed improvements.

I have been using Serverless for about a year and a half.

Serverless is very stable.

Our customer support experience has been straightforward as we have not really had to contact them.

Previously, we had a .NET Core back-end deployed onto ECS clusters, but when we switched over to Serverless, there is less DevOps involvement, and we take all the AWS resources we need, while Serverless helps deploy everything.

My experience with pricing, setup cost, and licensing was all very straightforward and very easy to use.

I have seen a return on investment in terms of time saved. To be honest, we were using .NET as our back-end for the most part, but switching over to use Serverless made the development cycle a little bit faster, as we use one-week sprints rather than two with .NET.

Before choosing Serverless, we evaluated other options, including AWS SAM, but it was mostly just between these two options.

Our customer support experience has been straightforward as we have not really had to contact them. I would rate this review an 8.

My main use case for Serverless is deploying my services like API services. A specific example of how I use Serverless for my API services is that I need to create one API where I want to expose my services outside by creating that. For that, I don't have the server to deploy my application. Instead, I just create a YAML file and deploy Serverless application onto my Lambda without any server.

The best features that Serverless offers include being without the server, which itself says we don't need to depend on the server maintenance, and so we don't need to worry about these server things. This aspect has really helped my day-to-day work because we don't need to maintain the server. We have gotten rid of the headache of maintaining the server, server maintenance, memory storage, and where we host that server. All these headaches are gone now just because of Serverless in AWS.

I choose eight out of ten because to go ahead with Serverless, we need to do YAML file creation and other format file creation. So it might not be having the idea. That is the only thing that I observed.

I have been using Serverless for about three to four years.

In my experience, Serverless is stable.

In my experience, Serverless's scalability is very effective, with options for whatever the memory size or whatever the scale that we want, based on the demand. During the peak demand, we can increase the scalability automatically. It can scale during the peak hours, and during the non-peak hours, it downgrades that scalability. This is really helpful.

Whenever we raise an issue to AWS, the customer support response comes within twenty-four to forty-eight hours, as I have heard from my organization.

Previously, we used a server only before switching to Serverless. Before choosing Serverless, we actually ran our application on a JBoss server, and also we hosted some of the applications on a Pyara server as well. From Pyara and JBoss, we migrated to Serverless.

Apart from that, I didn't use any other Serverless solution.

I have definitely seen a return on investment with Serverless. From the developer perspective and coming to the money perspective, we don't need to maintain it. A lot of money could be saved, because creating a server is one thing and maintaining it for a lifetime. Now the lifetime thing, we don't need to take care of. This is really helpful.

My advice to others looking into using Serverless is that you don't need to worry about the server maintenance, the servers, and where you host the servers. All these headaches go away. Definitely it's good to use. All the headaches that we have been doing for all these years can be gotten rid of, definitely.

This has been a great initiative taken by AWS. Previously, we thought that we cannot host our applications without any server, but AWS proves us wrong by creating a Serverless application, the option to deploy our applications without any server. This is a really great initiative done by AWS. I rate this solution an eight out of ten.