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.

My main use case for Serverless is to run simulation workloads currently. A quick specific example of a simulation workload I'm running with Serverless is that we have a product which runs circuit simulations. This can traditionally run on HPC clusters, but we are also working on running it on a serverless architecture for these simulation jobs. We are currently in the POC area and will spend more time to understand how our customers can use this architecture to achieve better turnaround time for their simulations instead of going the traditional HPC schedule-driven approach.

The best features Serverless offers for my use case are specific things within the simulation where we call it optimization. Batch simulation does not work out for us because this is more of an interactive session wherein a thick client can start an iteration and we need remote processing for the actual optimization. Once the optimization result for a single optimization gets back, the thick client can tune it and send out the next optimization. This is the major thing we are trying to achieve using Serverless.

This has changed the workflow and experience for my users, which is a big plus because the optimization jobs are very latency sensitive. We cannot do this using a traditional HPC scheduler because of how HPC schedulers work. We are looking at Serverless for quick scheduling of these jobs, and the turnaround time for optimization has increased tremendously. This is a big win.

I do not have any specific suggestion at this point on how Serverless can be improved for my use case. Perhaps down the line I will have more information.

The reason I choose a seven is primarily resource-based scheduling. This is what we are not able to get around on Serverless. It solves a main use case, but it still does not solve our batch executing and batch simulation use cases. However, if this could be one solution to move away from a traditional HPC scheduler, I would have definitely given a ten.

I have been using Serverless for just about three to four months.

Serverless is stable in my experience so far.

Serverless's scalability is something that since we have very specific needs, we are not looking at scalability at this point. However, down the line, that is going to be really important if we do a production deployment wherein we expect maybe tens to hundreds of users using it at the same time. That is when the scalability will be a big challenge. At this point, we do not have an issue with scalability.

The customer support experience has not been applicable to me, as this was done by my solutions architect, so I never interacted with the customer support.

We did not previously use a different solution, as we are a traditional HPC batch scheduler.

We did not previously use a different solution, as we are a traditional HPC batch scheduler.

We did not previously use a different solution, as we are a traditional HPC batch scheduler.

I have seen a return on investment so far, as I can definitely see a cost saving when it comes to keeping a virtual machine running. Serverless actually saves money for our POC. I can definitely say that. However, it is too early to say a comparison between how much we are saving from a traditional scheduler to Serverless computing.

My experience with pricing, setup cost, and licensing is that some of these are done by my solutions architect and I will not have enough information about that in my current role as a product manager.

Before choosing Serverless, I did not evaluate other options, as we are still working with Serverless. We have not looked at other solutions.

The transition from HPC clusters to a serverless architecture is going so far by facing the biggest difference where the traditional HPC schedulers have quite a bit of customization when it comes to scheduling jobs. It is traditionally a batch execution. Going for Serverless, we are looking at far quicker scheduling of jobs, but we currently are facing some issues when it comes to using the resources for the jobs and getting the image loaded because the image is very huge.

It is too early to tell if I have any numbers or specific metrics on how much the turnaround time has improved since moving towards Serverless. We are still working on optimization of this entire workflow. We are still trying to figure out all the use cases we can work with. We still need to benchmark the results, so it is too early to provide that information.

The advice I would give to others looking into using Serverless is to especially focus on any traditional HPC application, try to modularize your application and figure out specific workflows which are well suited for Serverless and migrate those into Serverless. I definitely see cost saving, quick scheduling of jobs and the overall improvement in efficiency. I gave this review a rating of seven out of ten.