Prospects and challenges of serverless services
Serverless services are currently one of the fastest-growing and most promising cloud technologies. According to surveys, the most commonly used serverless service is functions, with about 90% of users relying on them. Functions are typically used for things like chatbots, backends for IoT apps, video encoding, ML training, file backups, security audits, VM monitoring, image processing, scheduled backups, and sending messages (push, email, SMS).
The popularity of functions has grown so much that some startups are considering building all their project code using serverless functions. They believe this approach would allow the development team to
a) Skip the hassle of setting up and managing cloud infrastructure;
b) Ensure that functions perform well even under heavy loads and traffic, paying only for the time they’re running;
c) Get easy-to-scale and very flexible infrastructure.
But is such an approach the best long-term strategy? And what challenges do teams face as they add more functions?
According to the reports most serverless applications have 10 or fewer functions, and only a few have more than 20.
Imagine you have 20 functions in one environment (e.g., dev), and you must create another environment with the same 20 functions (e.g., testing). It can be time-consuming if you’re just using the admin panel. As the number of functions grows to 50 or more, managing them becomes nearly impossible without using tools like Pulumi, Serverless, Serverless Framework Pro, or custom solutions with infrastructure-as-code tools like Terraform.
Cloud providers offer orchestration services that make it easier to manage complex workflows with serverless functions and handle states. These services connect functions, so the output of one can be used as the input for another.
However, as the number of functions grows, there are some risks:
a) Your project might become dependent on a specific service provider because each cloud service (like AWS Lambda, GCF, Azure Function, etc.) handles functions differently. If you need to switch providers, you might have to rewrite a lot of code;
b) Debugging can be tricky. Example: AWS runs Lambda code in a container where you have no access, so debugging becomes a mental challenge. Unit and integration tests help, but it’s hard to cover everything, especially as the number of functions increases;
c) Costs can spiral out of control. As the number of functions grows, so does the risk of overspending. For example, one function might cost $1500-$2000 per month, and as more functions are added, costs can add up quickly. It might lead to a situation where the cost of serverless services outweighs the benefits;
d) Even though you might want to avoid spending time configuring and maintaining various frameworks, you’ll still need DevOps engineers. But solving issues quickly can be tough because you don’t have access to the serverless infrastructure, which could slow down your project’s progress;
So, when should you use functions, and when are containers a better choice? The answer can help you create a solid strategy and plan.
In our experience, serverless services like AWS Lambda, GCF (Google Cloud Functions), and Azure Functions suit the best for smaller, resource-intensive tasks. Functions weren’t designed for complex workflows, which are better managed with container-based orchestration services, like Kubernetes (K8S) under the hood (AWS Fargate, EC2, GKE Autopilot). In some cases switching from functions to AWS Fargate or GKE Autopilot cuts cloud service costs by half or more.
When you consider combining advanced serverless functions with K8S, we recommend Knative. Knative is a framework that allows you to run serverless functions integrated with Kubernetes. This approach avoids vendor lock-in and helps prevent architectural issues down the road.
How many serverless functions (Lambda/GCF) are you using in your project? What challenges have you faced? What frameworks or solutions do you use to manage serverless functions? Share your thoughts in the comments.
