The Case For Software-Defined Power
Intelligent power reporting vs. intelligent power delivery.
For those who know me, I have long stated that waste is abundant when it comes to power and provisioning in data centers as the IT load capabilities for failover and self-healing are rarely examined or included in the power supply design. Data center floors get power capacity based on predicted compute power needs that are allocated to each rack and then duplicated for redundancy and failure (in most cases). Redundant power rarely gets used. In fact, most hope it never does! In some cases, the backup power is via UPS and generators, renewables, fuel cells, or another diversely routed power feed. None of which are cheap. The problem is that facilities design ignores the failover mechanisms built into the software.
If a single software program fails over to multiple servers in multiple locations, do all of those locations need full redundancy of all power systems? If a single application can go down with minimal to no business impact, does it also need to reside on fully redundant servers with dual power, dual network (with dual power), and dual storage (with dual power) connections? The answer is no, but we still design power as if they do. Much of the power resources remain unused, expensive, standby assets. As applications move to the cloud or are retired, how do you reclaim that power? Does every business have a great commissioning/decommissioning plan and a business strategy to balance consumed energy to risk? Enter software-defined power (SDP).
Today, the data center is quite different than the data center of yore. Colocation data centers are built with the mind to supply dual power to every resource. It is simply easier to plan and sell but can be immensely wasteful. Hyperscale and cloud providers, of course, throw in redundant everything and are designed with the concept that everything will fail. Enterprise private data centers in some cases embrace various layers of risk-based power, but in most cases, just follow standard accepted practices of dual everything except for some smaller “run to fail” scenarios. Dual everything, in large part, is due to the engineering community that has been trained to create redundant facilities as IT is not in their purview.