The article seems to forget that calling a module "hardware" doesn't mean there's no CPU on that "hardware" with software running on top of it. Same goes for D

The article seems to forget that calling a module "hardware" doesn't mean there's no CPU on that "hardware" with software running on top of it. Same goes for DPUs, which are essentially just single-board computers. The datacenter OS has been done, many times, and the only incarnation that has had long-term success was the mainframe for a rather un-diverse set of tasks (record processing as banks, tax offices and insurance companies are doing). The problems so far have always been the same: a triangle of cost, performance and flexibility where you get to pick two if you are lucky, but with most of those 'mega systems' you really only get to pick one. What has been a true improvement over the last two decades is the commoditisation of hardware, the scheduling of tasks and services (think in terms of container schedulers and even task schedulers) over that commodified hardware, and much more recently: the improvements in hardware-assisted parallel computing (which includes machine learning and the recent shuffling of FPGA IP). The reason those have been an improvement is because they aren't vendor-locked, they don't have to be homogenous and they are flexible enough that once you meet the bar where you really need it, you can start out and grow and shrink practically on-demand. (and I'm not talking about 'the cloud' here, but about the size of what scheduling and parallel computing facilities you might need) More true to the title of the article: datacenter software has fallen because it's the old "buy a license, a support contract and install an instance" model which drives silo'ed technical design. It used to be true that to perform a task at a specified performance a specialised silo to perform that task was required to be able to fulfil a business need at all (think network frame and packet processing). Up to a point, that has been generified and commodified so much that before your baseline performance requirements need you to get a highly specialised silo'ed system/device/appliance, you've already outgrown the 'do it yourself' scenario. (scale: think about one corridor/double row of 48U) At that stage you'll either be offloading to an elastic capacity provider or are in such a niche scenario that common rules don't apply anyway.