[cle]

It’s a lot easier and safer to scale hosts horizontally than vertically. You can predict the limits and behavior of each host, the VMs/processes on each host don’t need to deal with fundamental resources changing, etc. For services I own that are high availability, require GC tuning, etc., these hosts with dynamic resource adjustments (also T2/T3 in AWS) are a nightmare because the behavior can change at runtime under load, exactly when I want it to behave predictably.

[bullen]

Sure but:

1) Some things can't scale on more hosts, like say an action MMO with no sharding.

2) Scaling dynamically does not necessarily mean you have to do it unpredictably.

Are you running them as unlimited or standard?

[cle]

Oh definitely there are valid use cases for these, was just sharing my experience with them for my use cases.

We moved off of T2’s and back to C’s because of the unpredictable behavior under load. IIUC, T3s by default just bill you more instead of CPU throttling, which is a bit better for our use cases, but we haven’t tried them yet.

[bullen]

Aha, thanks for that very valuable information!

T3 look cheaper and better than E2 then, my only problem is region placement where Iowa and Taiwan are more central than anything AWS offers (still no central US region!?).

I'm in the MMO business, so very specific requirements.

[boulos]

Disclosure: I work on Google Cloud.

T3 is pretty different (even in unlimited mode) than E2. As an example, t3.xlarge (4 vCPU, 16 GB, $.167/hr, so $.042/hr/vCPU roughly) only has a baseline performance of 40% (so 1.6 vCPU). If you cross that threshold in unlimited mode you pay an additional $.05/vCPU/hr (so more than doubling your cost). By comparison an e2-standard-4 is $.134/hour even if you run it flat out.

We take on the statistical multiplexing over the datacenter and move VMs around, instead of pushing it to you as an economic or performance-throttling risk when you need it most. If you want a burstable type, we do have an e2-{micro, small, medium} that only guarantees you 12.5%, 25% and 50% of your 2 guest-visible vCPUs. But that's more fit for dev workstations and so on.

[bullen]

Are the shared E2 cores (e1-micro f.ex.) guaranteed to be on different physical cores? See my reply to AWS below.

[ti_ranger]

> We take on the statistical multiplexing over the datacenter and move VMs around

You're implying here that EC2 doesn't do this.

On what basis?

[boulos]

Sorry if I was unclear. In unlimited mode, if you sustain greater than your baseline percentage, you pay for it (the key point of the sentence you’re quoting is that we take on the risk). One reason for this happens to be because AWS doesn’t do migration (yet?), but instead does an awesome job of doing in-place upgrades (see their talks on Nitro, for example).

[Dylan16807]

Every search result I can see says that EC2 doesn't do live migration. You can try to balance things but you can only do so much if you can only move a VM when it happens to reboot by itself. (And there's no evidence I can find that they even do that.)