investigate the idea of making the API behave as if it's synchronous (so dev doesn't need to deal with it as if it's asynch) but make it asynch under the hood when possible, and implement provisioning status checks so that the blocking on a given not-yet-provisioned resource happens only when a subsequent call is made to that resource that expects it to be ready. That way large parts of VM creation could be automatically parallelized so that the end-to-end perf could be better, but still the same simple synch API model on the surface.
Perhaps internally, the dependent resource action could check the status of the dependency resource and simply wait while provisioningStatus is not "ready" but it is at least "creating",
investigate the idea of making the API behave as if it's synchronous (so dev doesn't need to deal with it as if it's asynch) but make it asynch under the hood when possible, and implement provisioning status checks so that the blocking on a given not-yet-provisioned resource happens only when a subsequent call is made to that resource that expects it to be ready. That way large parts of VM creation could be automatically parallelized so that the end-to-end perf could be better, but still the same simple synch API model on the surface. Perhaps internally, the dependent resource action could check the status of the dependency resource and simply wait while provisioningStatus is not "ready" but it is at least "creating",