5 ms·
Sure that makes a lot of sense, I'm sorry for my bad assumptions, but that drives my point home even more. The problem is not related directly to your performan
by xupybd 4y ago
Sure that makes a lot of sense, I'm sorry for my bad assumptions, but that drives my point home even more. The problem is not related directly to your performance on the hardware. It's an additional cost from the business environment. License costs can drastically alter where your efforts are best spent. I'd imagine there are times where you might be better off pulling huge chunks of data out of the database to process on machines that don't have such a big license cost.
CPU cycles are cheap, SQL Server licenses are extortionately expensive. While the costs are tied to the server they run on if you can offload to a different CPU not tied to that license model you can still take advantage of the low cost of CPU cycles.
- jiggawatts 4y ago> CPU cycles are cheap But people aren't. Any code that "makes people wait" is wasting people's time. The only way to make code take less time is to optimise it, because capacity != latency. You can't get a 20 THz processor. You can buy more capacity, but you can't buy more speed! At FAANG scale, it's common to hire "top" developers at hugely expensive annual total comp to tune stdlib code like "string" for just 1-2% efficiency gains because at their scale that might be 1,000 to 10,000 fewer servers. At a small scale, budgets are tight. At "enterprise" scale, staffing (user) costs are high, and license costs are high. I can't think of a typical business scenario where compute and/or associated per-core-licensing costs can be blindly disregarded with a flippant statement like "developers are expensive and infrastructure is cheap".
- xupybd 4y ago>I can't think of a typical business scenario where compute and/or associated per-core-licensing costs can be blindly disregarded with a flippant statement like "developers are expensive and infrastructure is cheap". Say you're a small business with an in house server rack. Not a software company but say a manufacturing business. Not enterprise scale, smaller. You have 1 development resource. It turns out the ETL server is overloaded and it's causing the reports that run on the same server to run slow. You could get the developer to spend a few weeks porting the legacy system to faster modern option to speed up the ETL and maybe improving some of the reports. But it would be far cheaper to buy in another server for $3k and have the developer spend less than half a day moving the ETL onto the fresh server.
- jiggawatts 4y ago> moving the ETL onto the fresh server. On which... it'll run at maybe 20% faster, because that's the scale of single-threaded processor speed improvements these days. Not to mention that now there's a network hop involved, which will eat into any CPU gains. Very few apps scale well with increasing core counts, and then hit a wall around 64 cores for almost everything. Okay, okay, fine. The ETL is natively parallel code and somehow, magically, it can read inherently sequential file formats like multi-gigabyte CSV or JSON files in parallel. This tiny org already has 10 gigabit switches, SFPs, and everything. Did you upgrade the database server too? No? Now the shiny new ETL server is twiddling its thumbs while the database server is getting overloaded. Suddenly this option is "not so cheap". You have to buy a new database server and... uh-oh... it's Microsoft SQL Server, Oracle, or SAP HANA, and the licensing is going to eat half your tiny little company's profits for the year. Did you forget the OS license, backup agent license, anti-malware license, and so on? I bet you did. All of those are extra, and either per-machine or per-core. Someone has to set this all up. Small non-IT shops typically outsource this to an IT service company. They'll explain all the extras that turn a $3K purchase into a $30K purchase (including on-site assistance to install everything). Or that 1 guy could have just taken a 10 minute look at the ETL logs, discovered that "SELECT * FROM HugeTable" is unnecessary, and fixed the problem.
- xupybd 4y agoThat's a totally different scenario. Imagine it's all Linux no back up required and the database server has lots of capacity. The lone developer can do it in half a day. No extra cost. But yes there exist situations where that is no possible. This is just one example of where it is
- mtrower 4y agoDon't forget your electricity costs, A/C costs, hardware maintenance costs... these are often overlooked, but are not nothing. You've added permanent recurring expenses to avoid your one-time developer fee. Yes, sometimes this might make sense --- if the dev fees are going to be exorbitant, or if you just can't afford to pull a dev off a project to work on it. Other times, it makes more sense to pay the dev... You keep saying, CPU cycles are cheaper than developer hours, but this is nonsensical without quantities attached to each. How many CPU cycles, on what kind of machines? How many cycles do those machines have to spare? What's the performance per watt? How many developer hours at what kind of salary? There's way too much missing info to be making such a statement.