2 ms·

But cloud, because cloud and cloud cloud! We recently did the math on some cloud database solutions vs. warehousing data ourselves and using Glacier as a last-

by api 11y ago

But cloud, because cloud and cloud cloud! We recently did the math on some cloud database solutions vs. warehousing data ourselves and using Glacier as a last-resort backup. Turns out it's orders of magnitude cheaper to DIY and would remain so unless we needed -- as you say -- a whole lot of burstable compute. In that case we could always upload (or ship) all the data to the cloud if we wanted. Cloud is cheaper for some work loads and use cases but not others. You have to analyze your own problem and see what works best. What cloud vendors have managed to do is put a ton of marketing hype out there to the point that cloud has captured the entire discourse. Today if it's not cloud it's not cloud and that means it's not cloud, because cloud. I've heard many stories recently of companies spending 2-4X what they currently spend on IT to put it in the cloud in order to save money. It's hilarious.

spacecowboy_lon 11y ago
I saw this at RBI (part of reed Elsevier) I had to port a small system I built from linode to AWS and it was 10x the cost on AWS.
- api 11y ago
  But it was on AWS, so it was enterprise.
  - spacecowboy_lon 11y ago
    Ah the old spend millions out sourcing to save hundreds of thousands of internal budget.
vgt 11y ago
While there's arguments on both side for TCO of Cloud, I'll offer one idea - a solution like BigQuery is zero-Ops, lets you scale to thousands of cores in a second, and you pay per-second. This is both cheaper, faster, and easier to use, simply because it breaks many assumptions folks make when doing TCO comparisons: https://cloud.google.com/blog/big-data/2016/02/understanding-bigquerys-rapid-scaling-and-simple-pricing https://cloud.google.com/blog/big-data/2016/02/understanding...
- api 11y ago
  For our app the killer was storage costs. Of course our app is probably different from your app. For us we are doing real-time network testing and diagnostics of a bunch of distributed networks and dumping the data into a series of tables for analysis and diagnostic use. We can also use that data to improve our software in the long term. A lot of data is generated, but if we lose a little bit it won't kill us. The analytics we want to do right now are fairly consistent in terms of load. For this work load the cheapest option by far is to buy a RAID array and warehouse it locally. It can also be backed up very cheaply in Glacier so that if we do lose some we can get it back if we want it. But of course like I said our app is probably not like yours. My point was that you have to do the analysis for your exact specific problem to decide what approach -- cloud or not -- is the best fit.

by api 11y ago

spacecowboy_lon 11y ago

I saw this at RBI (part of reed Elsevier) I had to port a small system I built from linode to AWS and it was 10x the cost on AWS.

api 11y ago
But it was on AWS, so it was enterprise.
- spacecowboy_lon 11y ago
  Ah the old spend millions out sourcing to save hundreds of thousands of internal budget.

vgt 11y ago

While there's arguments on both side for TCO of Cloud, I'll offer one idea - a solution like BigQuery is zero-Ops, lets you scale to thousands of cores in a second, and you pay per-second. This is both cheaper, faster, and easier to use, simply because it breaks many assumptions folks make when doing TCO comparisons: https://cloud.google.com/blog/big-data/2016/02/understanding-bigquerys-rapid-scaling-and-simple-pricing https://cloud.google.com/blog/big-data/2016/02/understanding...

api 11y ago
For our app the killer was storage costs. Of course our app is probably different from your app. For us we are doing real-time network testing and diagnostics of a bunch of distributed networks and dumping the data into a series of tables for analysis and diagnostic use. We can also use that data to improve our software in the long term. A lot of data is generated, but if we lose a little bit it won't kill us. The analytics we want to do right now are fairly consistent in terms of load. For this work load the cheapest option by far is to buy a RAID array and warehouse it locally. It can also be backed up very cheaply in Glacier so that if we do lose some we can get it back if we want it. But of course like I said our app is probably not like yours. My point was that you have to do the analysis for your exact specific problem to decide what approach -- cloud or not -- is the best fit.