Submitted 1 day ago by sommerset@thelemmy.club to selfhosted@lemmy.world
https://viduli.io/blog/serverless-is-a-handicap
I’m sure ‘serverless’ has a good time and place to be used, but in my experience it has just always the worse choice.
“But we need to be able to scale!”
Sure, but we’re not in a place where we’re getting anywhere near early mySpace / Facebook / Google style growth. Just get a regular ass cheap VPS and stick your service on it; if you need to expand upgrade the VPS. If it’s starts getting serious then let’s look at compartmentalizing and distributing it if we need to.
Premature optimization is billed as a feature nowadays.
It really is such a cool concept. The autism in me hates the name though because there’s always a server. I wish it were called a “container-based service” or even just “containers” instead of serverless to be more direct.
There’s so much big talk about scale but really, scaling is not that important to 99% of businesses I’ve worked at. You’re not a startup. Your typical server has a huge amount of resources if managed appropriately. I guarantee and would bet money that you’ll never have a million users let alone a billion using your medical coding web app. Like, sit down!
Problem is containers mean OCI/Docker containers for most people, which distinctly are little OSs (the kernel is shared), where serverless creates a common OS stack and application framework as well.
Absolutely. People really sleep on just how much traffic a simple low end server running a PHP framework can handle. I’ve ran systems with a million users (combined across multiple domains and clients but still) and it was just fine with a single database server and a few web servers. They would have needed to hit the tens of millions of users before serious refactoring or rewriting would have ever been necessary to consider.
If you build for a containerised environment, standing up your service in Kubernetes with HPA gives you all the scalability (and potentially cost) benefits of serverless without all the drawbacks.
I don’t know about you, but I really, really, really don’t care if a website wants to make its articles look more appealing by throwing in some animates.
Are you saying that it isn’t a picture of the cloud (or of an IA barrister in a British court)?
Did we culturally forget that digital art and photoshopping exist for a minute?
WTF?
What does this have to do with self-hosting?
So people know what not to do for selfhosting. Don’t self host in lambdas people.
Tbh it speaks volumes that none of the hundreds of containers I run - none of them had this in the instructions “you should use serverless”.
Who is self-hosting in lambdas? Isn’t the idea of self-hosting to control your infrastructure (preferably including the hardware) ?
Containers kinda are the opposite of serverless, not surprising they don’t have that in their instructions.
A poor architect blames their tools. Serverless is an option among many, and it’s good for occasional atomic workloads. And, like many hot new things, it’s built with huge customers in mind and sold to everyone else who wants to be the next huge customer. It’s the architect’s job to determine whether functions are fit for their purposes. Also,
Here’s the fundamental problem with serverless: it forces you into a request-response model that most real applications outgrew years ago.
IDK what they consider a “real” application but plenty of software still operates this way and it works just fine. If you need a lot of background work, or low latency responses, or scheduled tasks or whatever then use something else that suits your needs, it doesn’t all have to be functions all the time.
And if you have a higher-up that got stars in their eyes and mandated a switch to serverless, you have my pity. But if you run a dairy and you switch from cows to horses, don’t blame the horses when you can’t get milk.
It's a dystopian government's dream.
What wasnt conveniently covered is what happens when your container goes down and how to architect recovery. Your simple flow diagram is no longer simple.
When building an application, consider all options. Serverless is great for background tasks that can be broken up into smaller pieces that you would otherwise need to scale up for main instances to handle, or scale up/down additional instances. It’s great for running background reports that you do t want to build a bunch of routes for.
I would never choose serverless for the whole app architecture, but I might choose one host over another of the distinguishing feature was serverless. It’s really nice to have the option.
eleijeep@piefed.social 22 hours ago
This is just an ad for “Viduli, The AI-native cloud platform”
The discussion itself is off-topic for this community anyway. Who would even think about using “serverless” for self-hosting?
fruitycoder@sh.itjust.works 20 hours ago
I use serverless via knative in my homelab…
EncryptKeeper@lemmy.world 18 hours ago
Why wouldn’t serverless technologies be relevant to the self hosted community?
Goodeye8@piefed.social 13 hours ago
The discussion is off topic for the same reason web development software patterns or the benefits of choosing one language over another aren’t really relevant to the selfhosting community. Because most self-hosters don’t develop the software they host, they set up existing software. Serverless technology itself might be relevant, if there was a project using that, but how the architectural decision impacts software development is not really relevant to self-hosters.
RedirectedPotato@lemmy.world 16 hours ago
I can’t think of a single open source / self hostable app that needed, or even had an option to deploy as a function. I have seen FaaS projects though, but they deploy to docker.