3 ms·

Is looking at current running costs the only metric? Computer co2 emissions are dominated by manufacture, not use. At some point the extra bloat means you hav

Is looking at current running costs the only metric? Computer co2 emissions are dominated by manufacture, not use. At some point the extra bloat means you have to upgrade your computer / buy another one.

vidarh 3y ago
The point is that for a lot of services that "at some point" never come, and/or favors avoiding "extra bloat" in the development team rather than production servers. By all means, assess the costs and benefits - I've done projects where I've optimized heavily for performance because it means we could shave tiny amounts of power use off embedded systems we hoped to deploy in large quantities; I'd certainly not deploy Ruby there. But people seem to have a tendency to overestimate the scale they will need, often dramatically, and often because they have no idea the size of their total addressable market or the amount of data available in a given space (e.g. I've seen developers worry about scaling things to large clusters in niches where actually talking it through with a business analyst would've made them realize that a total saturation of the product to 100% of the maximally possible worldwide market for their service would see it all fit on their laptop) Unless you actually sit down and work out what your realistic scaling scenarios look like, you don't know whether a tradeoff of time vs. performance will ever pay off. Even when you do need a scale where putting significant effort into performance matters, there are many scenarios where starting "inefficient" is still more efficient, because it lets you focus more effort on the parts of the system that are proven in real-world settings to actually carry a cost that matters, and the most cost-effective solutions might well be different than what you expect. E.g. one other aspect of the system that included the Ruby component I mentioned actually hit scaling challenges. Instead of investing time in rewriting it, we cut the computational cost to fractions of a percent by just caching the main pages for a few seconds (I want to say 10, but not sure the exact number). The total energy use for generating those pages once that cache was in place (reconfiguring the reverse proxy that was already in place) was so low that rewriting that part in a more efficient language would equally have saved at most fractions of a core. Instead of spending extra dev time on that, we got to spend the extra dev resources where it did matter, such as e.g. the backend search engine indexing and query engine, where processing costs certainly would have killed us if it'd been written in a slow language. Basically, know your costs. Your fully loaded, real costs, including the actual dev costs by service and by feature. Developers in particular tend to have absolutely no clue about the fully loaded costs of the choices they make, and it often shows in the choices they make. EDIT: I'd like to add that this is often not the fault of developers. It took years, and very specific circumstances (co-founding startups, that exposed me much more to the money side) before I started seriously thinking about the costs of what I built, and sitting down and actually calculating "worst case" scale and likely scale, and estimating costs of going from one to the other if we engineered for the smaller scale. It's not a habit most developers have, because it's not something most developers get asked, even though they ought to at the very least be involved (a lot of the time I've seen costing done by architects, or even worse directors or VPs with no exposure to the hands on work, it bears little resemblance to reality).

vidarh 3y ago

The point is that for a lot of services that "at some point" never come, and/or favors avoiding "extra bloat" in the development team rather than production servers. By all means, assess the costs and benefits - I've done projects where I've optimized heavily for performance because it means we could shave tiny amounts of power use off embedded systems we hoped to deploy in large quantities; I'd certainly not deploy Ruby there. But people seem to have a tendency to overestimate the scale they will need, often dramatically, and often because they have no idea the size of their total addressable market or the amount of data available in a given space (e.g. I've seen developers worry about scaling things to large clusters in niches where actually talking it through with a business analyst would've made them realize that a total saturation of the product to 100% of the maximally possible worldwide market for their service would see it all fit on their laptop) Unless you actually sit down and work out what your realistic scaling scenarios look like, you don't know whether a tradeoff of time vs. performance will ever pay off. Even when you do need a scale where putting significant effort into performance matters, there are many scenarios where starting "inefficient" is still more efficient, because it lets you focus more effort on the parts of the system that are proven in real-world settings to actually carry a cost that matters, and the most cost-effective solutions might well be different than what you expect. E.g. one other aspect of the system that included the Ruby component I mentioned actually hit scaling challenges. Instead of investing time in rewriting it, we cut the computational cost to fractions of a percent by just caching the main pages for a few seconds (I want to say 10, but not sure the exact number). The total energy use for generating those pages once that cache was in place (reconfiguring the reverse proxy that was already in place) was so low that rewriting that part in a more efficient language would equally have saved at most fractions of a core. Instead of spending extra dev time on that, we got to spend the extra dev resources where it did matter, such as e.g. the backend search engine indexing and query engine, where processing costs certainly would have killed us if it'd been written in a slow language. Basically, know your costs. Your fully loaded, real costs, including the actual dev costs by service and by feature. Developers in particular tend to have absolutely no clue about the fully loaded costs of the choices they make, and it often shows in the choices they make. EDIT: I'd like to add that this is often not the fault of developers. It took years, and very specific circumstances (co-founding startups, that exposed me much more to the money side) before I started seriously thinking about the costs of what I built, and sitting down and actually calculating "worst case" scale and likely scale, and estimating costs of going from one to the other if we engineered for the smaller scale. It's not a habit most developers have, because it's not something most developers get asked, even though they ought to at the very least be involved (a lot of the time I've seen costing done by architects, or even worse directors or VPs with no exposure to the hands on work, it bears little resemblance to reality).