Surprising Scalability of Multitenancy
brooker.co.za
Surprising Scalability of Multitenancy
1–10 of 40 posts
Re: Surprising Scalability of Multitenancy
#2One thing this scalability bets on is that side channel attacks won’t get better.
Spectre and related attacks already reduced CPU performance.
Shared hardware opens up the door for side channel attacks and hardening against those attacks is going to decrease performance.
Re: Surprising Scalability of Multitenancy
#3Who 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.
Re: Surprising Scalability of Multitenancy
#4Who 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.
Time slicing significantly predates computers, and was quite well developed even when Erlang was analyzing it a century ago. 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.
I can understand that may not be a surprise to you. What's surprising to me is that you took the time to come say you aren't surprised, instead of going on with your day.
Clearly, I shouldn't have claimed this casual blog post was original research that had never been seen in any form before. Silly me!
Re: Surprising Scalability of Multitenancy
#5I'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.
Re: Surprising Scalability of Multitenancy
#6Who 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.
Time slicing significantly predates computers, and was quite well developed even when Erlang was analyzing it a century ago. 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. I can understand that may not be a surprise to you. What's surprising to me is that you took the time to com…
> 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 claimed this casual blog post was original research that had never been seen in any form before. Silly me!
That's not the issue though is it, that's your snarky strawman to deflect from it. Which is that its a lazy cliche title and it purports to be much more grandiose than it is.
Re: Surprising Scalability of Multitenancy
#7I'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.
I guess the latency between AWS and your data centre would have a negative impact on game performance.
Re: Surprising Scalability of Multitenancy
#8Who 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.
At my previous employer, there was at least one person with a "staff software engineer" job title who believed that running more than one Ruby server process per AWS virtual machine would lead to unacceptable contention at the hardware level. I was never able to convince them that Linux handles tens of thousands of processes just fine, or that even if you do one per VM there's nothing stopping AWS from scheduling those VMs onto the same machine.
I guess whether you consider someone like that to be a "serious person" or a "charlatan" depends on your own point of reference.
In that case, their arguments were more persuasive to management than mine were. I found the experience baffling.
Re: Surprising Scalability of Multitenancy
#9One thing this scalability bets on is that side channel attacks won’t get better. Spectre and related attacks already reduced CPU performance. Shared hardware opens up the door for side channel attacks and hardening against those attacks is going to decrease performance.
You'd generally use co-tenancy for workloads that are mutually trusted. Privileged services (authn/authz, machine management, deployable artifact builds) get put onto separate hardware, since their footprint is small enough that the extra 200% cost isn't material.
Re: Surprising Scalability of Multitenancy
#10I'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.
I guess the latency between AWS and your data centre would have a negative impact on game performance.
I believe the idea is to spin new servers on AWS and and connect players directly to them instead of hopping via their own infra.
That’s way your profit margins on the AWS servers is lower than self hosted ones but at least you’re making money.