Serverless Reviews

My main use case for Serverless is to deploy functions which we can scale as our user base grows. I am currently using Vercel in my company where I deploy our API functions to these specific Vercel services, so we can scale as our user base grows. I deploy these API endpoints and all.

In my experience, the best features Serverless offers are that for many of the serverless services, you don't need to pay upfront. You can pay as your usage grows. As your user base grows for the particular function or your application, you just pay whatever you use instead of paying upfront like other VPS or VPC services.

The flexibility of Serverless has helped us very much. We can freely do POCs, Proof of Concepts, and we don't need to worry about deploying. We can just deploy it and test it before going live. As it is pay-as-you-go, we don't need to first set up a server instance. We can just get up and running with this serverless function.

Serverless has positively impacted my organization by helping us deploy our application quickly to the web and the internet. We don't need to first set up the infrastructure. We can quickly set up a serverless function and deploy our app without paying an upfront amount.

I can share specific outcomes and metrics I have noticed since using Serverless. Previously, when we were deploying it on VPS, our whole day was spent on setting up a VPS and setting up all the CI/CD pipelines. With Serverless, it is instant. In just 10 to 15 minutes, you are up and running.

I don't know how Serverless can be improved. I am not thinking about any such instance of improving Serverless.

I would say in the debugging, we could maybe improve or in monitoring. In the monitoring aspect, we can improve. It would be helpful to get holistic information about your Serverless app that you have deployed. I cannot think of any specific instance at this moment to add more about the needed improvements, especially around monitoring.

I have been using Serverless for the past one year.

In my experience, Serverless is mostly stable.

Serverless is quite scalable. As your user base grows, your serverless functions are incredibly scalable, and they can adapt quickly. They can spin up instances quickly and as fast as possible, so they are quite scalable.

For Vercel and Cloudflare, customer support is good.

I did not use a different solution. From the start, I was using Serverless only.

My experience with pricing, setup cost, and licensing was good. I did not have any issues with that. It was acceptable with no issues.

I have seen a return on investment. Previously, we needed one full DevOps person to handle all of that, but now with Serverless, our developers can easily and quickly get the application up and running. With Serverless, we needed fewer employees and also saved time.

From the start I was using mostly Serverless, so I did not have to evaluate much. I know about Serverless and its benefits and drawbacks.

For POCs and for setting up your application quickly, you should definitely consider Serverless. However, if you have an application which you know from the start will be very popular, then you should consider a VPS. My overall review rating for Serverless is 8 out of 10.

My main use case for Serverless is developing full stack applications and APIs.

The best features Serverless offers is the ease of going to market. It is easy to simply go and deploy your code. You just focus on the functionality while the infrastructure is already set up there, so I do not have to spend hours setting up the infrastructure.

Serverless is easy to start with, especially for features like minimum viable products. If I want to develop a full set of applications and go to market immediately, then I prefer Serverless. Also, if you want to scale up, then Serverless is the best way. It is scalable and more secure, and it is on-demand, so it is easy to reduce or increase the load based on our needs. It is automated and very cost-effective. We are not billed per second like with provisioned services. Serverless offers a great pay-as-you-go model that is really excellent. It also has very good integration with all services from front-end to back-end, following a microservices concept. I love this concept and the supporting features including X-ray to find any issues in terms of failures, or CloudWatch to gather logs. It is an amazing set of components and microservices working together to provide solutions to single problems.

The most important feature is time-saving. When we have an idea and want to test it, we need to go to market quickly. Developing and deploying the MVP to check the idea is really a time-saving approach that has impacted our organization.

Almost 60% of time was saved when we considered Serverless. Because we always had to wait for server provisioning and other provisions if we wanted to do something else or pursue other projects using non-serverless methods. But in Serverless, the infrastructure is already set up, so we just need to go and deploy and start using it. We almost saved 60% of time. Cost-wise, we also saved a lot of money by not buying provisions and not paying for idle time. In Serverless, there is no need to pay for idle time. That is the core advantage of using Serverless.

Serverless can be improved with more usage videos. I found a lot of online tutorials using Serverless, but it could have more use cases with more detailed videos. For example, videos on DynamoDB single-table design and how to develop efficiently would be helpful. Additionally, detailed content on how to improve Lambda debugging and comprehensive documentation would be helpful for developers.

I have been using Serverless for the last four to five years.

I can provide details of a recent project called Project Creative Gifts, which I developed fully with AWS Serverless technology. It is an online gift e-commerce store developed using Angular as the front-end and Node, NestJS as the back-end. The complete solution is deployed in Serverless on AWS. I used various Serverless technologies and tools to deploy this application. For the front-end, I used S3 bucket web hosting and CloudFront as a CDN. For the back-end deployment, I used API Gateway, Lambda, and DynamoDB. For authentication purposes, I used Cognito to authenticate the users.

It is an e-commerce online store with a lot of access points to store and retrieve data. I considered various options to save money and keep a single table design. I conducted a lot of research and created multiple access points to securely store and retrieve data in a more effective and cost-effective manner while maintaining performance. This presented a challenge, but I finally managed to solve it by placing the design appropriately.

So far, I am satisfied with Serverless. Everything is integrated and everything is set up perfectly. I would rate this review an eight 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 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.

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.

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.