Serverless Providers and Effective Architectures
seve.blog
seve.blog
Given a Git-push-and-you're-done PaaS-style hosting provider (Render is my fav at the moment) that can easily scale from one tiny VM to…well, whatever you're willing to pay for…tell me again why I need to throw away decades of acquired monolith knowledge to architect my application as serverless?
Monoliths and serverless are not exclusive. Serverless applications can and should be built as monoliths and should be able to run as a monolith e.g. via a container. Any platform that prevents you from doing this is part of the 90% bad group.
Your knowledge probably mostly carries over. Stateless application architectures were around before serverless, Serverless just enforces most of the patterns. For example, Rails promotes a monolithic pattern that scales horizontally thanks to the stateless application principle of maintaining state inside the database (or separated data store) and only having ephemeral state on the server. This wasn't always obvious. But nowadays we know not to store images directly on the server's hard drive.
Rails couldn't have anticipated the computation or memory constraints of serverless, which is why it's incompatible. Serverless is basically just stateless application design within a cpu and memory constrained system.
So you or I might get excited about streamlined container deployments (does Fly.io count in this world I wonder), but that's not people are talking about when they write their DEV.to tutorials on "serverless". =)