Serverless Reviews

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.

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