What I've learned by building a fully serverless application

A few years back, while doing my masters in Software Architecture, I challenged myself to create a fully serverless application to be my graduation project.

The idea of that project was to check how a fully serverless application would look, and where it would stand when choosing an architecture for other projects.

For this project, I decided to go with a fairly simple but powerful set of tools: Serverless Framework, NodeJS, MongoDB running on Atlas, API Gateway for the endpoints, and AWS SNS for events. While the app itself centered around evaluating NFL draft prospects, the real learning came from designing and evolving the architecture.

The Good

1 - Faster time to market

With no need to manage infrastructure, you can build, iterate, and ship features faster. In a matter of days, I had a fairly functional MVP.

2 - Cost Efficiency

As this was an academic project, it was so good to see that in the end of the day, I was not spending any money on my infrastructure. But obviously, this is a huge advantage for companies as well, especially early-stage companies that are just building their product without having to worry about how much the bill will come at the end of the day.

3 - High availability

Serverless platforms are designed with fault tolerance and high availability out of the box. Your functions run across multiple availability zones, minimizing the risk of downtime.

4 - Built-in scalability

I didn’t have to think about scaling up or down at any point during the project. Whether there was one request or a thousand, AWS Lambda just handled it. That made the architecture feel robust and production-ready, even for an academic exercise. That's a massive advantage when you're building something with unpredictable or spiky workloads.

The Trade-offs

1 - Cold starts are real

In development, it’s easy to overlook cold starts, but in production, even for a small project, I could notice delays on initial invocations, especially for functions with more dependencies. It taught me to pay more attention to package sizes, lazy loading, and even runtime choices.

*2 - Testing and local development aren't straightforward *

Running everything locally with a full simulation of the cloud stack was difficult. I used tools like serverless-offline, but they only go so far. For testing, I had to think carefully about how I would approach it. At the end of the day, I was only able to have unit tests, as for integration tests, I would have to actually deploy the application, which would have slowed me down and decreased the feedback loop.

3 - Vendor lock-in

Using AWS services so heavily meant I was tightly coupled to that ecosystem. You are always able to move it to another cloud provider if that's something you want to do, but that would obviously require a good amount of rework.

Results

Overall, building this project was one of the most educational experiences I’ve had in terms of hands-on architecture.
It helped me move beyond theory and directly experience the practical pros and cons of serverless in a real-world system.

I could learn that Serverless is incredibly powerful, especially when you need to move fast, stay lean, and scale effortlessly. But as with everything else in software engineering, it has trade-offs.
In many cases, the best results come from combining serverless with other architectural patterns, as in that case, you can get the best of both worlds.