That's incredible to me. Their support is completely and utterly inept, AFAICT.
Just today, I've been asked for what availability for a meeting I have between the hours of 9pm and 6am (and no, that's not a typo!).
You can't paste errors into the ticket. Their support system doesn't even support all of printable ASCII. The reps don't read the ticket before responding. If you can't replicate the error in front of their eyes, it doesn't exist, and even if you can, they won't believe you. I've literally had them defend 56 kpbs as being "good enough throughput", I've had "What is your ISP?" on "we get 500 Internal Server Error from $service" (and … our ISP is you, Azure…) … yeah. The list of idiocy we've seen just goes on and on and on.
Their support team wants to talk about "how can we architect a cloud system that'll blah blah enterprise blah", I just want valid API calls to succeed. I'm an eng, I can do the building, I just need APIs that aren't hot garbage.
(The outage I allude to in the above comment is actually mentioned in passing in [1]. I had to link to that blog post in the support ticket! (So thank you, Scott Helme, for writing it.))
“ Microsoft Azure Application Gateway was no longer connecting to servers using a Let's Encrypt certificate”
Why would you expect TLS to work correctly on a HTTP load balancer that can’t do HTTP properly either?
Microsoft App Gateway is incompatible with Microsoft’s own SharePoint server for example because it doesn’t send a user agent header in the health monitor probes, which about 50% of all web apps require. Similarly it can’t send authentication headers either so it can’t monitor web apps that enforce security.
It’s a security product incompatible with security and encryption.
Let that sink in and then look at what you’re paying for this on your next monthly bill.
> Why would you expect TLS to work correctly on a HTTP load balancer that can’t do HTTP properly either?
Well, it doesn't exactly advertise that on the tin, now does it?
And we're not using it as a security product (I know there are people out there after "WAF"s and … stuff … but that's not us); AFAICT, it is Azure's offering equivalent to AWS's ELB.
(It is tempting to remove it from the architecture, but unfortunately, we're integrating with a third-party in this case that wants it that way. Everywhere else we need an HTTP proxy we use nginx…)
Most of my clients are big enterprise, and they insist on ticking the "WAF" checkbox. Unfortunately, App Gateway is pretty much the only Azure-native option for this. Front Door also has a WAF module, but it's even worse. Microsoft markets both as "security" products.
Speaking of Front Door: it's a CDN, TCP accelerator, and TLS offload performance product that slowed down web site performance in every test that I've ever done with it. It doesn't even begin to approach the features of some of its competitors. For example it still can't do HTTP/3 or TLS v1.3. Or Brotli, or ZStandard, or multi path TCP, or anything really that helps performance.
Just today, I've been asked for what availability for a meeting I have between the hours of 9pm and 6am (and no, that's not a typo!).
You can't paste errors into the ticket. Their support system doesn't even support all of printable ASCII. The reps don't read the ticket before responding. If you can't replicate the error in front of their eyes, it doesn't exist, and even if you can, they won't believe you. I've literally had them defend 56 kpbs as being "good enough throughput", I've had "What is your ISP?" on "we get 500 Internal Server Error from $service" (and … our ISP is you, Azure…) … yeah. The list of idiocy we've seen just goes on and on and on.
Their support team wants to talk about "how can we architect a cloud system that'll blah blah enterprise blah", I just want valid API calls to succeed. I'm an eng, I can do the building, I just need APIs that aren't hot garbage.
(The outage I allude to in the above comment is actually mentioned in passing in [1]. I had to link to that blog post in the support ticket! (So thank you, Scott Helme, for writing it.))
[1]: https://scotthelme.co.uk/lets-encrypt-root-expiration-post-m...