I've decided to go Serverless when implementing a search functionality for my personal blog recently [1].<p>Reasons were security (no need to maintain a custom box, install patches etc.) and cost. With the low request volume I expect for this API, Serverless is essentially for free or a few cents. It definitely wouldn't be cheaper for a constant significant load in which case running your own VM will be more cost-efficient.<p>Serverless doesn't necessarily mean you can't use your traditional frameworks. E.g. I'm using JAX-RS (I'm a Java guy) for my search. This app is compiled into a native binary via Quarkus and GraalVM, so it starts up fast enough, also cold starts are no problem.<p>Re vendor lock-in mentioned by other commenters, that's not necessarily true either. My app is portable, I can deploy it to Lambda (via the API Gateway proxy integration) or as a regular app e.g. in a container running everywhere. Also "serverless" doesn't imply Faas (functions); there's container-based serverless like Knative, where you deploy your services as a container bound to some HTTP port. I.e. no lock-in at all, and you still have the benefits of serverless like auto-scaling, A/B testing, per-per-request etc.<p>[1] <a href="https://www.morling.dev/blog/how-i-built-a-serverless-search-for-my-blog/" rel="nofollow">https://www.morling.dev/blog/how-i-built-a-serverless-search...</a>
"serverless" is used to describe a new type of cloud infrastructure you can run your apps (Django, Flask, Express) so that they scale automatically and charge only per request, never for idle, at ~$0.000001 per request.<p>The candid reason developers and Fortune 500s use serverless cloud infrastructure is because they want to build more and manage less.<p>The "Serverless Framework" is a developer tool that helps developers deploy their apps to serverless cloud infrastructure, without having to be an expert in that type of infrastructure. It makes it easy for developers to deploy Django, Flask, Express apps so that they auto-scale and pay only per request, never for idle.<p>Here is how you can deploy Express.js in seconds to serverless infrastructure:<p><a href="https://github.com/serverless-components/express" rel="nofollow">https://github.com/serverless-components/express</a>
If possible, I will always go with cheap servers on digital ocean/linode. Don't buy any cost-saving marketing gig from cloud vendors. Serverless could work for you if your workload is unpredictable. But it makes everything complicated (plus vendor-lock-in). (One more thing, the framework you mentioned can be used with serverless)
In addition to the answers posted already lets clear up what seems to be a bit of confusion in the question.<p>if you google serverless you'll find 2 seperate things.<p>1. a general name and concept for a user only having to worry about the services they deploy at the application layer (without having to worry about setting up servers and such behind it)<p>2. a framework for generalizing how to package up serverless functions.<p>(the name overload is super confusing took me a while when I wanted to setup 1)<p>So you question is comparing apples to oranges.<p>In that you can use serverless framework to deploy Django,Flask,ExpressJS and etc applications to serverless systems i.e. AWS Lambda.<p>for instance I have 2 services I use basically every day that are built on this<p><a href="https://github.com/awslabs/aws-serverless-express" rel="nofollow">https://github.com/awslabs/aws-serverless-express</a><p>so I use serverless framework to deploy nodejs/express applications
==== Advantages of Serverless:<p>- Stability: You're only deploying parts of the backend at a time, which reduces chances of breaking the entire application.<p>- Scaling: You can have parts of your backend scale with use, rather than scaling the entire monolithic backend.<p>- Cost: Serverless is surprisingly cheap these days, compared to hosting a full PHP/Python server.<p>==== Disadvantages of Serverless:<p>- Complexity: Serverless a.k.a "micro services", are basically tiny servers. This adds a bit of complexity, with authentication, latency etc. As it's not a single monolithic server anymore.<p>Many other drawbacks are inherently related to the added complexity.<p>In my experience it's worth trying, but if you're a one-man team then; a monolithic server is much easier/faster to deploy, test, and iterate on.
It would cost less starting out compared to your own server, you may only have to pay per function call. Whereas you would have to pay for server space from the start even if no one is using your product.<p>A framework may be overkill if all you want to do is run a function when something in your database changes. Firebase is a good example of this, you can trigger functions when a document changes.<p>Easy to deploy, reliable and maintainable.