11–20 of 40 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
The latency is still a factor of the AWS players interact with the non AWS ones.
Edit - And if a group of players raid a dungeon, the population of that dungeon is strictly limited, so you can park that raid on one server and don't worry at all about inter-player latency.
One 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.
AWS serverless, by the way, uses VM isolation.
Earlier quoted context omitted.
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.
This isn't how things always run in the cloud. I think the conventional wisdom is that the isolation of VMs is good enough unless you are very paranoid. Auth services are regularly run on less than full baremetal machines. AWS serverless, by the way, uses VM isolation.
https://aws.amazon.com/ec2/dedicated-hosts/
https://cloud.google.com/compute/docs/nodes/sole-tenant-node...
The AWS offering is pretty much turn-key. I've not used the GCP version, but it seems to be similar if you're willing to create a separate "project" for each security domain.
Once your company has any PII and/or has regulatory obligations (PCI, HIPAA, etc) then it's worth spending a bit extra to make sure sensitive components are running on their own hardware.
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.
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 tho…
No hate. Was (is) a frustrating experience for me too.
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.
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.
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 tho…
Amazon doesn’t over commit cpu for normal VM instance types.
Earlier quoted context omitted.
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 tho…
The lesson for you was in communication not engineering. No hate. Was (is) a frustrating experience for me too.
On the team I was on, newly-hired managers from Amazon accepted the ideas of ICs who had previously worked at Amazon, and rejected ideas from people who had not. I didn't realize this was a pattern until I already had one foot out the door, but even if I had realized it earlier it wouldn't have helped. I was ex-Google, so the ex-Amazon folks tagged every document with the bozo bit before they'd even opened it.
My takeaway was to be cautious of companies where the culture is imported through mass hiring from single companies. I joined in the middle of the "Google wave", which was relatively peaceful (per Google's culture at the time). When the "Amazon wave" arrived it was quite a shock; their culture was much more adversarial and authoritarian than anywhere I'd worked before. By the time I left, there were signs the Amazon folks were starting to get sidelined by an emerging "Oracle wave".
Earlier quoted context omitted.
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 tho…
Doesn’t it depend on how many cpu cores to some extent and how much the ruby process is idle on io? Amazon doesn’t over commit cpu for normal VM instance types.
Imagine you have three Ruby services, where each is allocated 10 cores of CPU time (via pinning with cpuset). If you give them each an 16-core VM, then there'll be 18 cores of "wasted" CPU. If you instead bin-pack them onto a 32-core VM, then they'll have the same number of cores at a lower price point.
If each service runs at 50% capacity with 2000ms latency during steady state, how much extra latency would you expect the service to have on the bin-packed configuration vs the single-VM?
My position is "very little extra latency", the other person's position was "a lot of extra latency due to hardware contention in (for example) the memory controller".
(If you're reading this and thinking "NUMA node locality", then you're operating two or three levels above where this org was in terms of optimization.)