Live data from Hacker News

Surprising Scalability of Multitenancy

brooker.co.za

31–40 of 40 posts

Re: Surprising Scalability of Multitenancy

#31
post #5

I'd seen a more useful paper on this subject, on how to organize your game servers for a big MMO. The most economical strategy was to own your servers for the base load, and go out for AWS for peaks. Running 24/7 compute bound work on AWS is at least 2x as expensive as owning your own co-located servers.

You can buy reserved instances that are about half the price as on-demand, so it really depends on how long the peaks are.

Dedicated servers are 1/4 or less of price of on-demand (don't forget the bandwidth!!!).

Re: Surprising Scalability of Multitenancy

#32

Earlier quoted context omitted.

The latency is still a factor of the AWS players interact with the non AWS ones.

I don't know how MMOs do this at all, but I would assume that for an MMO to be scalable, you do some sort of population-based geometric slicing of the world, and then assign each slice to a server such that players communicate with the server for their slice and the server for adjacent slices that are in some sort of visible/soon-to-be-visible range. That would mean no interaction between the servers - just between c…

The latency critical stuff traditionally happens in dungeons or other instances, precisely to get those players on a shared physical server. You just have a fleet of servers that each can handle X instances, and have a queue in between. And conveniently player state can just be synced in the loading time before and after the dungeon.

The bigger world is handled by slicing it up, but you still have a lot of communication going on with central databases for stuff like inventory management, chat, quests, etc. so you would probably try to keep all that within your own server racks.

Re: Surprising Scalability of Multitenancy

#33

Earlier quoted context omitted.

You can buy reserved instances that are about half the price as on-demand, so it really depends on how long the peaks are.

Dedicated servers are 1/4 or less of price of on-demand (don't forget the bandwidth!!!).

And all you need to do is pay a sysadmin or two in pizza to operate them :-)

Dedicated servers are undoubtedly cheaper in some circumstances than even a well-managed AWS account. But you do need to account for redundancy (including staffing), scaling up, possibly geographic replication, etc.). Setting up a dedicated server is just the beginning and be sure to take into account all costs--as is the case on a cloud provider too of course.

Re: Surprising Scalability of Multitenancy

#34

Earlier quoted context omitted.

> Time slicing significantly predates computers, and was quite well developed even when Erlang was analyzing it a century ago. I mean its implementation in computer systems. > What's surprising here isn't that time slicing works, it's that the same mechanism drives both the economics of large systems, and their ability to economically support bursty workloads. That's not surprising. > Clearly, I shouldn't have claime…

thank you, good samaritan, for doing the tough but necessary work of disparaging this blog post, and the person who posted it, because you find the conclusions obvious i'm sure that marc brooker, the author, and one of the most accomplished computer scientists currently living, will think twice before posting such pablum again

Somebody was surprised by the scalability of multitenancy :)

Re: Surprising Scalability of Multitenancy

#35
post #29

The author sounds a bit scared. Maybe the recent wave of "we can save $$$ by leaving AWS" articles have them rattled? Yes, multi-tenancy and improved hw utilization can save money ... for Amazon . That's of no use if they lack sufficient competition and just capture the savings as profits. Then you're just wasting time on debugging weird contention issues and cloud cost optimization consultants so Bezos can get riche…

that'd be cool but quite improbable until exploits like RowHammer, Meltdown and Spectre can be reliably ruled out.

Re: Surprising Scalability of Multitenancy

#36
post #33

Earlier quoted context omitted.

Dedicated servers are 1/4 or less of price of on-demand (don't forget the bandwidth!!!).

And all you need to do is pay a sysadmin or two in pizza to operate them :-) Dedicated servers are undoubtedly cheaper in some circumstances than even a well-managed AWS account. But you do need to account for redundancy (including staffing), scaling up, possibly geographic replication, etc.). Setting up a dedicated server is just the beginning and be sure to take into account all costs--as is the case on a cloud pro…

You absolutely need experts to run your cloud aswell, and there are colocating services that offer staff on hand for hardware issues, you don't actually have to run an entire datacenter even if you run baremetal

Re: Surprising Scalability of Multitenancy

#37
post #35
post #29

The author sounds a bit scared. Maybe the recent wave of "we can save $$$ by leaving AWS" articles have them rattled? Yes, multi-tenancy and improved hw utilization can save money ... for Amazon . That's of no use if they lack sufficient competition and just capture the savings as profits. Then you're just wasting time on debugging weird contention issues and cloud cost optimization consultants so Bezos can get riche…

that'd be cool but quite improbable until exploits like RowHammer, Meltdown and Spectre can be reliably ruled out.

Even if those were sorted, you probably want to hold out for homomorphic encryption. The threat model of Amazon having all your data is much different from the threat model of anyone willing to bid cheaply enough on a lambda execution having it. OTOH in the latter case, we can probably expect three letter agencies all over the world to be generously subsidizing our compute (for example, by reselling GovCloud at a loss).

Re: Surprising Scalability of Multitenancy

#38

Who is this surprising to? Timesharing, timeslicing, multiprocess, multitenancy,-- whatever you call the same underlying concept -- was one of the pivotal advances in computer systems. Surely no serious person is surprised it is effective.

I agree. It's not even about efficiently utilising resources. If we process things in timeslices that immediately kills any bad effects variability has on the workload. Small jobs go fast even if a big job happened to arrive in front of it.

(Of course, it's still a tradeoff between context switching overhead and the magnitude of the variability, but fundamentally even a tiny level of timeslicing can be a huge improvement.)

Re: Surprising Scalability of Multitenancy

#39
post #35
post #29

The author sounds a bit scared. Maybe the recent wave of "we can save $$$ by leaving AWS" articles have them rattled? Yes, multi-tenancy and improved hw utilization can save money ... for Amazon . That's of no use if they lack sufficient competition and just capture the savings as profits. Then you're just wasting time on debugging weird contention issues and cloud cost optimization consultants so Bezos can get riche…

that'd be cool but quite improbable until exploits like RowHammer, Meltdown and Spectre can be reliably ruled out.

Those problems affect cloud providers too.

BTW modern CPUs support the creation of RAM-encrypted VMs with remote attestation, so you can lower the trust needed in the targets by a lot. That said there are lots of companies that are known quantities, have verifiable brands and may even be considered more trustworthy than the big clouds in some cases because they're local firms.

Re: Surprising Scalability of Multitenancy

#40

Earlier quoted context omitted.

They should discount based on average cpu used.

You’re still consuming the RAM for the duration. In our on-prem VMWare environment, we didn’t charge, but we thought of the limited allocation being RAM far ahead of CPU ahead of disk.

The whole point of the bin packing in the blog post was to increase cpu utilization, so Amazon is clearly saving money if you are blocked on io.
Post reply on HN