5 ms·

I’m feel your pain also my friend. Azure quality is terrible compared to competitors: * no good working examples in docs * docs hard to read * docs are not c

by xiwenc 6y ago

I’m feel your pain also my friend. Azure quality is terrible compared to competitors: * no good working examples in docs * docs hard to read * docs are not consistent with reality * the web portal UX is inconsistent and outright weird (when you navigate through resource group, you can scroll back horizontally to previous context/screen; what a joke) * there are a gazillion preview api versions that never gets released officially. * and if you’re lucky to work with azure devops, it’s like building a house of cards with different card types and sizes I’ve worked with AWS and GCP in the past. Indeed Azure is often chosen by CIO’s rather than people that have to work with the service every day.

FridgeSeal 6y ago
Oh my god the web UX, how did I forget about that: for the life of me I cannot figure out why they make all the interfaces scroll sideways. Why? Who does that? Docs being hard to read and inconsistent with reality is a big point. My favourite mismatch is the storage classes one: it turns out there's actually 2 different grades of SSD available, but their examples and docs only mention premium SSD's. I only discovered "normal" SSD because they happen to auto-create a storage class with them in your Kubernetes cluster. The adventure to figure out whether you can attach a premium SSD to an instance is a whole new ball game - trying to find which instances _actually_ allow you to attach them is like looking for a needle in a haystack. Why are they so difficult about it? AWS is like "you want an EBS volume of type io1? There you go, done". Azure: "oh no, you _can't_ have premium ssd. Because reasons".
- arethuza 6y ago
  I thought the sideways scrolling (which was pretty weird) was only on the "old" Azure Portal - I'm not aware of it bothering me on the current Portal.
- ahoka 6y ago
  Actually there are three kind of SSD storage types in Azure: Standard, Premium and Ultra. I’m assuming that you need to provision an ‘s’ VM because the regular instances lack the connectivity for the faster storage, but that’s just guessing.
  - FridgeSeal 6y ago
    Oh I forget about the ultra ones. I found a few instance types when I went looking, but their interface does not make it easy to figure out which ones are premium eligible, but I do remember the price going up not-insignificantly for a premium capable machine, which feels about like double-dipping if you’re also paying extra for the SSD.
GordonS 6y ago
What's your beef with Azure DevOps? Personally, I love it, and find it far superior to anything else I've tried.
- FridgeSeal 6y ago
  Those configs feel like they're longer than a Russian literature novel. Setting them up is a pain: why do I need a different set of permissions to set up a service connection for every single pipeline? Why does my manager who has what we can only assume is a _marginally different_ set of permissions just see an approve button for the service connection but I get taken to page asking me to setup a service connection? (Which ultimately fails anyway) Why does it want to create a Kubernetes secret on every deploy? It does funny things with the output from Kustomise, and we discovered we had to add parameters in to make it stop adding characters to the end of the generated configs. Did you once, look at a pipeline? Be prepared to get more emails from devops than an overly-eager marketing department. If you have a Terraform in your Pipeline, Azure will lie to you about the status of you Apply's: it'll tell the pipeline that the resource was created, when it fact it was not successfully created, this will mess up your TF state. If you deploy to a K8s cluster, and your application crashes during startup for some reason, the pipeline treats this as a failure, IMO that's beyond it's set of responsibilities: it should take care of making sure the deployment configs get to Kubernetes, application failing to start is the concern and responsibility of the developer, not the CI pipeline.
  - GordonS 6y ago
    I can't comment on the k8s stuff specifically, but that does seem to be rather notorious for dubious documentation and features. > Those configs feel like they're longer than a Russian literature novel Assuming you mean pipelines YAML files, I can't agree - my pipelines are always quite terse, and you can also split them into multiple files if wanted. IME they are no longer than pipeline configs from AppVeyor, Travis etc. > Setting them up is a pain: why do I need a different set of permissions to set up a service connection for every single pipeline? IIRC, you don't - I'm sure there is an option when creating the connection to grant permission to all pipelines. > Why does my manager who has what we can only assume is a _marginally different_ set of permissions just see an approve button for the service connection but I get taken to page asking me to setup a service connection? (Which ultimately fails anyway) Working with service connections is definitely a PITA, but since you need to have the requisite permissions in Azure, I'm not sure there is a good way of handling things. > Did you once, look at a pipeline? Be prepared to get more emails from devops than an overly-eager marketing department. I work with pipelines all the time, and don't recall getting a single email from Azure DevOps marketing people.

