Serverless or Server?

I'm of the belief that you can optimize almost any serverless problem to be significantly cheaper or better as a server-first solution, with some notable exceptions (ETL, video transcoding might be the best examples of things that truly balloon up and down in resource consumption).

However, there's administrative overhead of running servers, and more complexity in prematurely optimizing things.

If you like serverless, use it until you run into problems you can't solve. Vercel monorepos are pretty awesome as far as serverless goes.

What is probably more optimal, unless you have significant experience running servers, is to start serverless and refactor when you see things scaling, and can make sense of what's happening. You will probably find scaling issues that can easily be solved through some kind of caching or database change, or a small code refactor.

Your goal is to delay refactoring as long as humanly possible.

This might not work if you don't have significant experience with a server-first approach. Generally for small projects, it's not worth it to over-engineer or over-optimize things.

We use both. Serverless is great for heavy parallelization as well as for applications that need to scale for traffic spikes, etc. Also, we quite often use AWS Lambda together with API Gatewat and Cognito for implementing RESTful APIs, since the services integrate seamlessly. Whever we can predict our traffic accurately AND we are facing constant traffic, we go for long running servers or containers, especially when there isn't a need for quick scaling operations.

By the end of the day, you can perfectly use Serverless for some parts of your application and Servers or Containers for other, depending on your needs. If you'd like to reduce your Ops overhead after all, you can also chose solutions such as ECS Fargate over running your own instance.

We should not forget that most costs are produced while working on engineering tasks such as implementations or maintenance - try to reduce that overhead whenever you can.

I would say that for a proof of concept, it doesn't at all. Just ship something.
Users won't care if it's serveless, server, or whatever, so for a POC, just ship something as soon as you can.
No need to waste time. And because you are expert in running in server, go for it. Don't loose time to learn how to use and optimize serverless

I've talked myself down on serverless for a few personal projects. The main reason was predictability of costs. With serverless, unpredictable traffic spikes (maybe you make it to the front page on X, or even a malicious actor) could hammer your website/api and cost you a lot of money. Build your application in a scalable language, and a single server could go a long ways.

There's also packages for many languages to transform http handlers (for traditional web applications) into serverless-compatible functions. I don't think that switch is actually that disruptive. Serverless seems like a safer bet once a project reaches profitability/maturity.

Personally, everything new I build now I look at serverless first. I find people greatly underestimate the costs (distractions/time wasted) of running/maintaining your own server instead of focusing on building a production / service.

If costs might be an issue (because serverless is more expensive per call), I make sure the architecture could be switched to a Docker container. So, if needed it would be possible to switch back to a more traditional architecture if needed.

i do love serverless.
you can try Cloudflare Worker

I go with PaaS initially. I don't plan that any of my projects are going to take off and just cost a ton of money. So I'll go with Vercel, or Heroku, or whatever. May check out DO's new PaaS.

If I start to get any kind of traction it's not hard to switch to a server.

I move to serverless lately, mostly due to the fact of how little it takes to create a new function.

My product consists of 5-10 "micro" web services, most of them built with asp.net Web API. If I accidentally need a new web service, creating a new one produces too much hassle: from project to packages, to DI setup and etc.

Same time cloud functions can be created by simply writing code in a web window (which I almost never do though), or by adding one file to a functions project.

I'm so impressed with serverless that I plan to incorporate it into my latest product api.chat in some form.

I'm not sure that it should be used for backbone of application, here I really would like to have more control, but for a side services it's the best IMO

With server.

The reason for this is that you are more comfortable with it. Also, if your project is new I am guessing you wont have issue with highly variable traffic like the problem solved with serverless. I am sure there are advantages with serverless here, but it is more important to concentrate on the features of the project (product) :)

Later on, if you have crazy traffic and you think serverless can solve the problem you are facing, then go to serverless. This is a very subjective opinion.

I like doing everything serverless because of two key reasons:

1. Less to think about

• There's no maintenance, upgrades, downtime, or securing of serverless functions. I can just deploy my code and expect everything to run. If it doesn't, it's my fault, and not an issue with server configuration or server lifetime artefacts.

2. More decoupling

• Doing everything serverless forces me to think about the code and architecture in a more modularized way because every function is, essentially, a small server doing Just One Thing™

With platforms such as Vercel, you get edge-to-edge caching as well. That means your application is no longer that dependent on location – at least for the end-user. They’ll get near-instant responses, as if the server was placed in their country.

Serverless is the way to go.

I've used the Serverless Framework on many projects and find it easy to understand and extremely flexible with its plugin model. The Serverless Framework provides a simple and effective abstraction of the AWS Lambda package and deploy process. GoDaddy has found that by providing developers with self-service, standardized infrastructure templates, they are able to get new projects running faster with less overhead.

I think both options are good and have their own benefits. First of all, if I discuss the pros of server ones then they are the following:

• Owned servers make data security invulnerable compared to the serverless options.
• Data sensitive apps like banking and government etc should reply on server platforms.
• A physical server gives you unlimited access to your operations and setups.

On the contrary, serverless options are the best if you have a limited budget and less time to develop an app. With cloud features, your project wouldn't go down anytime. Serverless frameworks like Parse https://www.back4app.com/product/what-is-parse-server with low coding developing offer many services like REST API tools, social logins, Cron Jobs and much more. In short, it depends on your requirements that what suits you the most.

This article https://www.stonegroup.co.uk/insights/server-vs-serverless-whats-the-best-option/ can also assist you in finding more pros and cons of both server and serverless platforms.