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

My main use case for Serverless is to deploy Lambda functions from AWS. A specific example of how I use Serverless with Lambda functions is that we deploy Lambda functions for any transfer-related and wire-related things because we are a fintech company, and we use Serverless framework to deploy Lambda, API Gateway, and S3 buckets.

Currently, I do not see any issues regarding our main use case with Serverless; we have written this framework in the YAML language, and everything is going smoothly, so we are enhancing the scripts.

Serverless offers many available plugins that support the workflow. Serverless impacts my organization positively in many ways by enabling us to easily debug issues when any pipelines break; we can get errors, debug them, and address issues. It can support many ways using its unique plugins that we cannot find in other tools, basically working end-to-end for our Serverless projects.

A specific outcome is that Serverless improves the release speed and deployment speed significantly compared to earlier when we used to deploy using Lambda SAM, reducing deployment time and becoming less error-prone, making it very useful.

Serverless can be improved by adding more plugins, as they help to support many integrations and can facilitate integration with other tools, such as monitoring tools like Grafana.

User experience with Serverless could be improved, particularly the UI, which can be a bit tricky; enhancing that UI experience would be very useful for us.

I do not see any needed improvements for Serverless beyond what I mentioned, specifically concerning plugins; everything else seems fine.

I have been using Serverless for around four years.

Serverless is stable and very responsive; it offers many debugging plugins, so overall, it is stable and good.

We have been using this tool for many years, so I think it is very useful for us and also scalable.

The customer support experience has been good; we tried to reach out for some issues and received quick responses, so overall, it is good.

Serverless is the first tool we are using and are still using, and I have not used any different solutions.

We have seen a return on investment, particularly regarding optimal cost optimization, and we need to monitor aspects such as yearly licensing costs. We have been using this framework for a long time but now feel the cost is expensive, so we need to improve in this area.

My experience with pricing, setup cost, and licensing is that I recently feel the licensing is a bit expensive; we need to renew the license, but we are still renewing it. In the future, a lower licensing cost would be very beneficial for us.

I did not evaluate any other options before choosing Serverless.

I find plugins such as VPC plugins most valuable or that my team relies on the most, and for security, we use Lambda's code authentication plugins, such as code sign plugins.

I advise others to use Serverless due to the many supported plugins for cloud infrastructures such as AWS and various integrations, as well as its beneficial debugging capabilities; if you have issues, you can clearly see the debugging logs on the console. The deployment time is very quick, taking hardly two to five minutes for some Lambda functions, and overall, I strongly recommend it to others.

I chose a rating of nine instead of a ten or something lower because some integrations need to be hardcoded manually, and there are no supported plugins for those integrations, such as monitoring tools like Grafana, requiring changes at the code level, indicating that some plugins are still missing.

My main use case for Serverless is based around an application that was an internal application used to track cloud usage across all cloud platforms like AWS, GCP, OCI, and Azure. I used Serverless and Serverless APIs based upon the Serverless Framework, with Node.js and Python Lambda, to support that full backend application.

A specific example of how I use Serverless in that application is that there have been many APIs which provide recommendations for cost analysis or utilization-related details. For each of them, multiple Lambdas were written, and with each Lambda, there were no provisioned compute resources, so each was handled with Lambda jobs through the API gateway.

The best features Serverless offers include that you do not have to envision the whole architecture; you can work with the AWS resources through the codebase. It will still look like the whole backend is a normal application, while it is not being deployed as a single application. It basically interacts with services such as DynamoDB or IAM, depending upon the use cases. That is really valuable.

What I appreciate most about the framework are both the flexibility and the integration with AWS resources. I also appreciate that we do not have to envision any cluster, so Lambda takes care of itself by definition, which is a beneficial feature to have.

Serverless has positively impacted my organization as it has become the de facto standard for any POCs I have been doing, unless something specific is required that demands an on-demand instance. Otherwise, basic POCs and all internal applications have been using Serverless.

A specific outcome related to Serverless's impact is that it saved time because I did not have to delve much into DevOps or pay external tools such as Kubernetes to manage the cluster, and it also reduced costs from the Serverless Framework.

Serverless integrates with my existing tech stack and other tools seamlessly; it works flawlessly and is a service of its own, so it does not really affect anything else.

Serverless can be improved by making it more readable, as the framework still has a different syntax than normal use cases. It can be made easier to use so that people coming from regular backend applications such as Node.js or others can transition to it more smoothly. That is what I felt personally, and that is one way Serverless could improve.

Readability improvement is one area I felt could be enhanced; otherwise, I am satisfied.

I have used Serverless for around four to five years.

Serverless has been stable.

The scalability of Serverless depends on the kind of Lambda being used; it varies based on each of the services, but it has been good, and the configuration defined with the YAML files supports it.

The customer support has been moderate; sometimes there are delays, but overall, it has been fine when I have needed to reach out.

Before Serverless, I used normal backend and frontend full-stack applications. The switch was needed to accommodate certain endpoints or services that had been used excessively while others were utilized less, requiring me to scale the applications differently. Adopting Serverless was the right decision for that.

I have seen a return on investment through the money saved and time saved to quickly adopt Serverless.

My experience with pricing, setup cost, and licensing has been straightforward.

The biggest challenges I have faced while adopting or using Serverless include the different syntax, syntactical understanding, and the steep learning curve with team members. Ensuring everyone has the right access and preventing direct interaction with AWS resources can be tricky if not managed properly, leading to challenges.

