Why I Stay with Serverless in 2024 😎

Starting Out with Serverless

Back in 2017, I took my first steps into the serverless world using the Serverless Framework to deploy stuff on AWS Lambda. It was great for managing cloud resources with code. Initially, I used a bunch of YAML configurations, but honestly, YAML started to wear me out. That's when I stumbled upon Serverless Stack (SST) which, at least until version 2, was all about AWS CDK. Switching to TypeScript for structuring AWS resources? Game changer. It made everything way easier, and SST quickly became my main tool. 🚀

The Real Deal on Costs

There’s a lot of talk about AWS being pricey. Sure, it can be—but it also can be pretty darn cheap if you’re rolling with a serverless setup. Aside from paying for Route 53 for domains, I’m running a ton of side projects practically for free. Each project has its own trio of environments—dev, staging, production. Considering I’m not exactly drawing huge traffic, the cost-effectiveness is pretty sweet. Before serverless, I was dropping 20 bucks a month on Elastic Beanstalk for one webapp with zero traffic. Ouch! Imagine scaling that across all my projects now—I’d be broke! 😂

When discussing databases for serverless architectures, I often refer to DynamoDB. My feelings toward DynamoDB are mixed. On one hand, it's arguably the best fit for serverless environments, surpassing even serverless SQL databases like Neon. Neon’s free tier doesn't meet my needs. On the other hand, DynamoDB's one-table design presents a steep learning curve. It also lacks flexibility if you haven’t clearly defined your access patterns in advance. Ultimately, using DynamoDB involves a trade-off between convenience and adaptability.

Choosing Between Serverless and Servers

Serverless was all the rage in 2017, but it’s cooled off since. Some folks are ditching it for the old school server, saying serverless and microservices can make the system unnecessary complicated. Sure, if you’ve got a simple project, maybe a straightforward server is all you need, especially early on when you’re not sweating over scaling. A lot of projects never hit the point where scaling is a real issue. I think sometimes people overthink the scaling thing way too much. But hey, that’s why tools like Pocketbase are popping up—they keep it simple. 🤷

Keeping It Real with Serverless

Even though I’m chatting up the simplicity of traditional servers, I’m still a serverless guy. Why? Because it often just makes sense. Setting up a single server might be easy and cheap at first, but try juggling multiple environments—things get pricey fast. Serverless can be tricky with stateful stuff like websockets, but it’s not a dealbreaker. ⛓️‍💥

Still on Team Serverless? Absolutely.

Despite any hurdles, I’m still recommending serverless in 2024. Frameworks like SST have really smoothed out the rough edges, making it way more approachable. Running 20+ web apps for free? Couldn’t do that without serverless. It’s a killer way to kick off a project without fussing over servers and costs. 💪

Wrapping Up

Serverless isn’t perfect for every situation, but it’s got a lot to offer for the right projects. It’s about figuring out what your project needs and maybe starting serverless before deciding if you need something more traditional down the line. Flexibility is key in this cloud game, and serverless gives you plenty of that. ✨

original post