I took your previous comment to be about on-prem cloud technology. It exists and does not need to be "cloned". If you were taking about staffing resources, we've pretty well established you're going to need staffing to manage both cloud and on-prem tech.
You need to document whether it's on-prem or in the cloud.
If you buy storage by the petabyte or use a large enough amount of network egress, you can definitely make that money back but it's a major commitment.
Agree, I don't think anyone is buying SANs that don't need them. If you're spending 7 figures on your AWS bill, you should be looking into other options.
That is building an S3 replacement. You aren't writing every line of code personally but you are selecting components, configuring them, operating the service, and testing it, which is a major commitment. Simply running k8s at an equivalent level is a non-trivial commitment.
> Agree, I don't think anyone is buying SANs that don't need them. If you're spending 7 figures on your AWS bill, you should be looking into other options.
Note that the 7 figure commitment I mentioned was what you'd need to build an S3 equivalent. Simply having 24x7 staffing and hardware easily puts you in that range.
You're casting this as a much more complicated concept than it is. It is essentially the same old "build vs buy" argument. No, it does not make sense to manage a datacenter to run a single wordpress blog, nor does it make sense for a telco to run their infra on top of a public cloud. These are all truisms.
My point stands that if you have a seven-figure AWS bill, you already have plenty of associated staffing costs. Once you hit the break-even point between the two, you can decide whether you want to continue to pay linearly, or go down the path of increasing RoI.