Serverless Framework

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

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

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

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

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

Serverless is stable.

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

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

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

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

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

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

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

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 that I mainly worked on Node.js serverless applications for my platforms, and I have worked with different domains, spanning three or four domains with Serverless.

A specific example of how I used Serverless in one of those domains is that I mainly worked with AWS infrastructure using the AWS stack, including S3, AWS Auth, and Cognito. I use several AWS services with Serverless and Node.js.

Serverless helps me with data processing in AWS by making infrastructure deployment very easy. With a single click, it automates everything when I am working inside AWS infrastructure. The development is also very fast and easy to implement, and it is not a complex architecture compared to Spring Boot, MVC, or other infrastructures.

The best features Serverless offers for me include automated deployments, which are very smooth and interesting. As a full-stack engineer, Serverless really helps me to reduce my DevOps cost. Another valuable feature is the offline mechanism, and I have used AWS LocalStack with Serverless Offline, which is really interesting and helps me to simulate cloud infrastructure without any cost on my machine.

Automated deployments and the offline mechanism impact my workflow positively because when I configure the Serverless application in the serverless.yml file, I can configure everything, such as AWS services I have used in my application, including S3 configuration, Cognito configurations, and database configuration as separate YAML files integrated into one Serverless file. Then I just click on the NPM deploy, develop, or any staging option, and it automatically deploys to my AWS CloudFormation stack, creating the entire service.

Serverless positively impacts my organization by allowing us to work as a startup with very limited resources and costs. When we go with a Serverless infrastructure, we reduce the need for specialized resources, especially on the DevOps side, because everything becomes automated, enabling our full-stack engineers to perform that work. Reducing resources means we reduce cost as well, and it is time-saving since deployment does not take hours but rather depends on our network speed.

Serverless helps with scaling my applications as the organization grows by not restricting the inclusion of more components or modules in the Serverless applications. However, there can be some restrictions. For example, AWS S3 only supports a maximum file upload of 250 MB using Serverless. Despite a few concerns, from a Serverless point of view, integration and implementation of our logic into applications remain very easy.

Serverless has many advantages, and it is very easy to handle with a cloud solution. However, there are a few concerns about the limitations. Especially when I work with Lambdas, there are maximum Lambda timeouts. Likewise, there are several things from Serverless, such as maximum file uploads.

Serverless can be improved by addressing the challenges faced when we have the first infrastructure. Sometimes it is hard because we need to manually create things such as Cognito pools. While 90 percent of the time is automated, more automation would be better. If Serverless provided CI/CD capabilities, that would also be great, as currently it only allows for manual deployments. Additionally, when working with cloud services, Serverless allows the use of LocalStack or Serverless Dev, but I think Serverless Dev might need simplification for easy access without organization registration.

When considering needed improvements, I get frustrated with Lambda time and similar issues, which are actually not related to Serverless but rather are AWS issues. However, when discussing Serverless, the main points I see require improvement from the Serverless end.

I have been using Serverless for almost close to two years.

Serverless is stable. With the arrival of Serverless v4, I observe it has good features and improvements over the past few years, hence it appears stable for specific domains and applications.

Serverless helps with scaling my applications as the organization grows by not restricting the inclusion of more components or modules in Serverless applications. However, there can be some restrictions. For example, AWS S3 only supports a maximum file upload of 250 MB using Serverless. Despite a few concerns, from a Serverless point of view, integration and implementation of our logic into applications remain very easy.

I have used several solution frameworks previously, including Java Spring Boot and NestJS with EC2, among others. The decision to switch to Serverless is based on the project or company requirements. If I was working in a very large enterprise application, I would choose Java over Serverless. However, for this startup, we determined that Serverless was the most suitable framework, and I am open to switching frameworks in the future as per the architecture needs of the application.

In terms of time or cost saved compared to before using Serverless, I save approximately 60 percent of my development time because everything is very lightweight and gives me the freedom to work within Serverless. Similarly, regarding cost, when I reduce time, I should automatically reduce cost as well. About deployment, we handle deployment more than 80 percent faster, so we do not need to have a specialized DevOps engineer as my full-stack skills cover it.

Regarding pricing, setup cost, and licensing experience, I find the application to be very cost-effective. The headcount needed is much lower compared to supporting services in software development, particularly in DevOps or technical writing roles. Overall, it is lightweight and should be cost-effective compared to other frameworks, which is why we choose Serverless for its suitability in small applications that need to be lightweight and quickly delivered.

Before choosing Serverless, I considered other solutions such as Express with AppRunners, but I found that version to be time-consuming compared to traditional Serverless with more manual interference, especially regarding deployment and DevOps. I also checked Spring Boot, but it did not match our application needs, focusing instead on AppRunners with Express as a viable alternative.

Serverless affects my team's productivity and collaboration by presenting some challenges. For instance, when we work in parallel, deploying two different versions at the same time can lead to issues or conflicts, where resources may not be generated successfully. However, these challenges are manageable since we typically avoid deploying two versions at the same time in actual production development.

Serverless handles monitoring and troubleshooting effectively by integrating with CloudWatch, allowing for easier understanding of logs. Serverless also possesses extensive documentation and references, making it easy to resolve any issues related to its functionality, although logic issues might require different handling.

My advice to others looking into using Serverless is that you need to understand your requirements and ensure Serverless aligns with your solutions. It depends on your application, the cloud solution being utilized, and the services required. Throughout my experience with Lambda, I always tie it back to that. While it works for me, others might have different needs or infrastructures, hence it is crucial to have an open mindset and determine what framework truly suits you rather than sticking to one blindly, as that could lead to frustrations. I would rate my overall experience with Serverless as a seven out of ten.