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.
Surprising Scalability of Multitenancy
31–40 of 40 posts
Re: Surprising Scalability of Multitenancy
#32Earlier 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 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
#33Earlier 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!!!).
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
#34Earlier 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
Re: Surprising Scalability of Multitenancy
#35The 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…
Re: Surprising Scalability of Multitenancy
#36Earlier 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…
Re: Surprising Scalability of Multitenancy
#37The 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
#38Who 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.
(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
#39The 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.
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
#40Earlier 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.