951 karma · joined September 26, 2014
I would go as far as saying that people concerned about GoDaddy providing services to anti-abortion groups don't even deserve a website. I work for for a SaaS, on the shop floor (luckily) and I'm offended that someone is intrested if someone wants to know who else is our client any more than the testimonials show.
And I'm pro-choice.
On the other hand, I had a regular blood test several weeks ago, and my blood sugar was borderline high for a fasting period. I just went out and bought a glucometer and tracked it for days later, it was much lower. It just happened on that one reading at the lab. The only explanation is that I was fasting for too long (close to 16 hours) and the lab was not the first thing I went in the morning, I had one more place to visit before. So my body was already fully woken up and/or my liver started doing its thing and produced glucose from fat or whatever.
Some human quirks are fun. Maybe because this guy doesn't look intimidating.
But what helped me with those other issues (like itchy ears) is to listen to my doctor (no pun intended) to "forget" I have ears. Only wash the outer most part of the ear and leave it to do it's part. Wax, although unappealing, is nothing bad and is actually protective. I cleanse it with a hydrogen and olive oil spray mixture from the pharmacy every few months.
Some colleagues are not so lucky. Multiple young children, small flats, day-to-day logistics complications, significant others that are essential workers (as my wife, who is working extra shifts since this pandemonium started, and I don't have an idea what would I do if we had a child) or could not work from home... And same goes for business partners or clients. I don't even dare scrutinize them about what they are going through these days. Some of their loved ones may be impacted, or they are having a hard time by themselves, the least they need is me judging them because they have a needy kid.
I remember a couple of years ago I had an interview with a job candidate, online because some other circumstances (FYI he was hired and is a great chap). He was pretty anxious, I can hear and see that, and in the middle of the interview his six-month baby started crying. We could hear the wife trying to calm the baby down and seen him sweating peas. My senior colleague did the best thing at that moment, basically aborting the interview discussion altogether and started talking about children and parenting and so on. We offered the guy to take a break, but the baby calmed down soon enough, so we continued. I remember the relief I've seen when he realized we understand him and that we're on the same page. He became much more relaxed in the rest of the interview.
3. Correct, I'm referring to azure-storage-blob and azure-mgmt-storage. I'm not concerned with the unmanaged disks so much, which utilize the storage accounts (thank god, we're over that :D ), more with working with regular blobs. From the initialization of the BlobClient to the operations which are sometimes weird in their input parameters, it's not up to par with lets say azure-mgmt-compute.
4. This point is not related to point 3. I'm completely referring to managed data disks, which are first class* entity (like NIC, for example, not a Page Blob any more). Attaching them to an existing VM is a nightmare, and because of some features we do that often. Also they lack basic things like per-disk disaster recovery (but this is way out of the scope of the SDK).
5. Correct, we're doing it by ourself. The LROPoller is also there in other parts of the SDK, we also use (if it's the same poller), but I think we were not able to utilize it. Ny clunky, I meant the response itself sometimes has headers with redundant values, we're not sure which one to use so we just take from experience (if there are two similar) etc. I haven't looked at the docs recently, but the "raw" requests are not documented that well.
* - I did say that managed disks are a first class entity, but we found out the hard way that the managed disks and managed snapshots are actually just in some storage accounts on the backplane, and when something goes South, storage-level errors leak out to our logic :) . Also throttling, thresholds and quotas apply as if it were just another storage account, but even worse, we don't control how the disks are distributed between those backplane storage accounts, so we get funky issues from time to time. We solve them by being extra careful and conservative with some operations, but heh, talking about leaky abstractions. This is not an SDK thing, just wanted to point that out for someone reading.
Disclaimer: some (or maybe all?) of the things I'm mentioning here might be caused by the API itself, rather than the SDK. The order is in which it comes to mind, rather than importance.
1. Some kind of strongly typed errors. I've turned the SDK upside down, and the only error that seems to pop up 90% of the time is CloudError with CloudError data. So our SaaS application (which utilizes Azure IaaS heavily) has a bunch of regexes that parse the messages contained in CloudError and throw something from our domain. Wrapping SDK errors by the implementing clients is a smart thing to do, but not this way :). Some messages change from time to time, so we try to make our regexes more tolerant, but you get the picture. In general the error handling is very strange, a lot of low-level errors sometimes flowing into high-level calls.
2. Documentation with more examples. The easiest thing to do is sometimes looking at the API or CLI documentation, and try replicating it with the SDK. Parameters named differently etc.
3. For some reason the Storage API/SDK keeps changing and it's like it's from another world than compute and network, which look pretty similar. The storage portion is... wild.
4. Improved working with data disks. Updating the VM with an array of disks has shown bad performance (and Azure support helped us and said that it can't be improved because it's a cross-RM event) but also poor reliability. A separate set of methods to attach/detach disks to VMs would be great.
5. Because we heavily rely on asynchronous operations, what we usually do is make a raw HTTP request for an operation (like VM deployment), serialize it and store it, then after some time deserialize it and check if the operation is done. We do the same with hundreds of requests at the same time, being able to process a lot of cloud operations with not much resources on our side :) . It works, but I found the raw request and serialization is a bit clunky. We're also stuck with a couple of older SDK libraries because we've noticed the raw responses changed in the newer ones, so now we need efforts to find all of the differences and consolidate the serialization. For example, the headers have had multiple urls to check the deployment status, sometimes it's `async-url`, sometimes `location-url` etc. This probably isn't something the SDK is to blame, and this is a niche case, but serializable async responses would be nice :D .
I have to commend the effort to break up the libraries from the original SDK into independent units. The versioning and dependency management became easier than with than one monolithic "4.0.0" schema.
Maybe some of the things are out of scope and our use-case is disproportionately affected by some stuff, it's just my two cents. I'm less satisfied with Azure as a service, with its unreliability, sub-par support, idiosyncrasies and poor "hypervisor" performance, than the SDK, but it's the SDK that gets all the blame because it's the one we're interfacing with.