MVP on a shoestring: Our Serverless Experiment

Long-Running Processes:  Traditional servers manage long-running processes efficiently. In contrast, long-running APIs in a serverless environment suffered from severe latency issues and cold start delays, making it difficult to develop performant APIs.

Database Connections:  Optimizing database connections and implementing effective caching strategies is more challenging in a serverless environment. The lack of connection pooling affected performance.

Typical, right? There’s a tech that promises a revolution only to deceive in the end. But does it? I want to take a step back and reexamine some of these challenges.

Function-Based Decomposition: Every business domain as a service is microservice architecture, but not necessarily a function-based serverless architecture. I’ve always had a problem with my development team trying to squeeze code into a microservice because it is too small to be its own microservice. I have seen this become a maintenance headache over time. Now, my team is breaking down their code into even smaller units called nanoservices. These are smaller than microservices. This helps keep the codebase more manageable.

Cold Starts: Cold starts are still an issue, with function startup times being a few 100 milliseconds. Every API call is that many milliseconds slow. However, by ensuring functions are lightweight we managed to reduce the latency. It’s common practice to initialize a thousand unnecessary environment variables during startup. Nobody cares as it delays just the server startup and not the API execution time. Well, we cannot do that when we want to be serverless.

Database Connection Management: DB connection pooling does not exist in a serverless world as you would create a connection pool only to destroy it on function shut down. This means connection switching and pooling optimizations are not available to me out of the box. This also means that managing orphan connections and leaks is not my problem. That’s a positive, right? I have been part of painful debugging sessions when the production server runs out of connections due to leaks.

Query Optimization:   DB query optimization is always an afterthought for the development team. Most teams do not care about DB query performance on day one. During the development stages, your application doesn’t have much data, so all your queries appear to work well. Once your software is live for a considerable period, this changes. I have seen teams redesign features/user experience when they realize that the product cannot handle the data demands. At this stage, it becomes super expensive to make the change. With limited computing power and no connection pooling, a developer is forced to think about query optimization from day zero. Some might call it premature optimization, but I call it adherence to coding best practices.

Let me revisit my statement now. Is serverless architecture just a snake oil? Not really. It doesn’t sound that bad to me now. Especially when we were able to reduce our fixed infrastructure costs by 600%. This approach is ideal for products that are still finding their market fit, where minimizing fixed costs is crucial.