by xiwenc 6y ago

FridgeSeal 6y ago

Oh my god the web UX, how did I forget about that: for the life of me I cannot figure out why they make all the interfaces scroll sideways. Why? Who does that? Docs being hard to read and inconsistent with reality is a big point. My favourite mismatch is the storage classes one: it turns out there's actually 2 different grades of SSD available, but their examples and docs only mention premium SSD's. I only discovered "normal" SSD because they happen to auto-create a storage class with them in your Kubernetes cluster. The adventure to figure out whether you can attach a premium SSD to an instance is a whole new ball game - trying to find which instances _actually_ allow you to attach them is like looking for a needle in a haystack. Why are they so difficult about it? AWS is like "you want an EBS volume of type io1? There you go, done". Azure: "oh no, you _can't_ have premium ssd. Because reasons".

arethuza 6y ago
I thought the sideways scrolling (which was pretty weird) was only on the "old" Azure Portal - I'm not aware of it bothering me on the current Portal.
ahoka 6y ago
Actually there are three kind of SSD storage types in Azure: Standard, Premium and Ultra. I’m assuming that you need to provision an ‘s’ VM because the regular instances lack the connectivity for the faster storage, but that’s just guessing.
- FridgeSeal 6y ago
  Oh I forget about the ultra ones. I found a few instance types when I went looking, but their interface does not make it easy to figure out which ones are premium eligible, but I do remember the price going up not-insignificantly for a premium capable machine, which feels about like double-dipping if you’re also paying extra for the SSD.

GordonS 6y ago

What's your beef with Azure DevOps? Personally, I love it, and find it far superior to anything else I've tried.

FridgeSeal 6y ago
Those configs feel like they're longer than a Russian literature novel. Setting them up is a pain: why do I need a different set of permissions to set up a service connection for every single pipeline? Why does my manager who has what we can only assume is a _marginally different_ set of permissions just see an approve button for the service connection but I get taken to page asking me to setup a service connection? (Which ultimately fails anyway) Why does it want to create a Kubernetes secret on every deploy? It does funny things with the output from Kustomise, and we discovered we had to add parameters in to make it stop adding characters to the end of the generated configs. Did you once, look at a pipeline? Be prepared to get more emails from devops than an overly-eager marketing department. If you have a Terraform in your Pipeline, Azure will lie to you about the status of you Apply's: it'll tell the pipeline that the resource was created, when it fact it was not successfully created, this will mess up your TF state. If you deploy to a K8s cluster, and your application crashes during startup for some reason, the pipeline treats this as a failure, IMO that's beyond it's set of responsibilities: it should take care of making sure the deployment configs get to Kubernetes, application failing to start is the concern and responsibility of the developer, not the CI pipeline.
- GordonS 6y ago
  I can't comment on the k8s stuff specifically, but that does seem to be rather notorious for dubious documentation and features. > Those configs feel like they're longer than a Russian literature novel Assuming you mean pipelines YAML files, I can't agree - my pipelines are always quite terse, and you can also split them into multiple files if wanted. IME they are no longer than pipeline configs from AppVeyor, Travis etc. > Setting them up is a pain: why do I need a different set of permissions to set up a service connection for every single pipeline? IIRC, you don't - I'm sure there is an option when creating the connection to grant permission to all pipelines. > Why does my manager who has what we can only assume is a _marginally different_ set of permissions just see an approve button for the service connection but I get taken to page asking me to setup a service connection? (Which ultimately fails anyway) Working with service connections is definitely a PITA, but since you need to have the requisite permissions in Azure, I'm not sure there is a good way of handling things. > Did you once, look at a pipeline? Be prepared to get more emails from devops than an overly-eager marketing department. I work with pipelines all the time, and don't recall getting a single email from Azure DevOps marketing people.