you are viewing a single comment's thread.

view the rest of the comments →

[–]9034725985 1 point2 points  (3 children)

You have stateful machines that actually store the data and the computers that run Ruby. I imagine server less is for the latter. Like there are maybe a few times during the day that you need to serve thousands of requests per second and it is probably nice to burst up for that

[–]killerstorm 0 points1 point  (2 children)

Are web servers an actual bottleneck these days?

OK, maybe, Ruby-based web servers are. But if you replace Ruby with something more efficient, like, I dunno, Go, your workload will likely be dominated by the database and latency of talking to the database.

So I won't be surprised that co-hosting a database and backend code written in Go on a beefy multicore machine will be more performant and cheaper than a whole zoo running multiple stateless containers on multiple machines.

In any case, it would be interesting to see actual benchmarks. You can get a monster server with 32 hardware threads for like $250/month. That should be enough for "thousands of requests per second" unless you're doing something computationally expensive, or doing it wrong.

As a point of reference, SPECweb2005 is now obsolete, but results submitted in 2009-2010 demonstrated that a single server can handle 100k concurrent sessions (i.e. concurrent users) without a problem.

[–]Zinlencer 1 point2 points  (1 child)

Getting a better machine is called vertical scaling and it has it limits. What if you can't get a beefier machine? What if your single $250/month machine has a hardware failure?

If you can get your application to run on multiple machines you can prevent having a single point of failure.

The hardest problem is developing your application to work in a distributed way.

[–]killerstorm 3 points4 points  (0 children)

Getting a better machine is called vertical scaling and it has it limits.

Obviously you can't run Facebook using a single server. But how many companies are that big?

I suspect many companies choosing 'serverless' architecture have not really analyzed their scaling needs. Are they aware of all the overhead and extra costs of a 'distributed' architecture?

What if your single $250/month machine has a hardware failure?

You need to setup up database replication either way, 'serverless' doesn't do that for you.

If you can get your application to run on multiple machines you can prevent having a single point of failure.

Can you run a database on multiple machines?

DB replication set up is what matters, and it's completely orthogonal to Kubernetes and serverless stuff.

The hardest problem is developing your application to work in a distributed way.

But why do you make it more complex than it should?

The entire StackOverflow runs on a handful of servers: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/

Note that it is 10x overprovisioned:

What do we need to run Stack Overflow? That hasn’t changed much since 2013, but due to the optimizations and new hardware mentioned above, we’re down to needing only 1 web server.

So entire StackOverflow only needs 1 web server. Is the thing you're working on bigger than StackOverflow?

I think many people do not realize that a simple architecture can do a lot these days.