4 ms·

We came across this time and time again, even when the procuring team was "an ops team". Our solution was to automate the boilerplate stuff, like the NICs, PSUs

by balex 4y ago

We came across this time and time again, even when the procuring team was "an ops team". Our solution was to automate the boilerplate stuff, like the NICs, PSUs, etc. So the order would focus on the compute and IO stuff (though they often struggled with RAID controllers too). We were thinking of switching to a "how much capacity and iops do you need?" method and breaking that down to spec automatically. Or even a "give me a baseline server and a performance multiplier per capacity, read/write, etc". In case they didn't know the actual numbers. Not sure if it would hold?

easytiger 4y ago
Every business case is different (as in the software requirements of the software that supports the business). Alas tricky to determine without analysing how much software they want to run. Not everything is small pieces of scalable n instances s/w.
toast0 4y ago
It really depends on your organization what you can do there. You can go a long way with a menu of servers, pretty limited customization, and an exception process for customization that's really needed. Some places don't want to do any customization, and that can work as long as the menu is reasonable, and you're OK with the consequences: when loads need more CPU, but not more RAM, they'll get more nodes and have underused ram; when they need more RAM, but not more CPU, they'll get more nodes and have underused CPU. Maybe you can build some sort of scheduling system and make use of those pockets of underuse; maybe you can just deal with it, because standardization saves enough effort (and maybe money) to pay for the underuse; maybe you have a pretty large menu and teams can find a good fit. Exceptions could be some specific use cases can customize, or maybe you can add something to the menu if it will save $X or be an order of N nodes. If you can measure existing loads and suggest hardware based on that, that's way more useful IMHO than having teams tell you their iops (cause teams are just going to make wild guesses about their loads anyway)

by balex 4y ago

easytiger 4y ago

Every business case is different (as in the software requirements of the software that supports the business). Alas tricky to determine without analysing how much software they want to run. Not everything is small pieces of scalable n instances s/w.

toast0 4y ago

It really depends on your organization what you can do there. You can go a long way with a menu of servers, pretty limited customization, and an exception process for customization that's really needed. Some places don't want to do any customization, and that can work as long as the menu is reasonable, and you're OK with the consequences: when loads need more CPU, but not more RAM, they'll get more nodes and have underused ram; when they need more RAM, but not more CPU, they'll get more nodes and have underused CPU. Maybe you can build some sort of scheduling system and make use of those pockets of underuse; maybe you can just deal with it, because standardization saves enough effort (and maybe money) to pay for the underuse; maybe you have a pretty large menu and teams can find a good fit. Exceptions could be some specific use cases can customize, or maybe you can add something to the menu if it will save $X or be an order of N nodes. If you can measure existing loads and suggest hardware based on that, that's way more useful IMHO than having teams tell you their iops (cause teams are just going to make wild guesses about their loads anyway)