- 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: Azure/azure-sdk-for-go#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.
- Azure/azure-sdk-for-go#324
compute.VirtualMachinesClient.Get
returns IDs with resource group name in lowercase, butcompute.VirtualMachinesClient.List
has 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 returnsnil
values 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
Created
May 15, 2020 10:23
-
-
Save kdomanski/7284b91999995354ca9f17b19de94d59 to your computer and use it in GitHub Desktop.
Azure issues
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment