As a software architect, I hate serverless. Not because it doesn't work, but because it forces design constraints that cripple your application. Here's why always-on servers matter.
I’m sure ‘serverless’ has a good time and place to be used, but in my experience it has just always been 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.
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.
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. Perhaps even “web functions.”
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.
I’m sure ‘serverless’ has a good time and place to be used, but in my experience it has just always been 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.
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.
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. Perhaps even “web functions.”
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.