By "the size" I meant to say "the size of the infrastructure", meaning that AWS has to manage orders of magnitude more instances than Hetzner. This might as well contribute to "things" being slower.
Arguably it can also make things faster. A small provider might need to migrate other instances around to make space for your new instance, whereas a big provider almost certainly can satisfy your request from existing free capacity, and it should therefore be a matter of milliseconds to identify the physical machine your new VM will run on.
I understand that, apologies for not making that clear.
I guess I'm just struggling to see how having more VMs means it takes longer to provision one? A database query to find the space and get an allocation should be milliseconds in either case.
More employed eyes on an issue or ability to compensate the best-in-class engineers to take a look.
Exactly, so a large provider should theoretically have faster boot times if anything, no? More chance of having a customer who cares deeply, more wasted CPU cycles (and therefore incentive to optimise) as it's multiplied by 10 million rather than 10 thousand instance starts. More likely to have larger quantities of engineers available, more monitoring/data/telematics.
The article mentions hydration (a process to reduce the penalty of first access of a data block). This is done by essentially reading the entire EBS volume with the tool like fio or dd. The time it takes to complete this process is relative to the amount of dirty blocks. Therefore, it will take twice as long to hydrate 20 GB of data compared to 10 GB.
Likely they mean that following Conway's law in AWS there are more abstraction layers involved.
Most likely true, but things are going deeply wrong if fresh Debian VM boot times are a function of the organisational structure of your hosting provider.
Smaller companies are faster and more nimble than larger corporations.
Yes, but why specifically does that mean boot times of a VM are faster? One has to be 'nimble' to improve that?