The previous responses to this comment are spot on. I would add two things:
(1) When you write an app that relies on a cloud service and your app has trouble, you have to make the choice to either dig into your app or call the cloud vendor for help. If you make the wrong choice, you lose precious time in the resolution process. This data makes that triage process simple. If your indicators and the GCP service's indicators go bad at the same time, call Google. If the Google indicators look good and yours are struggling, look at your app.
(2) When you do call tech support from a service provider, there is often some back and forth to show that it is the service provider that is causing the issue. With this data, that back and forth goes way down. Show them the chart that illustrates the Google service level drop and everyone agrees on the data and support can jump right on the issue.
One can object saying, "Shouldn't the cloud vendor already know that there is a problem and just fix it and let me know?" That is true for the infrequent big things. But, for the smaller, but more frequent issues, there is a specific issue for some method in some service for some customers in some region, etc... When that happens, the few customers who are hit by that issue can have a hard time knowing it's happening because it does not show on the global dashboard and then have a hard time getting tech support to see that this is really a change in service for them. This data solves those issues.
Cloud Harmony has done some more testing since then which covers some more configurations and you will see Google does quite well - especially if you normalize by price (not in the charts, but prices are public)
Disclaimer: I work for Google as the product manager for Persistent Disk.
I suspect that what crb is referring to is the ratio of 30 IOPS/GB being the top ratio that could be bought and what that would cost on a per GB basis. I don't think crb was suggesting a 1 GB volume.
As for the specific case you describe - looking for 30 IOPS consistently on a 50 GB volume, with Google, there is no need to go to SSD for that or to pay $16.25/month.
- If you meant 30 random reads, you can hit that with 100GB of Standard PD for $4.00/month (with no IO charges)
- If you meant 30 random writes, it's less as 50 GB gets you 75 random write IOPS for $2.00/month (with no IO charges)
At Google, we've tried to bring consistency of performance even to the lower tier of block storage so no matter what level of IO you need, you can count on seeing a consistent level between volumes and over time.
So, how do you choose between the two PD types? As a very coarse rule of thumb:
- If you are looking for 2 random read IOPS / GB or less, growing Standard PD volumes to meet the IOPS needs is the most cost effective route
- If you are looking for 2-30 IOPS/GB, SSD Persistent Disk gets you the better value
One can object saying, "Shouldn't the cloud vendor already know that there is a problem and just fix it and let me know?" That is true for the infrequent big things. But, for the smaller, but more frequent issues, there is a specific issue for some method in some service for some customers in some region, etc... When that happens, the few customers who are hit by that issue can have a hard time knowing it's happening because it does not show on the global dashboard and then have a hard time getting tech support to see that this is really a change in service for them. This data solves those issues.