Serverless Framework

We primarily run jobs on Serverless, specifically on AWS Lambda, using short-running jobs triggered by events. We can connect to an API Gateway for various purposes. For instance, if a client wants to process data and the data volume is not large, we decide to run that job on Serverless using AWS Lambda. In my previous role, we used it to build four backends because we expected API requests to be completed in microseconds. This represents a full range of applications.

Serverless's best features are quite impressive. You don't have to provision anything and it comes with a self-contained environment. The time limit is also beneficial because it forces you to work within certain constraints to build fast applications.

With a self-contained environment, you build things for specific purposes. You build technology to support what you currently have. The time limit depends on your needs. Sometimes you build something and later realize it's going to take more than 15 minutes, and at that point, you can move it to a container or a long EKS job. However, with the self-contained environment, it helps that you already know you have your language and it comes with some dependencies already installed, so you don't need to have a Docker container. Even with that, you can still have a CI/CD workflow and build with packages that are not pre-provisioned with the container itself. This is the Lambda container, and then you have them in there. The process is quite seamless.

Serverless has positively impacted my organization. In my previous company, it helped them save a lot. In my current company, we use the technology to achieve what the job needs. This helps us know that we save money because not every job demands you run a long-running job or have a container, as instances are expensive. With Serverless, it's on-demand, so you only use and pay for what you've used, which is very beneficial.

I think we are moving in the right direction because AWS recently announced something regarding VMs and Lambda VMs for long-running Lambdas. There are also SnapStart and a few other things available. Cold starts are generally getting better, and even for some jobs, cold starts aren't really a significant issue. In its current state, I don't know what Serverless can do better because I think it's already excellent at what it's supposed to do.

I've been using Serverless since late 2020, so approximately six years, give or take.

Serverless is stable.

Serverless scales to the point that if you're not careful, you may pay for more than what you're expecting because Serverless is extremely scalable.

AWS provides the customer service.

It wasn't a switch. It was just using a particular technology for a particular job. We still run multiple workloads, some on instances and some serverless, some on servers, and various other configurations.

It's pretty accurate and reliable most of the time regarding Serverless's AI capabilities. We use it currently to read data off bank statements and then try to determine what kind of transactions were made, whether it was an income or a payment or something else. It's pretty accurate most of the time, around 80 percent.

An implementation team was involved.

The experience with pricing, setup cost, and licensing was pretty straightforward and smooth. AWS has a number of in-built Serverless options, so you didn't really need to go to the marketplace. They are open with the cost upfront.

Serverless was the right option for us at that point.

I would give Serverless a rating of 9 out of 10. I think it's solid.

For what Serverless promises, I think it delivers on all fronts.

Regarding Serverless's AI capabilities, I think it operates the same way. We just need to be careful once you limit the access you give to your agents and the models, and even to the users themselves. It still boils down to the same principles of least privilege and what you give access to what the job is supposed to do. If you over-give the access, it will do something it's not supposed to do, and that's on you.

People should use the right tool for the right job. If Serverless doesn't work for them, they shouldn't use Serverless. If it works for them, they should go ahead because it's very beneficial.

The main use cases for Serverless are those products or project ideas in which we don't want running servers. For that, we have different frameworks available, such as Netlify, Cloudflare, and AWS serverless architecture. I am using that.

I have made a project for personal learning that was an MCP monitor in which I built observability that captures the logs provided by the MCP server and shows it on the platform itself. As we clearly know, it requires basic CRUD operations, as there is no need for running servers. Logs happen and are just sent into the server, such as normal edge functions, which is why I built this project in Serverless using Cloudflare functions.

Initially when I was working at a previous company, we were using a server with MongoDB and AWS EC2 instances, but the problem was that without any customers, they were paying huge charges for a medium-level server. After realizing that the product could be transitioned to Serverless architecture, they moved to Serverless and started using AWS Lambdas, leading to significantly lower costs. That transition allowed them to ship multiple features without worrying about costs. Initially, with a server costing without any initial customer base, after moving to Serverless, they shipped multiple features, started very early, and were able to deliver many things without the cost headache.

The best feature that Serverless provides is the pay-per-use model in which you only pay for what you have consumed. In short, if you haven't consumed anything, there are no charges. That is the best thing that I have found within Serverless architecture. It is very straightforward to begin, with different services such as Cloudflare, Netlify, and various others providing this functionality, which is very useful and efficient. The first thing I appreciate is the pay-per-use model. The second is that it's easier to begin, and the third is that we have plenty of resources available to get started with this.

If we talk about this project itself in relation to the pay-per-use model, it shows that you don't get charged for the initial setup. Most projects are built in the form of an MVP and later get converted into paid products as soon as users or customers get onboarded. With a server, we need to take a particular virtual machine, set up, and run the server, which is very costly and not cost-friendly. However, with Serverless, the cost depends entirely on how many function calls are happening, so the cost is zero in the initial phase. That is why it makes developers or product managers get started with any idea very seamlessly without the headache of cost.

The only improvement I want in Serverless is to address the cold start issues that exist, which is an obvious concern, but I would appreciate seeing improvements in this area.

I have been using Serverless for more than two and a half years.

Serverless is completely stable and performs very consistently.

Serverless is scalable, and the services connected to it generally have autoscaling. The container concept exists in Serverless, especially in AWS and GCP, where different containers execute functions. We can increase memory and timeout, and it autoscales itself depending on the cloud provider. They create different containers, with up to a thousand containers able to exist simultaneously, and each container can handle multiple invocations of any function.

I have not needed customer support for Serverless solutions I have used.

