Re: Cloud versus on-prem in depth.
I believe your "deep involvement" with public clouds has "clouded" your judgement. They don't have better architecture. Just different architecture. No one architecture fits all.
The idea that we should adopt hyperscale hardware and software solutions for on-premises IT is just flat-out bonkers. Hyperscale solutions are designed for hyperscale applications. They aren't inherently better, they sure as hell aren't easier to manage and they aren't cheaper unless you are buying and managing at hyperscale. That's before we talk about RPOs and RTOs. Something you conveniently didn't discuss at all, with the exception of a handwave that amounted to "rewrite everything you have because that lets you be more like Azure".
If enterprise tech hasn't changed a lot in 20 years, maybe you should start thinking that there's a reason for that. Like the fundamental designs are fit for purpose, and that changes will be incremental rather than foundational.
Regarding this bit: "if so many ppl left the cloud, it doesn't explain the surge in AWS and Azure revenue, i attended re:invent can tell you many Enterprise guys were there, some have a Cloud ONLY strategy ("CEO said we wont own any HW")"
I call bullshit. Why don't you go talk to Netflix or Dropbox about the cost of the public cloud? These are some headline names that have left for damned good reasons, and they are by no means the only ones.
Consumption of services which themselves consume the public cloud is increasing. Point solutions like HR applications, payroll applications, etc. These are applications that are like utilities to companies: every company needs them, but they aren't what make the company go. They aren't remotely attached to the core business, they're just a thing that the company has to have. Like phones. So they consume it as a service in order to not think about it. That is what's driving a lot of the public cloud growth.
But, like phones (or any other utility), there's a ceiling to that usage. Just like desktops and eventually tablets plateaued once everyone who had one wanted one, so too will SaaS consumption of these "software utilities".
Archival storage is another thing that's growing in the public cloud space. One look at someone like Backblaze will explain why. Public cloud storage can be very cheap. As long as you don't care about speed.
While I am certain that there are a few companies - usually American Fortune 2000 enterprises, or silicon valley startups - that are willing to go with a "cloud first" or even a "cloud only" model, these are niche. There aren't many of these companies. A fraction of a fraction of a many millions of companies in the world are willing to make that sort of commitment, and for good reason.
Now let's address the rest of your points...
Issue #1: You focus on Azure, but Microsoft isn't the be-all and end-all of clouds. I am aware that Microsoft's primary. storage is their own messed-up franken-glorp. I am also aware that they, like the others, will provide SANs as required to larger customers.
IBM is slightly different in that they aren't so circumspect with their provisioning of traditional storage. They're pretty up front about offering Storage-as-a-Service. For example, they offer Netapp. Indeed: if you need it bad enough, IBM will provide it as a service as part of their public cloud, no matter what it is, or who sells it.
Issue #2: while most data in public clouds today is in object storage and using "native" database services, most public cloud services today are the low hanging fruit. Stuff that was easy and cheap to move, or which was built new for the cloud. That doesn't make the public cloud ready to tackle the overwhelming majority of extant workloads.
Issue #3 (1, because you can't count): I never said JBOD wasn't cheaper. I said it was stupid, unreliable, problematic and way - way - more difficult to manage. It absolutely is cheaper to buy, which is the only thing that matters to hyperscale providers. Of course, when you're not a hyperscale provider, ease of use matters a heck of a lot more. So do RPOs, RTOs and other such things.
Issue #3 (2, because you can't count): File doesn't have to be slow. Until you get above 10M files (NTFS) or 100M files (ReFS, EXT, BTFRS). Then you have to get really creative with the OS an server design to prevent the whole thing from turning to glue. Object can be modest if accessed directly as object storage. It's a miserable pig if you have to use a shim (for example, filesystem access shim on top of object storage, block shim on top of object storage, etc.) There are some startups that have made solutions that almost don't suck on top of object storage, but as a general rule, object is slow when trying to use it as the storage backing for anything other than native object put/gets. Which is a huge problem for all those applications that don't speak object.
Issue #4: And here's you're back to "tear up everything you know and rewrite it because my religion says you should". Microsoft just announced 16 year support for SQL servers, bub. As much as you may get aroused by the idea of new database technologies, they're not helping companies with the software they have today.
Also, no matter how hard you scream, there absolutely are storage solutions that provide snapshotting for storage volumes that are tiered across multiple tiers of storage. I use them every day in production. I don't even need a fancy database to do it! My storage tiers the volume for me, and I run my old, boring databases on top of it. I get fantastic performance without tearing up everything I have and wasting - yes wasting - money recoding applications because some dude on the internet got religion.
I'm not missing background at all on this, mate. You are. You seem to assume that because a vendor supports something that you champion - in this case DAS storage tiering - that it is naturally better than all the other things they support. Here's a giggle for you: all the major databases from all the major vendors support multiple storage approaches, and multiple ways of doing things. Because they have customers. Not acolytes.
Continued in next post.