For handling monitoring and security for my Serverless applications, I use the ELK stack to push the logs that have been generated. With that, it gets published to Grafana and Kibana, and through that, I utilize monitoring and performance.

For managing version control and deployments for my Serverless applications, I have used Git for version control and GitHub Actions workflows for deployments.

I ensure compliance or governance when using Serverless in my organization by following SOC 2 practices, which includes all necessary security protocols and application-related services.

Serverless has influenced my organization's approach to innovation and digital transformation by allowing access and the ability for all team members to jump in quickly and contribute on an ad hoc basis without needing much infrastructure details. That has been a positive influence.

I have not used Serverless for DevOps, so there is no real impact on that process.

My advice for others looking into using Serverless is to first check what kind of requirements you have that make you consider Serverless: it should really fit your needs. Also, consult the team, as cost and time savings should not be the only metrics. Understanding the use cases and how the features can be applied in the Serverless framework is equally important. I would rate this product a seven overall.

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.

Our main use case for Serverless is to build Serverless APIs, and the complete back-end is built with Serverless. A specific example of an API or back-end workflow built using Serverless is a parts integration related to buying parts catalogs, which is a third-party integration API, and everything was built using Serverless.

Serverless offers the ability to test locally, as it can spin up a bunch of AWS resources and mock them as if they were deployed onto the cloud, allowing development locally without having to spin up the resources into an actual AWS account.

The local testing feature has helped speed up development for my team without having to wait for deployment into the cloud, and for debugging purposes, it has been beneficial to find out when things are not working properly as I can step through the code and see or log local errors.

Serverless has positively impacted my organization as it has been a good experience for the team overall because it is a new framework that we had to learn, and cost-wise, it helps because moving to Serverless means you do not have resources spinning all the time. It only uses Lambdas, and it is infinitely scalable, so you only use resources as the quota is used up or as the Lambda is invoked, with team collaboration being mostly about everyone learning something new together and giving each other tips.

I struggled with wanting to put breakpoints throughout the code and then use the debugger. At the time, I was not able to step through the code with breakpoints, so if Serverless had that support, that would be great.

The overall documentation is great, and I do not have anything else to add about needed improvements.

I have been using Serverless for about a year and a half.

Serverless is very stable.

Our customer support experience has been straightforward as we have not really had to contact them.

Previously, we had a .NET Core back-end deployed onto ECS clusters, but when we switched over to Serverless, there is less DevOps involvement, and we take all the AWS resources we need, while Serverless helps deploy everything.

My experience with pricing, setup cost, and licensing was all very straightforward and very easy to use.

I have seen a return on investment in terms of time saved. To be honest, we were using .NET as our back-end for the most part, but switching over to use Serverless made the development cycle a little bit faster, as we use one-week sprints rather than two with .NET.

Before choosing Serverless, we evaluated other options, including AWS SAM, but it was mostly just between these two options.

Our customer support experience has been straightforward as we have not really had to contact them. I would rate this review an 8.

My main use case for Serverless is deploying my services like API services. A specific example of how I use Serverless for my API services is that I need to create one API where I want to expose my services outside by creating that. For that, I don't have the server to deploy my application. Instead, I just create a YAML file and deploy Serverless application onto my Lambda without any server.

The best features that Serverless offers include being without the server, which itself says we don't need to depend on the server maintenance, and so we don't need to worry about these server things. This aspect has really helped my day-to-day work because we don't need to maintain the server. We have gotten rid of the headache of maintaining the server, server maintenance, memory storage, and where we host that server. All these headaches are gone now just because of Serverless in AWS.

I choose eight out of ten because to go ahead with Serverless, we need to do YAML file creation and other format file creation. So it might not be having the idea. That is the only thing that I observed.

I have been using Serverless for about three to four years.

In my experience, Serverless is stable.

In my experience, Serverless's scalability is very effective, with options for whatever the memory size or whatever the scale that we want, based on the demand. During the peak demand, we can increase the scalability automatically. It can scale during the peak hours, and during the non-peak hours, it downgrades that scalability. This is really helpful.

Whenever we raise an issue to AWS, the customer support response comes within twenty-four to forty-eight hours, as I have heard from my organization.

Previously, we used a server only before switching to Serverless. Before choosing Serverless, we actually ran our application on a JBoss server, and also we hosted some of the applications on a Pyara server as well. From Pyara and JBoss, we migrated to Serverless.

Apart from that, I didn't use any other Serverless solution.

I have definitely seen a return on investment with Serverless. From the developer perspective and coming to the money perspective, we don't need to maintain it. A lot of money could be saved, because creating a server is one thing and maintaining it for a lifetime. Now the lifetime thing, we don't need to take care of. This is really helpful.

My advice to others looking into using Serverless is that you don't need to worry about the server maintenance, the servers, and where you host the servers. All these headaches go away. Definitely it's good to use. All the headaches that we have been doing for all these years can be gotten rid of, definitely.

This has been a great initiative taken by AWS. Previously, we thought that we cannot host our applications without any server, but AWS proves us wrong by creating a Serverless application, the option to deploy our applications without any server. This is a really great initiative done by AWS. I rate this solution an eight out of ten.

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

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

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

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

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

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

Serverless is stable in my experience so far.

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

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

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

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

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

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

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

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

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

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

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