> I think you underestimate the middle management "everyone is doing it so it must be better" argument. Not at all. Although I didn't state it outright (in thi

> I think you underestimate the middle management "everyone is doing it so it must be better" argument. Not at all. Although I didn't state it outright (in this thread), I'm convinced that this, rather than cost, is the critical factor in this decision, not just in middle management but all the way to the top (especially in startups where there may not be a middle). > People regularly talk about how inexpensive AWS is vs buying hardware and renting space. As I mentioned in another thread [1], they're both right and wrong. For the general case, and if cost were actually a critical factor, they'd be wrong. However, as you point out, they've been sold on the idea (i.e. perception). Since what they end up having to pay is actual, not perceived cost, perhaps what we're saying is that a form of delusion is a factor in the decision making. > This is probably true for people who only need tiny instances or have massively variable workloads. I'd go so far as to say it's definitely true in those cases, but that they're rare/niche enough to be irrelevant to the broader discussion. Even the latter case, the sweet spot for "elastic" compute, is hard to imagine being the exclusive workload in an environment. To borrow a term from electrical generation, there's always some "base load". If the variable load is being used as justification for running the base load on AWS, then any cost savings could be wiped out [2]. I've found these lines of reasoning never have any actual numbers (cost analysis) behind them. > the idea that its hard to rack machines and buy clean power & network connections. Those things are trivial, of course, since they're generally outsourced (and safe [1] to outsource), but there's more to it. In that way, the idea is also both right and wrong. It's not trivial/obvious how to do it right, without getting bilked for too much money or creating needless risk/instability. It isn't however, cognitively or intellectually challenging and can easily be taught. It is, however, potentially tedious and unsexy, which means that hiring someone to do it exclusively isn't a credible option. Fortunately, that aspect of even a few hundred servers might take up a quarter of senior engineer's time [3], and all the other things (that would still need doing even with AWS) would take up the rest of the time. > a back of the envelope calculation wouldn't lead you to understand where all the compute power is actually going. That's part of the magic of AWS, it doesn't have to "go" anywhere to get charged. GCP recently announced a more pro-rated approach to, at least, CPU cores, based on actual usage. In general, even to take advantage of elasticity, a customer has to expend (costly) engineering effort and/or engage in the vendor-lock-in auto-scaling tools provided. Even then, there's opportunities to slip under the radar, such as with unattached EBS volumes, or snapshots on volumes, or S3. I'm sure there's a myriad of other opportunities to get charged for unused services spread throughout the AWS ecosystem. [1] https://news.ycombinator.com/item?id=18043544 https://news.ycombinator.com/item?id=18043544 [2] I interviewed with a startup that was attempting to use this justification to move completely out of a colo, even though the variability of their "spiky" load was below 10:1 and their base load was well over half. [3] Something that is often grossly over-estimated by people who have inadequate experience. I've read here on HN "but then we'd have to hire 5 sysadmins", a 10x over-estimation.