> But you also have the turn around time to actual get the physical boxes and you can’t run experiments as easily. That's a false dichotomy. There's nothing sa

> But you also have the turn around time to actual get the physical boxes and you can’t run experiments as easily. That's a false dichotomy. There's nothing saying that, when one has physical infrastructure, that one cannot also use cloud infrastructure in cases where it's needed (and transition when it's not.. it's the transition part that's usually missing). > Can you imagine the red tape and the time it would have taken to do that self hosted? I don't have to imagine, as I have experience doing things self hosted. "Red tape" is just a political problem within a company, not a technical one. In some cases, even time is zero, if I happen to have spare hardware to lend. Regardless, the whole experimentation situation is a strawman. It is, effectively, indistinguishable from early startup. > 1. You’re not taking into account the total cost of an equivalent redundant system within a data center and between geographically redundant data centers Nope. Always apples-to-apples. Physical DC redundancy costs something, but it's approximately linear. (Double for twice the price). Multi-cloud gets very costly in engineering time, too, if you want true redundancy in that context. > 2. You’re overprovisioning and not architecting with the mindset of elasticity. Overprovisioning goes against the definition of comparable. The "mindset of elasticity" is entirely too hand-wavy, as it's only a savings mechanism, and only for part of the infrastucture. It also only works if the workload itself is actually elastic enough. That's part of why my range for the AWS premium is 2x-10x. The other part is that not everything is about CPU+memory (i.e. EC2), and I/O, including EBS and data transfer costs can play a big role. > 3. You’re not taking into account the ability to move a lot faster by not having the lead time between an idea and provisioning hardware and getting things to market. Besides being a strawman argument, that has nothing to do with the infrastructure cost. After bridging the initial lead time, AWS will still cost multiple times more, over years, if not transitioned off of. > 4. You’re not taking into account either a global workforce or global customer base. At one company we had people working overseas, performance was horrible. Again, nothing to do with the cost of the underlying infrastructure. It's just an argument of the form "<benefit of cloud> makes it worth the premium price", which isn't the same as the premium not existing. I'm willing to concede that, for certain location, AWS might actually be cost-competitive, due to, for example, otherwise insufficient competition in commodity hardware vendors or internet service. However, I'm skeptical that such a place exists and is served by AWS. > I blame “AWS Architects” who take thier on prem netops mindset to the cloud, I'm not sure how you can legitimately blame the existence of those you consider incompetent for the non-existence of those who are competent. > developers who don’t know how to architect with elasticity in mind, I'd argue there's nothing wrong with that, as they shouldn't have to care. Plus, some workloads just aren't easily elasticized, just like some (many) aren't easily parallelizable with software, no matter how much you might personally wish it were so. That not-easy can translate to huge engineering costs (which I've seen for parallelization, though not elasticity, for the very reason you mentioned). > and devops folks who don’t know how to use AWSs built in devops tools. That sounds like a recipe for vendor lock-in, which is another way of saying higher-cost-lock-in. > There is no reason that costs shouldn’t go up linearly (at a lower slope) as the number of customers increase. There are plenty of reasons, not the least of which is naive/inefficient distributed systems design. Notwithstanding the fact that No True Scotsman would ever create such a system, I've witnessed more than a few. > with predictable growth Everyone has predictable growth, given a short enough timescale. That's part of the point of using commodity hardware, rather than something like "enterprise" hardware, where sometimes just the sales cycle can be prohibitively long. Extrapolating lead times from ones experience in a giant corporation or from the dot-com era is unrealistic. > Also if you are a low margin B2C company it may not make sense at a certain scale. I posit that neither the size of the margin nor the nature of the business makes any difference. Having a vastly too high COGS doesn't make sense for any business.