It's not the value of the outcome for that job that you're interested, but rather its sensitivity to a delayed latency in executing it.
For example, preemptively converting Youtube videos to a lower resolution with optimum compression to avoid having to do it in real-time (when video is played) at a crappy compression (to be fast), is valuable for sure. It's just that it can be postponed for 24 hours without real impact. Executing a search for a single user is less valuable in terms of overall impact but much more latency-sensitive.
(you can think of value and latency-sensitive in terms of two dimensions that are independent between them.)
This idea helps save the planet for sure, but it requires cloud-providers to build APIs that enable devs to switch from the "here's the SSH to the server, do what you want with it" to a model where it's the devs that say instead "here's a lambda function and its desired latency execution, please schedule to run it for me and let me know when the result is ready" ( https://en.wikipedia.org/wiki/Inversion_of_control )
Google was able to do that because it owns a large part of the jobs executed in their datacenters. Hence they could build this adaptive scheduling for their own jobs quickly without necessarily passing through a cloud-based API that inverts the control of job scheduling.
As a customer I think you could configure somethings like you said using spot instances on AWS but that’s it, you’re going to save some small amount of dollars in a year but if you account for the engineering hours needed to set this up maybe is not really worth it.
As a cloud provider you could juggle your client between datacenters depending on the load and price of energy over there. A flat rate for a cloud region means that there’s an opportunity for arbitration between datacenters that could be an increase of thousands in profits on their side.
If the cloud provider becomes aware of the remaining latency you have at your disposal for the job's execution, they can do a much better job. They would be able to look across the entire job execution queue in that datacenter, each job having a specific remaining duration for its execution, they would know the predicted pattern of carbon/solar/wind split for the next hours, and the implementation of the system would sit just on the cloud provider side (making the life of the customers easier and simple).
Of course, in the end, the benefit is towards our planet, but this is much more likely to succeed if the proper cloud API exists and the implementation initiatives are properly aligned to avoid redundant implementations on the customer side.
So in that case, optimizing for a single customer makes perfect sense if it's the right customer.
The future doesn't always need to be as "webscale" as Google; sometimes, scaling down is the smart thing to do. The minimal approach of LTM is the technology equivalent of riding a bicycle (or electric velomobile [1]) to work instead of driving.
[0]: https://solar.lowtechmagazine.com
[1]: https://solar.lowtechmagazine.com/2012/10/electric-velomobil...
LTM's approach required producing, assembling and shipping a full 2GHz/1GB computer, plus PV, PV-controller and router, all to serve a single site. And it's even turned off some of the time!
Google, on the other hand, is more like a fleet of trains; sure, each one is a honkin' beast, but it also transports thousands of passengers/sites at once, possibly millions in its lifetime.
The bicycle analogy doesn't really work, because a bicycle is just a performance attachment to the real vehicle: the human.
This way you can have 24/7 fully green content delivery to consumers.
Although that being said we could just try to cover the earth with as many generators everywhere and then fully connect the grids.
This is the easier route: you do this by having as many businesses as possible purchase renewables PPAs, where they're specifically contracting for renewable energy.
https://www.utilitydive.com/news/as-corporate-renewable-buyi...
But CPUs have an incredibly high embodied energy, we should aim for full utilization of servers, regardless of the source of that energy.
If it's three CPUs with carbon-neutral electricity, or one CPU with electricity from coal, the latter is the responsible choice.
If no, then why. I can explain my confusion if needed.
To be fair, these are artificial choices, and that's not even what lowtech was doing (they have a battery). I was responding to the post about the CDNs that stop working at night.
Their DCs are globally distributed, so their timings on when they'd actually be doing the heavy lifting is shuffled around.
I guess it's okay as long as the people making the rules have good monitoring and are watching out for weird exploits and fixing them. The flexibility to change the rules tends to be more common internally than externally where customers want more guarantees.
As we've seen, there also needs to be a balance between cost-optimization and preparedness. If the wind patterns don't match the prediction then you need to be ready for that.
Also, as we've seen with cryptocurrency, real money attracts theft. A human-adjusted credit system is better. In the real world, this looks like support having the discretion to forgive big bills. But to do that they need to know their customers. It's hard to automate.
Our hypothesis is that market signals combined with the right tools (friendly app and home automation) can help households shift demand into less carbon intensive periods.
So far it's working pretty well.
It would also be pretty neat to integrate processing power markets with the wholesale energy markets. Energy prices are quite volatile and making load responsive to that would actually be quite helpful to stabilize them.
I've wanted to have realtime pricing like that for a while, it seems to be becoming available again.
I honestly thought that was what the advanced electricity meter roll-out was going to do; but it seems not.
More direct energy cost to service price charged seems like a good thing in general.
It's goofy, but another one is situations where you have a lot of stored heat energy, thinking like pools, hot tubs, hot water heaters, etc— all those things could be activated in response to spot pricing with pretty simple policies (I want a shower of at least X degrees at 7am, I want the hot tub at at least Y degrees by 9pm, etc).
With renewables the incentives for load management become even higher (per this article). The real next step after second-by-second billing would be setting up chargers with backfeeding capabilities/policies, so that you have an arrangement with your employer to charge your car at work on cheap daytime solar power, sell it back into the grid during the evening rush, then charge up again on overnight base load. Most EV batteries are way overspecced for what people need in daily use, so as long as you have a special "charge me to full and stay there" mode you can switch into, there'd be no reason (other than a bit of wear and tear) not to cycle your battery like this.
But for me as a customer, the price was as high as allways.
But if customers could react to that (automatically), you could have all sorts of jobs waiting for it. Bitcoin mining, dryer, charging batteries, freezer full power ... would be good for the grid, too, to balance it.
Texas energy markets are where all the fun on this front is really happening.
One way to do it would be assign various jobs a value, (which could be dynamic e.g. it might get more important as information becomes stale) and have them bid on compute power. You could make the value virtual.
Or you could use real money. This is the premise behind EC2's spot instances. So when power is abundant, your prices drop and the relevant jobs kick off.
Using real market prices makes sense especially if you're renting out computing power, most customers will be happy to adjust workloads to save money.
Even if it's entirely internal, it's good to have a facility to "optimize for cost" and then report the savings. That's helpful to get the engineering resources devoted towards it, because "I saved $X" is a great bullet point to put in anyone's promotion packet or to base a bonus on.