3 ms·
It is very difficult to have a company culture that optimized both for software and hardware. "Move fast and break things" doesn't work when you have to retool
by outworlder 8y ago
It is very difficult to have a company culture that optimized both for software and hardware.
"Move fast and break things" doesn't work when you have to retool your production line or throw away inventory, or call a supplier to request changes.
Conversely, hardware development processes tend to be too rigid and slow when applied to software.
It is very, very hard to get these working together even (and particularly) when they are two distinct groups in a company.
I have had to deal with 'firmware' updates on a VM. You know, the full "build and download a binary" thing from some website, upload to FTP, then login to a website and point to that FTP server, so the binary would be applied and the instance restarted.
No big deal, right? We do that sort of thing for OS upgrades, right? Except it wasn't an OS upgrade or actual firmware, it was updating the application running on that machine. The sort of thing that could be accomplished by an automated CD job, and a docker pull (or heck, apt-get update). All because the thing was an appliance. So it was lifted and shifted as-is and now "it's a cloud app, because it's on AWS!".
I have had to argue against authentication for a HTTP health check. "But if there is no authentication, people can spam the endpoint, and it's slow and returns a lot of data". Ok, first thing: it's not a public accessible endpoint. Second, I'm not interested in testing auth or taking the machine down when credentials expired. And third, if it is slow, then just return a HTTP 200 for me if it is ok, I don't care about anything else. "But if I just return 200, it doesn't mean the app is actually working". Ok, so go do the checks at whatever interval you want, and return the last run. "But this needs authentication, otherwise there could be a DOS, as the checks are slow." No you don't understand, they are supposed to be async... This went on and on for months. I finally got the health check.
... but then, now they want to log all packets to our centralized logging, so that they can count them. Dude, expose a metrics endpoint, Prometheus will call it periodically. "But there are too many messages, we can't hold all of these!" No, you give me a counter. Return the counter. "But counting messages is even slower". No... you increment the counter _as you receive them, not when I request_.
sigh
So anyway. Even when hardware is amazing, software development can lag behind. Or vice-versa.