Serverless Reviews

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.

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.

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.

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

I rate customer service a four out of ten.

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.

My main use case for Serverless is hosting applications and running code.

I can provide a specific example of how I'm using Serverless for stream applications or running code: I am running applications without servers, executing ad hoc tasks, Lambda tasks, or function tasks.

I have additional context about my main use case with Serverless. We did not want to host servers and pay for idle servers just to run code and ad hoc tasks, so we switched to Serverless. We now only pay for the amount of time we are running applications or the amount of time we are using the application.

Serverless has positively impacted my organization, and we are seeing a positive response in terms of pricing and scalability.

Serverless offers valuable features including ad hoc task execution, event-based triggers, integration with other features, other functions, and other applications.

The integration with other features and applications has particularly helped me. When something arrives in my S3 bucket or any other source, it triggers an event and runs Serverless applications to execute tasks.

Serverless can be improved with more stability, more scalability, and more integration with other applications.

There are improvements needed around triggers and event-based functionality. Sometimes we see old results instead of new results when events trigger. This area requires improvement.

I rate Serverless an eight because it can be improved in stability. Sometimes we see older results, and sometimes it doesn't trigger based on the event. Additionally, sometimes we get charged more money than we actually use, so these areas require improvement.

I have been using Serverless for two to three years.

Serverless is stable, but it can be improved.

Serverless can scale on demand.

Serverless customer support is good.

We have not used any other solution before this.

My experience with pricing, setup cost, and licensing demonstrates that pricing is good because we only get charged for the amount of time we use and the amount of time we trigger events. Setup cost is minimal because it is easy to use. It requires only some code, which is why it is easy to set up.

I have seen a return on investment. Money and time are saved, and it is deployed in a public cloud on AWS.

We have not evaluated any other option before choosing Serverless.

My advice to others looking into using Serverless is that you can use it if you want to save money, if you don't want to manage servers, if you only want to be charged for the amount of time you use, and if you want to run code and ad hoc tasks. Serverless offers great scalability. I rate this product an eight.

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.

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.

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.

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.

My team has been using Serverless for the last three to four years.

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.

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.