Hilariously, adding retries to applications can make them “bi-stable”, where they can get stuck in a faulty overload state.
This isn’t for writing reliable web apps, it’s compensating for Azure’s slow database offerings.
In an era where I can buy 1 million IOPS for a few hundred dollars, I have to write code to compensate for the few hundred IOPS that I can buy from Azure for thousands a month.
“But, but, cloud storage is different and not at all comparable to an NVMe drive” — you’re about to say.
It seems crazy to me that you need to solve such infrastructure concerns at the application level. I'm really interested how this works in a large scale application. Are retries sprinkled throughout the code base? Especially for database stuff, as EF Core doesn't support transactions when retries are enabled.
I bet these resiliency issues and the fact you need to modify your application didn't make it into the cloud sales talk. I also don't see many resources mentioning it.
Is this also mainly an Azure problem or does it also happen on AWS?
Generally this kind of thing is needed for all clouds, but Azure SQL has a few additional issues in some SKUs.
It all stems from the decreasing “IOPS per TB” as mechanical drives get bigger. Large scale multitenant hosting uses up all available IOPS, which means it has to be carved up and meted out carefully.
Years of this being the status quo set an expectation that the availability of modern SSDs hasn’t yet eliminated. Everyone is used to services with throttled throughputs of a few hundred operations per second in an era where this should be a few hundred thousand…
This doesn't really feel like much of a revelation. Retry w/circuit breaker and cache-aside are things I was doing almost 20 years ago, and others long before that.
5 comments
[ 4.3 ms ] story [ 26.9 ms ] threadThis isn’t for writing reliable web apps, it’s compensating for Azure’s slow database offerings.
In an era where I can buy 1 million IOPS for a few hundred dollars, I have to write code to compensate for the few hundred IOPS that I can buy from Azure for thousands a month.
“But, but, cloud storage is different and not at all comparable to an NVMe drive” — you’re about to say.
Yes. I know. That’s my point.
I bet these resiliency issues and the fact you need to modify your application didn't make it into the cloud sales talk. I also don't see many resources mentioning it.
Is this also mainly an Azure problem or does it also happen on AWS?
It all stems from the decreasing “IOPS per TB” as mechanical drives get bigger. Large scale multitenant hosting uses up all available IOPS, which means it has to be carved up and meted out carefully.
Years of this being the status quo set an expectation that the availability of modern SSDs hasn’t yet eliminated. Everyone is used to services with throttled throughputs of a few hundred operations per second in an era where this should be a few hundred thousand…