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.
Serverless Framework
Serverless, Inc.External reviews
10 reviews
from
and
External reviews are not included in the AWS star rating for the product.
Event-driven platform has handled real-time financial workflows and delivers faster with smaller teams
What is our primary use case?
What is most valuable?
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.
What needs improvement?
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 how long have I used the solution?
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.
How are customer service and support?
I rate customer service a four out of ten.
What other advice do I have?
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.
Auto-scaling has ensured reliable order processing and has reduced costs for unpredictable traffic
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
My team has been using Serverless for the last three to four years.
What other advice do I have?
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.
Serverless architecture has reduced idle resource costs and supports concurrent backend AI workloads
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Serverless for about five years.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
Which solution did I use previously and why did I switch?
I had not used a different solution.
Which other solutions did I evaluate?
I also evaluated making use of EC2.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Event-driven workflows have transformed image processing and now reduce load times effortlessly
What is our primary use case?
My primary use case for Serverless is handling asynchronous data processing and event-driven workflows. I typically use it to trigger background tasks like image processing or data transformation whenever a file is uploaded to S3, which keeps our main application responsive.
In my last role, I used Serverless to address an issue where users were uploading high-resolution images that were slowing down our main site. I set up an S3 trigger that automatically invoked a Lambda function the moment a file hit the bucket, and the function resized the image into three different formats and stored them back to a separate bucket, which reduced our page load time by about 40% and significantly lowered our storage cost.
By offloading that processing to the background, we ensured that the main application remained responsive while the images were handled asynchronously, turning a major performance bottleneck into a seamless, automated workflow for our users.
What is most valuable?
The best features Serverless offers beyond image processing include building event-driven APIs and cron-like automations. For instance, I set up scheduled Lambda functions to handle daily database cleanup and report generation. For me, the biggest advantage is the automatic scaling and the pay-per-execution model, allowing us to handle massive traffic spikes without manual intervention.
During high traffic periods, I found that automatic scaling has helped us immensely. We had a major marketing campaign launch last year that drove a sudden 10x spike in traffic to our platform, and because our backend was built on Serverless functions, the infrastructure scaled out instantly to handle the concurrent requests without me having to provision a single extra server or worry about downtime.
Serverless has positively impacted my organization by shifting our focus from infrastructure management to pure product delivery. By offloading the operational overhead to the cloud provider, my team has been able to cut our time to market for new features by nearly 30%.
What needs improvement?
The biggest area for improvement in Serverless is around cold start latency, especially for applications that aren't constantly active. While providers are making strides, it still forces us to choose between cost efficiency and instant responsiveness, and I would love to see more mature, built-in support for pre-warmed instances or predictive scaling to bridge the gap.
Beyond latency, I believe better observability and debugging tools for distributed Serverless architecture are critical. It is often difficult to trace a single request across multiple functions, so having a more unified, native tooling would significantly reduce the time we spend troubleshooting complex event-driven flows.
For how long have I used the solution?
I have been working with Serverless architecture for about a year and a half.
What do I think about the stability of the solution?
Serverless is incredibly stable for us. We have seen significantly higher uptime compared to our previous setup because the platform handles all the underlying patching and scaling automatically.
What do I think about the scalability of the solution?
Scalability of Serverless is honestly one of the biggest wins for us, as it handles traffic spikes automatically without any manual intervention. We do not have to worry about over-provisioning or under-provisioning. Regarding customer support, it has been very responsive; we have found the documentation and resources to be thorough enough that we rarely run into blockers that we cannot solve quickly.
How are customer service and support?
I would rate customer support around 8 out of 10 because it is consistently quick, the documentation is comprehensive, and all customer support is quite responsive, so there is not much of a blocker.
Which solution did I use previously and why did I switch?
Before moving to Serverless, we were running a monolithic application on standard EC2 instances. We decided to switch because scaling was manual and reactive, which led to significant downtime during traffic spikes and high operational overhead for our engineering team.
How was the initial setup?
We did not purchase Serverless through the AWS Marketplace; we manage our infrastructure directly through AWS accounts using Terraform for our IAC, which gives us better control over environment configuration and deployment pipelines.
What was our ROI?
We definitely saw a strong return on investment after moving to Serverless architecture. By reducing our monthly infrastructure spend by about 30%, we eliminated the idle capacity costs we were previously paying for underutilized EC2 instances.
What's my experience with pricing, setup cost, and licensing?
Regarding pricing, setup cost, and licensing, I find the pricing model quite efficient for us, as we only pay for execution time in a pay-per-use model, eliminating the idle costs we saw with traditional servers. While some investment was needed in defining our Terraform modules and CI/CD pipelines, it significantly reduced our long-term licensing overhead compared to managing proprietary on-premise software.
Which other solutions did I evaluate?
Before choosing Serverless, we evaluated other options and looked into containerizing our monolith with Kubernetes on EKS. While Kubernetes offered great portability, we ultimately decided against it because the operational overhead of managing clusters did not solve our core problem of wanting to focus purely on feature development rather than infrastructure maintenance.
What other advice do I have?
My biggest piece of advice for others looking into using Serverless is to prioritize observability from day one because you lose visibility into the underlying infrastructure, so you need to have robust logging and distributed tracing in place immediately, or debugging becomes a nightmare.
One final point about Serverless is that while it is incredible for scaling, I think it is crucial to be mindful of cold starts and vendor locking early on; if you design your architecture to be modular from the start, you keep your options open as the system grows. I would rate this product an 8 out of 10 overall.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Serverless functions have transformed how we deploy APIs quickly and pay only for actual usage
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Serverless for the past one year.
What do I think about the stability of the solution?
In my experience, Serverless is mostly stable.
What do I think about the scalability of the solution?
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.
How are customer service and support?
For Vercel and Cloudflare, customer support is good.
Which solution did I use previously and why did I switch?
I did not use a different solution. From the start, I was using Serverless only.
How was the initial setup?
My experience with pricing, setup cost, and licensing was good. I did not have any issues with that. It was acceptable with no issues.
What was our ROI?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Automation has simplified API deployment and now reduces time, cost, and team size
What is our primary use case?
The main use case for Serverless is to enable seamless serverless operations. I use Serverless for building an API that serves native IoT devices, which serves as our use case where we use Serverless for seven days. The API I built for the project includes login and registration functionalities, and it automatically changes the user experience accordingly.
What is most valuable?
Without managing a server, we can utilize Serverless in various aspects of our work. Without managing a server, we can automatically deploy and manage AWS Lambda functions, allowing us to complete everything without job-related hassles.
Serverless stands out for easy deployment without any server hassle, and if we need scalability or efficiency, the Serverless framework is mostly cost-efficient because we integrated a Lambda function that charts user request steps, which is why it is cost-efficient. We do not need any high-profile developer for maintaining a server, which is the good thing about Serverless.
Serverless positively impacts my organization by saving time since we do not deal with deployment hassles, and Serverless costs less than other server maintenance options. The positive impact of Serverless is its ability to reduce the number of people needed for project deployment. As a software engineer working on DevOps for project deployment, I find that without Serverless, every project needs multiple workers, but I can handle both development and deployment easily, which reduces hassles for software.
What needs improvement?
I see that the local development setup in Serverless is more complex, so if you provide examples or automation that we can test and deploy locally on a local machine, then automatically shifting all methods or functions into production would significantly improve efficiency.
For how long have I used the solution?
I am using Serverless for about one year.
What do I think about the stability of the solution?
Serverless is stable in my experience.
How are customer service and support?
Serverless has customer support, which I have found helpful.
Which solution did I use previously and why did I switch?
Before Serverless, I used manual deployment methods such as Docker to create container images and deploy them on a VPS server or AWS EC2, but with Serverless, we no longer deal with that hassle, and this led me to choose Serverless.
What was our ROI?
I have seen a return on investment with Serverless. As I mentioned, it saves money, time, and requires fewer people for a project because one person can handle everything, deploying using a single command, with testing and running all managed seamlessly without needing multiple people for various purposes. When a company chooses Serverless, I consider it a great investment.
What other advice do I have?
I did not face any challenges while using Serverless for my login and registration APIs, as we integrated storing user credentials and user information in the AWS relational database, so every coding infrastructure we are deploying works smoothly.
My advice for developers considering using Serverless is that if they face any hassle with deployment, they can easily choose Serverless for automation, coding, and deployment, as well as local setup and project deployment in any server automatically.
Serverless is a great tool for every software engineer, and if any software engineer has not used this tool, they are lacking knowledge and a great opportunity. I tell every software engineer that if they have not used Serverless, it is important for every developer at some point to experience it. I give this review a rating of 9.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Serverless workflows have improved uptime and now support continuous feature delivery
What is our primary use case?
In my previous job and in my current job, I work as a cloud engineer, where I have been working with some clients who have provisioned Serverless architecture for their business, and I provide services to those customers as a cloud engineer.
I can give you a quick specific example of a project where I used Serverless: in my previous company, I worked on a fintech project where the services ran in Fargate, a Serverless service of AWS, deploying a microservices architecture within this Serverless framework. In my current job, I also provide support for a customer whose entire architecture is deployed in Serverless on AWS Cloud, which includes API Gateway, Lambda functions, DocumentDB, and S3 buckets; everything within this architecture is Serverless, and I provide maintenance and daily support for this project in my current job as well.
I mainly worked on these two projects with Serverless, but I know there are other Serverless services in AWS that I have not worked with in a production environment. Thus, I can say these two are the main projects I have been involved in with Serverless architecture.
What is most valuable?
The best feature that Serverless offers is that I do not have to manage any servers because the service providers, like AWS or other cloud providers, take full care of the servers behind the scenes, which means I do not have to manage maintenance, security, scalability, or anything about those servers. I focus my attention on application development rather than spending time on servers.
Serverless has helped me and my team by making our workflow easier and freeing up time for other tasks. If I focus on previous projects, particularly the fintech project, which operates like a Revolut application and is based in Haiti under the name MonCash, I deployed microservices in Fargate that are highly scalable. The application supports features like adding money, sending money, transfers, and bill payments, and I needed to avoid spending time troubleshooting infrastructure because everything was Serverless, making it very easy to manage, highly durable, and secure.
In the previous project, monitoring was done solely on AWS CloudWatch, despite not having access to servers or SSH. Still, I had monitoring capabilities for our services. For example, if a service reached 90% capacity, I could set auto-scaling limits, ensuring costs remained manageable. Integration was handled through AWS Cloud Map, managing the networking of new IPs for our microservices, which is also a Serverless service.
Serverless has positively impacted my organization, particularly through its scalability. Developers can deploy at any time thanks to blue-green deployment available in this architecture, allowing for bug fixes or new features to be pushed into production without any downtime, which has helped not only my organization but also the fintech application MonCash, which has enjoyed uninterrupted service, meeting SLAs consistently.
I can share specific metrics indicating Serverless's positive impact: I achieved 100% uptime, an impressive feat compared to traditional servers that often experience downtime during peak usage. With Serverless, I had 100% uptime SLA, which was excellent for my portfolio and essential for end users.
What needs improvement?
There can be improvements in the AWS architecture of Serverless, particularly regarding features like blue-green deployment, where automation could simplify tasks. If I had easier options for these deployments, such as assigning specific traffic percentages to various versions, it would enhance Serverless architecture usability for both professionals and beginners.
Transitioning from servers to Serverless results in a price increase due to the additional maintenance and patches AWS provides, but if costs could be reduced, more customers would consider moving to Serverless architecture.
For how long have I used the solution?
I have been using Serverless architecture for the last four years.
What do I think about the stability of the solution?
Serverless is very stable and highly scalable; I set limits for invocations, RAM, and CPU usage on Lambda functions, and AWS ensures stability and availability. With five years of experience using Serverless services from AWS, I have encountered no outages or issues.
How are customer service and support?
My experience with AWS support regarding Serverless is mixed; while I appreciate the interaction, I lack deep visibility into the monitoring and logging of Serverless components. When issues arise, I rely on AWS for detailed insights, but the lack of direct access can be limiting.
Which solution did I use previously and why did I switch?
I migrated from using Docker containers on EC2 instances to Serverless due to numerous challenges in DevOps, including complex monitoring setups and the extensive automation needed to scale infrastructure. Serverless simplified my architecture, making it highly available and scalable without managing servers.
How was the initial setup?
Serverless is not available on the AWS Marketplace; it consists of a collection of services already available on the AWS console, allowing me to use any service I need like Lambda for compute, DocumentDB for databases, S3 for file storage, and API Gateway for serverless APIs. There is no single service to purchase, and setup is straightforward, with no licensing required—however, costs remain higher than desired to attract more customers.
What was our ROI?
I have seen a return on investment with Serverless, as moving from servers means requiring fewer cloud engineers and DevOps staff for maintenance, patches, and infrastructure management, resulting in reduced time and effort.
What other advice do I have?
I would rate Serverless an 8 out of 10.
I choose an 8 out of 10 because of the pricing, which should be reduced, even though a higher price makes sense due to the services provided, but AWS pricing is significantly higher than traditional servers. Additionally, access to Serverless offerings must be more accessible for all users to become the first choice for customers.
I advise others to consider Serverless as their first option, as it saves effort and money despite the higher costs, but the reduction in maintenance and deployment costs from traditional servers is significant. My overall review rating for Serverless is 8 out of 10.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Architectures have become more fault tolerant and cost efficient as data workflows run smoothly
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Serverless for three years.
Which solution did I use previously and why did I switch?
I have not previously used a different solution. I have worked on Serverless without getting to use anything else.
What was our ROI?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Hybrid Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Serverless workflows have reduced idle costs and now run event-driven tasks efficiently
What is our primary use case?
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.
How has it helped my organization?
Serverless has positively impacted my organization, and we are seeing a positive response in terms of pricing and scalability.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Serverless for two to three years.
What do I think about the stability of the solution?
Serverless is stable, but it can be improved.
What do I think about the scalability of the solution?
Serverless can scale on demand.
How are customer service and support?
Serverless customer support is good.
Which solution did I use previously and why did I switch?
We have not used any other solution before this.
How was the initial setup?
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.
What was our ROI?
I have seen a return on investment. Money and time are saved, and it is deployed in a public cloud on AWS.
Which other solutions did I evaluate?
We have not evaluated any other option before choosing Serverless.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Serverless functions have powered agile event-driven automation for my smart devices
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Serverless solutions for more than six years.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
showing 1 - 10