No bare metal. Well that node is. Most of it is Hyper-V or EKS. Aware of that one, perhaps unfortunately. The onion skin of context switching and bloated multiple kernels causes havoc particuarly on the fucked up mess that is Intel virtualization. Had serious problems with on ESX a few years back with things just hanging solid particularly when VMotion decided to move the hot nodes around while they were shitting a brick. You're only getting partial core resourcing and having to share L1/L2 cache heavily leading to high cache miss, escalating load and then deadlock. Ugh.
I'm not a proponent of virtualization. Processes are enough virtualization for anyone who hasn't fucked up ![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
We need sandboxes in our containers in our VM's to fix the same problem thrice. Turtles all the way down, baby.
Ditto asynchronous comms protocols on top of synchronous comms protocols on top of async on top of sync (repeat ad nauseum/infinitum/cretinum as appropriate).
Ditto addresses/identifiers.
I came to the conclusion that a good starting point for assessing any software design was to ask "what is an address/identifier in your system, and what are their scope and lifetime?". The amount of weebling/bumbling that provoked gave a good idea of the design (in)competence.
Similarly for any software
or hardware system, asking for the definition of clock/time domains and how the boundaries are crossed, could be enlightening. Sometimes the light came on in the other person's skull, but usually it was darkness and defensive invective.