Some of these "cloud" places, though, don't have that kind of oversight. They build their systems to just auto-scale up, and up, and up. Soon, there are dozens,

Some of these "cloud" places, though, don't have that kind of oversight. They build their systems to just auto-scale up, and up, and up. Soon, there are dozens, then hundreds, then even thousands of these crazy things. If they write bad code, and their footprint goes up every day, they don't even realize it. Odds are, the teams themselves have no idea how many "machines" (VMs in reality) they are on, or how quickly it's changing. There's no equivalent of my friend to stand there and tell them to first optimize their terrible code before they can get more hardware. The provisioning and deploy systems will give it away, and so they do. What usually happens is that someone will periodically run a report and find out something mind-blowing, like "oh wow, service X now runs on 1200 machines". How did this happen? That's easy. Nobody stopped them from needing 1200 machines in their current setup. People wring their hands and promise to do better, but still those stupid instances sit there, burning cash all day and all night. Most accurate picture of shops struggling with the problem of doing cloud well. Not only "cloud", but 3rd party APIs/managed services as well. Slab based pricing, pricing on various rates, pricing on data. what not! I have come to believe that most of the cloud/API vendors make bill tracking so convoluted and hard on a definitive purpose, just so that people can't get easy visibility and early-warning of impending disasters. Any firm/outfit that says "we want to use cloud for its elasticity" must be prepared for that "elasticity in the billing" too. If they are not, they will find themselves in deep troubles.