Does serverless make sense? Here’s what you need to know

When serverless architecture became all the rage a few years ago, we wondered whether it was just marketing hype. Was serverless really cloud 2.0 that would fundamentally change how apps are built?

In 2025, we have an answer — a resounding yes. Serverless architecture’s popularity has risen over the past 5 years. The below Google Trends graph (which tracks what people search for over a period of time) aligns perfectly with what we are hearing from our clients.

Serverless architecture allows developers to create products without managing the underlying infrastructure.You don’t have to manage servers to run apps, storage systems, or databases at any scale.

While serverless brings immense benefits to businesses, it’s important not to rush into it. Once you go serverless, pivoting back can be very expensive. So here are five questions you should ask before adopting the serverless architecture:

1. Are you doing greenfield development or modernizing an existing app?

Serverless architecture isn’t ideal for lift and shift migrations, i.e., moving your product to the serverless environment without redesigning the app and operations workflow. You have to plan the architecture upfront to avoid complications during migration. Therefore, serverless is a more suitable option for new product development or complete redesign projects where you don’t have to worry about any legacy infrastructure, particularly databases. Legacy databases can’t scale fluidly with your serverless functions, creating a major bottleneck in the scalability of your serverless application. In the AWS world, the go-to options for solving this issue would be DyanamoDB or Aurora Serverless.

Note that greenfield development can also include rebuilding an existing feature extracted from the legacy codebase, in which case serverless works quite well. For example, one of our clients wanted a new reporting function in its monolith ruby-based application. Since it was an isolated feature, we created a separate Lambda function for it on AWS. This allowed the client to experience some benefits of serverless architecture without migrating the entire application.

2. Are you comfortable with higher OpEx for lower CapEx?

A major part of serverless architecture’s appeal is cost savings. As the architecture automatically scales up and down to handle traffic spikes, you don’t have to pay for servers if they aren’t in use. Additionally, direct deployment of applications also reduces infrastructure management costs. For example, you can create a workflow where a new environment is created every time you push a branch to code. This can allow a non-IT team like your marketing team to sign off on the feature and deploy it to production.

Although serverless architecture, like all other types of cloud infrastructure, reduces your capital expenditure, it can sometimes increase operational costs. For example, serverless might get costlier than traditional virtual machines if you have long-running functions, an unexpectedly high volume of calls, or haven’t set resource limits.

Before making the transition expecting a cost reduction, weigh in use cases that might increase your operational expenses.

3. Do you have the right technical expertise?

Serverless reduces the need to manage application infrastructure but still requires specific technical skills to get it right. You might have to either upskill the existing team or hire new talent.

Serverless architecture usually requires expertise in event-driven programming, microservices, and a deep understanding of the enterprise cloud ecosystem. Wrong technical choices can cost you critical resources. Serverless is not just about the Lambda function but involves several other technical choices around redesigning the application in a more distributed fashion, such as the use of event sourcing and asynchronous communication.

Although the cloud provider manages the infrastructure, you must still take measures to maintain a strong security posture. Having the right technical expertise helps shift your security left and go serverless without creating additional vulnerabilities. So, while you no longer have to worry about OS vulnerabilities, it’s still possible to set up less secure apps in AWS Lambda. That’s why thinking about dependencies, code libraries, and AWS configurations is vital.

4. Is vendor lock-in a major concern?

Vendor lock-in refers to the risk of your business being overly dependent on a specific cloud provider. Serverless architecture often involves proprietary APIs or features specific to cloud providers, making switching to an alternative vendor expensive and extremely difficult. So, if your business places high value on vendor agnosticism, serverless might not be the best option.

However, it’s important to remember that vendor dependency is a factor even in traditional virtual machines. For example, switching from a standard AWS cloud instance to Azure is not easy. That’s why, over the past few years, several organizations have realized vendor lock-in isn’t as big a concern as they thought it was. In 2022,47%of respondents said no cloud vendor lock-in is essential to them, down from 56% in 2021. Plus, there’s also been an increase in cloud-agnostic serverless options in the market, such as OpenFaaS, Fission, and OpenWhisk. These solutions are particularly useful for leveraging some of the serverless benefits for on-prem workloads.

Still, before going serverless, understand how comfortable your business is with creating a dependency on a specific cloud vendor. As with all choices we make in selecting a tech stack, avoiding vendor lock-in is a tradeoff, which gives us flexibility at the cost of greater complexity and development costs.

5. What is your expected application workload?

Serverless architecture is ideal for applications that have highly variable workloads. For example, Netflix has its own computing platform — Cosmos, which combines serverless functions with asynchronous workflows. When an app has wide variations in traffic, serverless architecture scales up the resources needed for additional requests and scales them down when the traffic normalizes.

However, if your application has stable high volumes and high memory usage, a dedicated virtual machine might be a more feasible solution than serverless. Therefore, it’s essential to understand the run time of the components of your application infrastructure, plus their memory, disk, and CPU usage, before deciding on going serverless.

Serverless isn’t a silver bullet, but it’s here to stay

Although some companies like Basecamp are leaving the cloud to return to renting their own machines, the cloud is still the most suitable option for most organizations. And serverless is the natural step in cloud evolution.

Moreover, serverless services such as AWS Lambda, Azure Functions, and Google Cloud Functions are constantly evolving, expanding the scope and scale of serverless architecture. So, while serverless won’t solve all your problems, and you certainly need to consider its trade-offs, serverless is on course to become the dominant architecture framework.

Thinking about going serverless? See our AWS expertise and learn how we help teams design and scale the right cloud architecture.