2 ms·
But how many engineering-hours would be needed to optimise it to fit into a single server? And what would the risk be that there is a screw up? Sure there migh
by mattlondon 6y ago
But how many engineering-hours would be needed to optimise it to fit into a single server? And what would the risk be that there is a screw up? Sure there might be a few low hanging things to clean up ( i.e. a few places where a data structure could be better picked), but if it needs that much iron then it is probably not a trivial refactor of a few hotspots, but likely a more extensive rewrite.
Probably cheaper to just pay 250k than for a couple of engineers taking risks modifying a battle tested bit of code... If it is important enough for the business to justify paying that much for then you'll need to "do things properly" and not do a hatchet-job of a cowboy refactor, but plan things out and test them and have rollout/rollback plans, project management etc.
- lmilcin 6y agoOptimisation is typically one time cost. You make a feature A and you spend a bit more time to ensure it works couple times faster or couple times less resources than initial/naive version. Maintaining larger infrastructure is an ongoing cost as you need to provide x times more resources throughout the life of the application. Not only that, but now future development will have to be done in context of large application. Maybe writing a process for a single node could be easy and now you have 100 nodes and it is complex to design your functionality to work correctly on multiple nodes, complex to deploy, complex to resolve issues. Maybe you decide to employ new technology to solve some of those problems but at the cost of creating other problems and also additional complexity. Then maybe you need more people -- and this comes with its own inefficiency. The point really is, most applications could be orders of magnitude more efficient if you just don't make stupid decisions.