Initially when I was working at a previous company, we were using a server with MongoDB and AWS EC2 instances, but the problem was that without any customers, they were paying huge charges for a medium-level server. After realizing that the product could be transitioned to Serverless architecture, they moved to Serverless and started using AWS Lambdas, leading to significantly lower costs. That transition allowed them to ship multiple features without worrying about costs. Initially, with a server costing without any initial customer base, after moving to Serverless, they shipped multiple features, started very early, and were able to deliver many things without the cost headache.

I did not evaluate other options after moving to servers and instead moved to Cloudflare for Serverless, which offers a good number of functions and free tiers that make project building very straightforward.

Based on my experience with pricing, setup cost, and licensing, the offering is good.

I did not evaluate other options after moving to servers and instead moved to Cloudflare for Serverless, which offers a good number of functions and free tiers that make project building very straightforward.

The best feature that Serverless provides is the pay-per-use model in which you only pay for what you have consumed. In short, if you haven't consumed anything, there are no charges. That is the best thing that I have found within Serverless architecture. It is very straightforward to begin, with different services such as Cloudflare, Netlify, and various others providing this functionality, which is very useful and efficient. The first thing I appreciate is the pay-per-use model. The second is that it's easier to begin, and the third is that we have plenty of resources available to get started with this.

The only improvement I want in Serverless is to address the cold start issues that exist, which is an obvious concern, but I would appreciate seeing improvements in this area. I would rate this solution an eight out of ten.

My main use cases for Serverless include automation or chatbot implementations and real-time media processing.

A specific example of how I used Serverless for automation or media processing is a project in which we had to gather all the emails regarding our users that subscribed to our product. We get those emails from a third party and add them into our marketing system to use that for daily marketing, making a funnel for different scenarios in our product according to different people that subscribed based on our plan.

Serverless offers easy scalability whenever I want it, with no problem when there are many requests. I really appreciate that there is mostly no management of the servers that I have to do and that it is basically available all the time. Automatic scaling is another key feature that I really value as it helps manage resources whenever my project or audience grows over time.

Automatic scaling and always-on availability have helped me in my day-to-day work and on specific projects because without Serverless, I would not have been able to handle everything on my own. With Serverless, since I have to do no server management and do not need a specific person for DevOps, it becomes easy for me to focus my energy on the high-end tasks that I really want to do. Regarding automatic scaling, it really helps the resources to scale up or down instantly based on incoming traffic, and it also addresses our budget constraints since we do not have to buy a large server initially, but rather it helps extend the time.

Serverless has positively impacted my organization concerning constraints, as we teach everyone about DevOps and how it will scale. Now we need fewer people to perform the types of tasks that Serverless could easily manage and execute, allowing us to take advantage and do the work we have to do in our specific spaces and focus on high-impact tasks rather than working on things that would not be as impactful.

In my opinion, Serverless could improve its performance regarding the major drawbacks when functions are idle, as it takes a bit of time to start over and begin a new container. This delay could really help performance. Another consideration is cost since if your team does not have experience with the financial implications of DevOps, the high volume could end up being more expensive compared to buying a dedicated server. I also feel vendor lock-in is an issue that is not very large but can become a problem if teams become overly reliant on one cloud service, making migration more difficult in the future. If this aspect could be managed properly, it would be great.

Regarding the needed improvements related to developer experience, debugging, or monitoring, it is easy to start things out, but tracing errors across distributed third-party functions can be challenging without special tools. Cold starts, unexpected costs, vendor lock-in, and debugging difficulties are major issues that we have to address.

Other improvements needed for Serverless include performance enhancements across various cloud server providers. Every Serverless company has its benefits, pros, and cons. Some may not scale well with AI and GPU integration right now, while others, such as Cloudflare, perform exceptionally well. It really depends on what you want to achieve, and there are numerous Serverless providers you can utilize to meet specific use cases.

I have been working in my current field for almost six years.

Serverless is stable in my experience.

Serverless's scalability is really easy for me.

Customer support does not tend to help quickly, typically taking three to four hours in my experience.

I previously used containers and virtual private servers (VPS), which I still have, when we were building demo products and small or medium persistent applications. When things became complex, involving more microservices, I would use Kubernetes, depending on the service or the specifics of what we wanted to create.

Regarding return on investment, I think AWS offers numerous resources when we need to start a new product, which has greatly assisted us.

There is nothing to consider regarding pricing, setup costs, or licensing as you do not need traditional software licenses or computing engines with Serverless; you simply pay as you go.

Before choosing Serverless, I evaluated other options, and it really depends on the project I am working on because their constraints vary. If the constraints require a product that can scale easily and uncertainty about potential breakdowns exists, I would lean toward Serverless. However, if the project had different constraints, I would consider other options, as it all comes down to use cases and budget.

I rate Serverless an eight out of ten.

I give it an eight because it is working for me, and I am fully invested in it. I use it directly every day and have not encountered many difficult tasks that I need to manage, either directly or indirectly.

Regarding Serverless's AI capabilities, I think there would obviously be automated guardrails, and if we talk about AWS, they monitor runtime, identity access, and prompt injection strictly. They really provide good Serverless capabilities while acknowledging there are security risks and controls.

I consider Serverless reliable concerning accuracy and output for my specific needs, as I did not see any issues with the services I am utilizing. However, I faced some issues with vendor lock-in since all of our infrastructure was managed in one account. When that account was temporarily blocked for an unjustified reason on their side, it became an issue for our whole project and caused significant costs and loss of users because of that single incident.

My advice for others looking into using Serverless is that you should not use Serverless if you do not understand its constraints, such as cost and scalability with respect to cold starts and vendor lock-in. If you are completely new, you should first learn about your use case and then proceed carefully. My overall rating for Serverless is 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.