Hacker News new | ask | show | jobs
by hjhffyuu57 1012 days ago
It would be interesting to see what the corresponding figures are like for on-prem, although they would be much more difficult to calculate and would vary wildly between companies.

The only thing that really stood out to me was the Google storage price increase, which seems rather large, as in way out of line in comparison to our 2023 spend and 2024 budgeting.

It would also be nice to see what exactly is meant by SaaS vs presumably IaaS. I.e. would Amazon Glacier (random selection since we've been comparing the pricing with tape recently) fall under their definition of SaaS.

5 comments

Storage prices depend on the reliability you want.

Someone like Google cannot ever lose data of any customer. So if you pay for 1GB of storage, they probably actually store 5GB of data or more for you. It will be redundantly stored within the datacenter across different racks, but also stored (also redundantly) in different datacenters in case of flood/fire. Theres probably a copy on tape incase of a catastrophic software bug that wipes all the drives. Or two copies on tape because if there were a software bug that wiped all the drives, the chances that every single tape was readable for a restore is low - so more redundancy needed.

However, if you go for a smaller player, they probably still keep multiple copies of your data, but it might be a RAID-5 -like setup, requiring only 1.3GB of storage for each GB you store with them. It can survive a drive failure, but two drive failures or a datacenter fire or an engineer fat-fingering an erase-all command and your data is all gone.

Thats (part of) why the big players charge so much for storage. I actually wish I could choose less reliable yet far cheaper storage option with a big player, but they don't want to offer that because of the PR hit when they do lose customer data.

That makes sense and is a factor in our calculations, we store everything at least twice (as in RAID + actual copies not including tape off-site results in ~ 2GB stored for every GB), with at least a third replicated to DR off site backup. That explains the on paper per-GB price difference (which we would expect to be more expensive in the cloud, the main advantage being that we don't have to coordinate all of that, so there are areas where we would save, its just very difficult to do a price comparison given we don't know the details of their system).

It doesn't explain a huge percentage increase though. Presumably they (Google) were already doing due diligence there with respect to reliability.

Essentially agreeing with you on all those points though. Especially the bit about the PR hit. It's a constant factor in our budgeting with the understanding that if you "lose the backups", you are probably out of a job.

> So if you pay for 1GB of storage, they probably actually store 5GB of data or more for you

The actual factor is most likely around 1.4-1.5x and for sure can’t be any more than 2.2x in this day and age. Dumbest possible implementation will be “only” 3x so no it’s nowhere close to 5gb

Edit: looks like it’s public so i can actually tell you that google uses RS 3,2 which gives 1.5 replication factor. When i was there a few years ago storage folks told me they never lost a single stripe of data

Those numbers are for Colossus. Blobstore, which backs the cloud object store, is different, and used to be a lot higher.
Yeah those aren’t public afaik, iirc they adjusted replication for cold data
Presumably Google also keeps backups, though, right?
And mirrors to at least one extra datacenter as they can lose bandwidth with a fiber getting cut, become unreachable due to networking snafu, or even burn down entirely.
Yes they also store to tape
That means 2X at a minimum. Then RAID overhead. Possibly other hot or warm copies ready to take over instantly.
And tape costs same as ssd/spindles in your calculations?
A common problem would be throughput though. Storage capacity scales much faster than access speed. If you are storing an item only 3 times and lets say each storage location gives you 50,000 IOPS max then you can only ever service 150,000 IOPS of this item which might not be enough.
Vast majority of data rarely (if ever) gets read so you use a cache for that
What does RS 3,2 stand for? Thanks
Reed-Solomon erasure coding. 2 data blocks, one parity. Basically raid-6 but distributed
But thats within one cell... But data will be stored in more than one cell to deal with scheduled and unscheduled downtime of the cell...
You have pay more for that
Not with GCS, you don't.

https://cloud.google.com/storage/docs/availability-durabilit...

Are you thinking of Persistent Disk (PD) and Replicated PD?

(I work on storage at Google.)

I was thinking of gcp regions in which case you do have to pay for it. For colossus cells within a single regions you obviously don't but I don't know enough how it maps it out down there and whether it just moves data around in the event of PCR
I did a detailed price cost calculation of onprem vs AWS as I worked at a MSP. Our cost of compute and storage including DC construction over 10y was about half the cost of AWS.

We also used cheap supermicro and had no service contracts or warranties we had on site staff. Their salaries were included.

Small DC 2mw.

I think Cloud has never been a question of costs — it’s generally about not having to become operational experts in house and maintain that expertise as it’s not a core business function (hard for SMEs for example, to retain talent outside of overhaul and project cycles), overall desire by senior management to single source vendor management, and a “throat to choke” that keeps you from losing your job if problems arise.

These are the drivers I’ve seen, with cost a distant third, fourth or fifth. Can’t wait to see what happens this economic cycle.

The infrastructure the simplest little offering on a modern data center is so immense that honestly it’s a good deal often. If you’re a small-midsize company what’ll you do - put a bunch of computers in the office closet and get what uptime and latency?
Pretty good uptime and exactly the same latency (CDNs != cloud, and that's where most latency is handled). Not 99.9%, which is the big selling point of clouds... as long as you forget about all the times that their complex infrastructure collapses on itself and loses you that third 9.
Thanks for this insight. It’s a perspective I don’t have. Did you build the site? Is it performing as expected?

I know “nobody got fired for choosing AWS” but the real value seems to be in burst loads. If you have predictable, stable workloads I can see on prem or hybrid making more sense.

So long as stable also means "unchanging" (in the sense of no new machines are being deployed). Our biggest win from AWS was never having to think about DDoS; our second biggest win was never having to wait for our Ops team (who was very good overall) to have the discussions about how to deploy new hardware, new storage, etc.

I get annoyed when a new EC2 instance takes 2 minutes to launch now. That time used to be not productive to measure in hours.

Yes the benefit of the cloud is the ability to change deployed capacity quickly.
We also need to bear in mind that SaaS vs On Prem also often implies 'subscription' licensing vs perpetual software licensing (one off + support payments).

If a SaaS product is $100k per year (subscription) the equivalent perpetual license cost is probably $200k (one off) + $40k annual maintenance (my very rough rule of thumb after doing lots of tenders - a perpetual license is usually two years of the subscription fee plus 20% of the perpetual license cost as support fees).

If you can afford to build a data center and know you have that fixed amount of capacity for 10y then you’re not talking about 99.99% of businesses. For everyone else the cloud is cheaper. In fact, to your customers, you are the cloud, so I’m not sure what you are arguing.
I don't think they're arguing anything.

The parent wondered:

> It would be interesting to see what the corresponding figures are like for on-prem

They replied. Not everything is an argument.

Also, they didn't say anything about fixed capacity - they're likely just talking about 10Y deprecation which is a very common accounting thing to use - and "For everyone else the cloud is cheaper" is definitely not true. It depends on workload and architecture. If you're in the business of selling infrastructure, for example, using the cloud will eat most of your margins (this is not to say that it's not done, but usually there's some caveats, e.g. maybe you will get some cheap VMs provisioned and do your own fleet management ontop instead of building everything on top of say, firebase or dynamodb).

Thanks this was helpful, somewhat in line with the numbers we've been throwing around.
> It would be interesting to see what the corresponding figures are like for on-prem […]

You won't find any, not easily anyway. The world of enterprise SaaS follows a different business model that I refer to as «hiding the dead horse in the cloud» and holding the customer to ransom.

The premise: the customer is already locked into the wares the vendor supplies, and the customer can't easily migrate away from the product. Oftentimes, the product is also ridden with the technical debt, but it either has a feature critical to the business or there are multiple business (and technical) processes that have a deeply ingrained reliance on the product. It is either the data or the integration with the product. Regularly both.

The vendor repackages the product («the dead horse») as a SaaS, rolls it out into the cloud (the act of hiding the said dead horse), bumps prices up and slips the bill under the customer's front door (the ransom). Cloud costs are passed onto the customer at a markup. The product (and sometimes the customer) might get minor tangible benefits from the repackaged version, e.g. improved availability and reliability, although even that is not always the case. SaaS products typically do not use native cloud services, they run on EC2 instances (or their equivalent in Azure, less often GCP) and are cobbled together just enough to make them not fall apart.

SaaS, as a business model, is not about the engineering excellence most of the time. It is about squeezing the last drop of blood that there is left in a legacy product, now being offered as a shiny-shiny SaaS version («hey, lookie, we are also int the cloud!»). This is the reality.

The theory is somewhat different. In between 2000s and 2020 (approximately), vendors used to tailor their products to specific needs of each specific customer which increasingly became difficult to maintain, update and upgrade as there would be no single product titled «ABC», there would a «ABC customised/hand-rolled for customer 123», «ABC customised/hand-rolled for customer 456» and so forth. So the original premise of SaaS was to have a single version of the product for ALL customers that exposes simple data centric and whatever other technical interfaces that the customer would hook into. The enterprise world does not work that way, though.

There are positive exceptions in the world of SaaS, and almost all of them are in the startup universe and outside the enterprise.

Terms like SaaS, IaaS, PaaS are pretty fluid outside of specific contexts.
GCS launched as an S3 competitor (with an S3 compatible API). So their pricing was basically copy pasted from S3.

From the start though they offered more expensive to run features (a consistent list api, 1GBit transfer per file vs 100mbit for S3 at the time, Glacier-like storage with instant retrieval).

I think this pricing jump is mostly pricing it at what it always should have been. Plus a bit of the now being so focused on enterprises that the list price means less and its all about "call sales for more information".

S3 has built most of those features since then though, without a price increase.