Serverless Reviews

My main use case for Serverless is to deploy the application and save the cost of the servers. I have deployed some simple React-based applications and React and Node-based applications using Serverless. I have developed some extractors such as Google extractor in our team, which will be hosted in Serverless to save the cost of the server.

The best feature of Serverless is cost; when the application is in use, then it will incur cost, unlike traditional servers where it is the cost of all the uptime. Using Serverless saves the cost of my team. Serverless has positively impacted my organization by doing cost cutting, as we had achieved cost cutting of more than 50,000 using this.

We achieved that cost cutting mainly through less maintenance, and it incurs cost only during the running time, not during idle time as normal servers do.

Serverless can be improved by effectively handling large scale applications, as large scale applications would save more money.

In my current field, I have been working for more than five years. I have been using Serverless since one year.

Serverless is stable.

Serverless scalability is very good; however, for large applications, I think it is not working well, but for small functions and small applications, it is very good.

I did not attend any customer support yet because it does not require, as my IT team handles it very well.

Previously, I was using servers and VMs for hosting the application, and we switched due to cost cutting.

I have seen a return on investment, as Serverless saves a lot of idle time money.

I do not know about the pricing, setup cost, and licensing, as that is handled by the sales team, my other team.

We did not evaluate another option before choosing Serverless because we had taken all of the demos and it was very cost effective for us.

Serverless is good for small based applications, but for large applications, it will not perform very well. If you have any small application, then you can go ahead with Serverless, as it will save you a lot of money and a lot of effort in managing and securing servers; you only need to secure hosting the application. I would rate this product a 7.

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 in home automation products, embedded systems, and smart car chargers. Serverless fits into those products because when you say to turn on the light, it actually triggers a Lambda function, a Serverless function, which executes the command of turning on the light.

Serverless also applies to embedded systems and smart car chargers.

The best feature Serverless offers in my experience is that it is Serverless, which means we don't have to manage anything. This has helped my team and our projects by being cost-effective, as well as enabling us to build event-driven solutions, which suits Serverless perfectly.

Serverless has positively impacted my organization by making us more agile in giving releases. Being more agile has benefited my teams by allowing us to continuously maintain our Node packages and different scripts, which are now more easily manageable.

I believe Serverless can be improved as I have faced some pain points and challenges. We need more execution time. I chose a rating of nine out of ten because it cannot run long-running processes, which keeps it from being a perfect ten.

I have been using Serverless solutions for more than six years.

We are referring to enabling Serverless solutions for our clients, and we have been using Serverless solutions for more than six years. My advice to others looking into using Serverless is to go for it, as it is highly recommended. I give this product a rating of 9 out of 10.

My main use case for Serverless is to deploy serverless databases using AWS Serverless, and I have deployed ETL pipelines and data ingestion pipelines using AWS Serverless services. Generally, I design architectures for microservice apps using AWS Serverless services.

My main use case is to make the system increasingly fault-tolerant and scalable, so I always prefer to use AWS Serverless services because they provide precisely the kinds of solutions that help me design scalable and fault-tolerant solutions. One of my recent architectures involved hosting a data architecture that can store infrequently accessed or rapidly evolving loads on our system. For that, I used Aurora Serverless database that can provision its capacity based on the use it receives. In combination with Aurora Serverless, I used Lambda functions for my validation and other operations. Lambda is a serverless service that provides a very prominent capability of scalability and can scale on its own. When designing any solution, I look for these capabilities, and all of the services I have mentioned provide me these capabilities.

In my experience, the best features that Serverless offers are quite fault-tolerant services that are getting updated and worked on quite frequently by AWS, so they are improving over time. I have comprehensive use of AWS Lambda functions, as I have been using them for about three years, and I was quite impressed with the studio code option for the Lambda function. I could do quite much coding in that interface, which I think was quite a good improvement because it is a small but very impactful thing that AWS did. My judgment criteria is the self-improvements that the provider takes seriously, and additionally, I have not gotten any issue, any breakage, or any downtime in these services, so I think AWS Serverless performs quite well in any use case. It is quite maintained, so I do not have to worry about anything.

These kinds of small improvements in Serverless help you be well integrated with the whole system, as I do not have to manage a coding environment separately from my cloud console. It is all happening in one place, which I find quite helpful. These kinds of small improvements help me get better integrated with the system.

Serverless has positively impacted my organization in one of its solutions for architecture that it provided to a very big real estate company in the United States. It used a very old technology called Pentaho, where all of the data operation workflows were running. AWS Serverless helped my company and my team to migrate these operations to AWS Step Functions workflows, which are cost-effective and help integrate Lambda into all of its steps. As a result, all of the workflows that were running in the old technology Pentaho were migrated to AWS Step Functions, and we saved quite a lot of cost.

With the upcoming technology change and the migration towards Generative AI and the exploration of large language models, it would be quite helpful if serverless services evolve with that. I have observed that AWS Serverless services can have quite good uses for agentic AI in future improvements, and if those capabilities were to be brought into Serverless, that would be a big plus for all these services and provide a very competitive edge in the serverless services market.

I have been using Serverless for three years.

I have not previously used a different solution. I have worked on Serverless without getting to use anything else.

After migrating to serverless, we saved about 50% of the cost that was occurring in the previous architecture, and our operation time also got reduced by about 40% compared to the previous architecture due to the use of Step Functions, Lambda, and Aurora Serverless, which are all services managed by AWS.

All of the serverless services that I have used have been quite friendly in processes and pricing. My advice for others looking into using Serverless is to choose serverless services according to their architecture, as they are beneficial in most use cases. My overall review rating for Serverless is 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.