No, thats ridiculous. You are still paying for all the servers in the server farm, even if you have decided to waste another year of Moores law to add a bulky abstraction layer on top.
The whole point of a cloud to a business is that you can adapt to changing needs without having to pay for all the infrastructure all the time.
(You didn't think the suits talk about "the cloud" all the time because they fancy the technology, right?)
> You are still paying for all the servers in the server farm
Amazon is paying for all the servers in the EC2 server farm. Does that stop EC2 from being a cloud?
TestingBot is spinning up VMs dynamically to scale out test infrastructure on demand. Their use case is basically the ideal cloud use scenario. They've built a system of servers that enables them to do all of the things typically associated with clouds, which means they've built a cloud.
You're stuck thinking of TestingBot needing a bunch of servers, and seeing the tradeoff as dedicated servers vs cloud servers. In reality, it's TestingBot's customers who need a bunch of servers. So TestingBot built a cloud for their customers. They aren't setting aside N servers for each customer. They're building a cloud with the capacity for X servers and carving out of that on-demand.
Yes, EC2 is not a cloud for Amazon. If tomorrow everyone moves away from it, they will be stuck with many millions in sunk costs for hardware, rack space, datacenters, paid peerings.. they didn't rent that stuff by the hour. Feel free to replace Amazon with TestingBot in this description as you see fit, because right now you are confused as to what is a cloud to whom.
(Mind you, I'm still only discussing the financial side here, as this was the reason the original post cited. In technical terms, of course they are still a cloud, but so is the mainframe emulator on my Raspberry)
Somebody somewhere always has to pay for the infrastructure. I fail to see how the parent is confused between Amazon having infrastructure which they provide cloud services on, and TestingBot having infrastructure which they provide cloud services on. What's your point of distinction on the 'financial side' between the two exactly?
> The whole point of a cloud to a business is that you can adapt to changing needs without having to pay for all the infrastructure all the time.
The point of a cloud is that you can adapt to changing needs by reallocating resources based on demands. For a public cloud, that's exchanging money for more storage/compute capacity/etc. with near-zero latency. For a private cloud, its not adding total capacity, but reallocating between different uses on demand.
Having worked in large organizations still primarily concerned about allocating physical servers to tasks -- which, just like one with a private cloud, still keeps substantial excess capacity to accomodate changing needs --I can immediately see that being able to reallocate resources with minimal latency is valuable even if its from a fixed pool where increasing the total size of the pool has substantial latency.
That's a technical detail, not a financial one. Sure, you can save a few physical servers by being smarter in allocating load, but that is a far cry from the financial flexibility you get from e.g. EC2.
The whole point of a cloud to a business is that you can adapt to changing needs without having to pay for all the infrastructure all the time.
(You didn't think the suits talk about "the cloud" all the time because they fancy the technology, right?)