[0]: https://cloud.google.com/compute/docs/sustained-use-discount...
Running 2x 4cpu instances for 1 month is the same as 4x 2cpu instances for 1 month, and will come out the same even if you switch in the middle.
(Note: I have no investment in the company)
Without wishing to be too promotional, you can set a trigger to shut off EC2 when a cost threshold is reached. You can currently automate shut off of RDS but not yet from a cost threshold (that will be available shortly).
TLDR: we can do a lot of what you ask but not all of it.
Feel free to reach out if you'd like more info.
The exception is Google Compute has a 10 minute minimum, so if you are creating machines and destroying them quickly, per second billing will be noticeable.
That all being said, it can enable a bunch of interesting things (e.g. more interesting stuff with AWS Lambda), and I look forward to see what per-second billing becomes an enabling technology for.
Azure looks to be per-hour [Edit: Wrong again, they are per-minute as well. Oddly enough, I did check their pricing page before, but missed the per-minute paragraph and only saw the hourly pricing] but I'm seeing something about container instances possibly being per-second.
Azure's containers don't use a full VM-- they're more like AWS Lambda or other serverless frameworks, so they do per-second billing with no minimums.
Disclaimer: I work at Google on Container Engine.
[0] - https://azure.microsoft.com/en-us/services/virtual-machines/
"Keep your budget in check with low-cost, per-minute billing. You only pay for the compute time you use."
I really want to use them to parallelise CI test runs, but haven't gotten round to setting this up yet.
Per-second billing greatly reduces the overhead to bringing up an instance for a short task then killing it immediately - so I can do that. There's no need to build a buffer layer to add workers to a pool and leave them in the pool, so that you didn't end up paying for 30 hours of instance time to run 30, two-minute tasks within an hour.
This is certainly a long time coming.
Years ago my boss at the time did this (this was when scaling had to mostly be done in code/by hand). I just recently updated all the code as I moved it to using spots. The low price of spots made it less important to shut ones down closer to the hour mark though.
Also, is the economic incentive really that huge? Or is it just a nicety?
AWS batch currently does this. I presume that will change now.
I really hope Amazon build something like Azure Container Instances [1], as per second billing would make this sort of thing feasible.
[1] https://azure.microsoft.com/en-us/services/container-instanc...
To make the most of per-second billing, the compute unit should be deployed within seconds, e.g. immutable. prebaked container. You launch containers on demand, and pay by seconds.
It's now possible to boot operating systems in milliseconds and have them carry out a task (for example respond to a web request) and disappear again. Trouble is the clouds (AWS, Google, Azure, Digital Ocean) do not have the ability to support such fast OS boot times. Per second billing is a step in the right direction but needs to go further to millisecond billing, and clouds need to support millisecond boot times.
The lifetime of a web request, for example, can be measured in milliseconds.
It is now possible, technically anyway, for operating systems to boot, service the request and disappear.
There needs to be pricing models that reflect computing models like this.
The applications are "whatever you want imagine" but yes one application is building FAAS Function As A Service in which the operating system carries out a single function.
Put anther way, Docker is complex, overweight, and requires re-implementation of much computing infrastructure. You can meet many of the same goals as Docker in much more simple way not by building containers but by building tiny operating systems.
What would be interesting is if they had exactly the same upvotes and comments.
