Pros and Cons of building "serverlessly"

As a self-taught developer for the purpose of building my own web apps, the whole concept of serverless has been a godsend and probably the reason why I dared take the jump to get out of the noob-friendly Wordpress ecosystem and now developing my own MVPs and products with much more freedom.

The reason is because I've had HUGE nightmares with managing my own servers (on Linode) and the plethora of configurations, threats, maintenance, and costs to worry about. I guess "managed hosting" was an option, but even that has a lot of pitfalls and the costs are not negligible.

So I've been working in the Firebase ecosystem and I absolutely love it. So far using Firestore for the DB, Cloud Functions for some logic, and Cloud Scheduler for the odd cron job . Hosting is done on Netlify. So far it's all free and I've modeled it so that the site would have to get super popular to even have to pay a penny. Analytics, performance monitoring, authentication can all be added in literal minutes. There's so much more available in the ecosystem and constantly being worked on by super bright minds and you as a user don't have to worry about any of it and can plug-in to different services when/if the time comes if you wish.

Sure there's vendor lock-in, things could get expensive at scale, and you're at the mercy of these company's whims...but for indie hackers these should be really far down your list of concerns.

I personally think it's the future, if not the present, and while its cumbersome to develop for certain types of apps (currently) for others I think it's a no brainer, especially for the indie hackers out there who aren't backend wizards. I see 3 tiers of development: no-code devs, serverless devs, and monolithic devs - and I really like the middleground that serverless offers.

I'm not a huge fan of bootstrapping up starting with server less. Its always been my experience that the best use cases for server less / micro service architecture show up when you begin having difficulty scaling one aspect of your design. In general, this is usually a good problem to have.

At early stage, I prefer to be able to share code throughout my architecture and keep my time available for rapid feature development if needed. If something needs to get broken out into a micro service - Great! That means people are using the product.

You said "I basically don't have to worry about uptime. Even if something does go down, there's nothing for me to do except wait for Amazon to get it back up." - but it's important to note that you can still be the reason you are down when using server less (bad db migration, poor deployment, failing logic, etc).

The biggest con for serverless is state. If you can model everything as stateless event-driven functions it will work well. If you're building something very stateful it's going to be a bad fit. There's a couple projects out there that are looking to pull out a lot of common code that microservices and / or serverless functions need : https://cloudstate.io/ and https://dapr.io/

I've started to use Netlify functions for our live streaming app and haven't noticed any performance related issues. I'm beyond ecstatic about the time-to-deploy that comes with using Netlify compared to us managing our own deployments with Django.

With that being said, I've not had any experience with large functions or running them at scale yet as we only have a few users.

As I mentioned, the biggest upside is how simple to setup, develop, and deploy our API is now.

While it may be cheap early on, it can be extremely slow to startup your functions. To the point of degrading the customer experience. The biggest risk, in my opinion, is the underlying mindset of pre-optimizing for scale. So many startups I’ve worked with have fallen into that trap.

GCP serverless (Cloud Run) specifically is very good for running your apps. It lets you run any docker container. Very easy to work with and deploy. I have my product running on Cloud Run + manager MySQL on GCP and it's been great. Previously I ran on my own VM on GCP, it worked well but I did not want to worry about server going down and dealing with SSL certificates. I haven't tried serverless stack on AWS thus can't really compare.

My suggestion, use what you know. You can spend way too much time trying to figure out how to use a certain stack. Also, think if you really need all these technologies such as DynamoDB that have very specific use cases. Why not use RDS instead of DynamoDB? It makes you application much easier to run locally for testing also and can move between cloud providers if needed later.

A couple of thoughts. First of all, what do you think of mostly managed solutions like Render? They're definitely more expensive than Digital Ocean or Linode, but they're probably cheaper than whatever "serverless" stack you've got (free for static sites, too!). They'd let you develop your Rails app or whatever locally and then deploy it to them and keep a simple architecture (with the important bits in version control rather than in AWS config panels).

Secondly, I recently interviewed Derrick Reimer and he talked a bit about his new startup, StaticKit, which is basically aimed at creating a dev-friendly experience for people with static/serverless sites. You might find some useful things there...