- Azure is generally slow, both in terms of the API and the machines themselves.
- The cheaper machines with one CPU actually provide a very small percentage of an actual CPU's computing time.
- It takes minutes to create a VM and all of its resources.
- Same with deleting it.
- Deletion of connected resource must be conducted in specific order, or the resources must be disconnected first. e.g. cannot delete a NIC while it is assigned to a VM.
- VMs seem to be created one by one, even if the calls to create them were made in parallel.
- No sensible API lifecycle management. They just cut off a new version with a timestamp in module path, resulting in many, many versions to choose from.
- This results in so much code that the Go lead developer comes over and scolds them: https://github.com/Azure/azure-sdk-for-go/issues/1969
- API endpoints return identifiers in inconsistent forced casing, e.g. one endpoint returns IDs lowercase, another uppercase, and yet another in the original casing.
compute.VirtualMachinesClient.Getreturns IDs with resource group name in lowercase, but
compute.VirtualMachinesClient.Listhas them in uppercase
- All fields returned by API (even non-optional!) in the Go SDK are pointers, so they can potentially be
nil. Azure SDK sometimes returns
nilvalues even for non-optional values - forcing nil-checks on absolutely everything to avoid panics.
- API calls to create objects often don't return their IDs, forcing to get it by resource name in a separate call.
- Some API endpoints accept resource names, and other full resource IDs.
- When creating a security group with the API, it silently injects its default rules ontop of the explicitly specified ones