Pricing is yet another area where Google Compute Engine is superior. Automatic sustained use discounts[1], the ability to commit long term to a certain amount of cpus and memory and get a discount without any upfront cost[2]. Extended memory[3], basically you can craft a VM instance of any size. Need just 1 cpu but 32 GB of memory, no problem.
AWS on the other hand... A labyrinth of pricing tables, spot instances, EBS optimized, enhanced networking... Complexity.
Google Cloud maybe is superior in the pricing of compute, but it is actually more expensive on network egress traffic, object storage and block storage.
I recently created a simple tool (http://theprice.cloud/) to compare egress traffic, object storage, and block storage cost among AWS, Google Cloud and Azure. It seems like Googel Cloud is the most expensive one in egress traffic and object storage.
Don't feel bad, I'd forgotten this one: "Using a public or Elastic IPv4 address => $0.01 per GB". I'm sad we still don't have a proper split horizon DNS to encourage internal IP usage, but I can't imagine charging for it in the same zone.
All these cloud offerings are priced so complex you can pretty much expect some nasty gotcha unless you spend an inordinate amount of time modeling your workload and traffic patterns.
And if something changes you can do it all over again.
Our egress pricing (from all sources) is certainly higher because we operate a private backbone rather than just dumping your packets straight onto the internet.
Your site seems to be hugged to death (so I can't see it), but there are lots of gotchas with S3 pricing (like rounding up file sizes with Infrequent Access and Glacier) that in our experience means our customers come out ahead. Glacier and Coldline also aren't really comparable in the sense that GCS always responds within milliseconds. We only economics to discourage frequent access from Coldline, not delays. As above, our egress is more expensive because it's better (we hear you though if your response is "I don't care! Give me cheaper instead, then!").
Yes, I totally agree S3 pricing can be complicated with IA, Glacier, RRS, etc.
And it also gets complicated when comparing network egress, when region to region and egress to different parts of the world are taken into consideration. And GCP is actually more complex in the sense because it charges different prices for different egress destinations and AWS in comparison is one price for all of the world.
The most challenging part of making this tool is instead of displaying tons of options and dropdowns, I try to simply enough so that people get a general idea of the cost comparison of three major cloud providers, but not too simple to distort the reality.
And WOW, this is my first time getting "slashdotted". Very surprised to see the enthusiasm. The original "Show HN" is here https://news.ycombinator.com/item?id=14582181, and you are welcomed to continue the discussion there
Google's backbone is a little bit different. Google Cloud shares this backbone with Youtube, Maps, and the rest. Not only are there DC-to-DC cables, our backbone extends to a vast number of Edge POPS (more than AWS and Azure combined), detailed at [0]. Our DC-to-DC network is pretty great too, allowing things like Spanner to exist (minimizing P in CAP etc) at [1].
Here's what it means for you in practice:
- Google's Load Balancer supports a single global anycast endpoint.
- When your packet tries to hit Google network, it hits the nearest POP, which acts as an on-ramp to the network and traverses only Google network, not touching public.
- Similarly, when data is en route to a customer, Google network will take it all the way to the nearest DC or POP on its private backbone.
- Google by default gives you a global software-defined VPC. No need to create VPN tunnels between zones/regions/etc.
I work at AWS and I think there's definitely some similarities and differences. We do share our backbone with CloudFront, and hence our video traffic, of which there's quite a lot these days. We also advertise our network ranges broadly, it's our mission to carry the traffic as much as possible ourselves. So those aspects are very similar.
But a genuine difference is that we don't try to operate a global "seamless" network. The reason is that we optimize for the "A" in CAP. Our experience is that at the low-ish level of a network, it can be too easy for outages and availability issues to spread quickly. For example, with global networking then a misconfiguration or error can more easily propagate globally and bring everything down.
Instead, we have autonomous uncoupled regions and it's one of our core principles that faults and errors stay within these regions (or better yet, availability zones). That does mean that partitions can happen, but find that most customers use active-standby configurations (where it makes no real difference) for key data, and we also build the tools that work with partitionable networks at a higher level. For example Route 53 supports multi-region routing and failover, and does it measurably better than simple anycast routing can achieve.
Over time, we're offering more and more multi-region services, such as cross-region replication for data, but the coordination is done at higher levels where we can achieve higher levels of availability in simpler ways, built on top of a more solid foundation.
Yeah, at least one outage in the last year for us included the paraphrased "anycast is hard". There's definitely an advantage to limited-blast-radius services, but I wouldn't trade GCS's multiregional buckets for S3 CRR (the same applies to Datastore, etc.). We have strict reliability requirements for global services; our perspective is that some customers want regional control for regulatory reasons, and we're happy to meet those requirements. But composing a global or even multi-regional service on an untrusted, lossy network is "crazy".
Again, Disclosure: I work on Google Cloud (and this network existed when I got here!)
>For example, with global networking then a misconfiguration or error can more easily propagate globally and bring everything down.
This sounds like Nassim Taleb's antifragile meme [1].
If I was running IT for some large enterprise (which I'm not!) then I might replicate services on both AWS and Google Cloud. A bit like Apple try to have more than one supplier for their hardware components.
Just in case you can forward this on... AWS EC2 eu-west-2 (London) to GCP Network Loader Balancer is about 12ms round trip for some reason. Most other anycast services located in London are 0.5-2ms round trip.
Though Glacier is hooked to S3 (for obvious reasons) I don't think it's relevant to a discussion of bandwidth egress costs. If you're frequently pulling things out of Glacier then you're using it wrong.
I agree! Most conversations that somehow talk about GCS being more expensive usually are "oh actually, AWS just charges less for egress" (which isn't a non sequitur but is effectively orthogonal). Again, I'd respond directly if the site weren't hugged to death :).
WOW, this is my first time getting "slashdotted". Very surprised to see the enthusiasm. The original "Show HN" is here https://news.ycombinator.com/item?id=14582181, and you are welcomed to continue the discussion there
One thing I would like to add is also the fact that they give you tips on under utilized instances and how much you can save per month. They really go the extra mile to make sure you are paying for what you are truly using and not paying for idling hardware.
I've built this page since I often just want to pick a spot instance type that gives me biggest bang for the buck. Amazon's own pricing page is still very confusing, and ec2instances.info is great but it is a static website and adding spot prices there is nontrivial.
I've also fixed a few minor things that annoyed me, such as correct sorting by instance type (so that r3.16x goes after r3.4x) and added a mode to display spot savings vs on-demand.
Right. So the Show HN page says you can barely go below $5 per gigabyte with on-demand pricing. OVH RAM instances consistently cost 1.33 $/GB for a machine with 30, 60, 120 or 240GB of RAM.
I havent looked at OVH lately, but are they really a cloud? Do they provide full VPC with central firewall? Dynamic network disk storage that can be mapped to servers?
TIL, thanks! Didn't realize OVH was OpenStack--that's a pretty hard no for me, because I've witnessed firsthand the failure conditions there, but I appreciate the correction.
It's not NFS, it's a block storage mechanism. NFS presents a file-based interface, EBS is a block/device-based interface. The underlying implementation isn't widely publicized, but if you think about how a block device works on a Unix and the AWS bigger-is-faster model for non-PIOPS EBS, you can probably draw some reasonable inferences.
> For example, in at least some embodiments, a representative logical local block data storage device may be made available to an executing program via use of GNBD (“Global Network Block Device”) technology.
If all you need is compute and RAM, then OVH dedicated machines are a great choice; I used them for a long time myself and would again for personal stuff. That said, it's important to remember that focusing on that to the exclusion of turn-key services (RDS has saved clients of mine tens of thousands of dollars in billable hours just by itself) doesn't do you so well once you need more than that.
When they have RDS and Redshift and and Athena and SQS and SNS and when they have a fully-functional API that crosses every platform I need to write code against and years of a proven track record of stone-cold simplicity and success, I am sure I will take that into account.
Time is valuable. AWS/GCE/Azure have a huge head start in making us more productive.
Forgive me for a dumb question from someone who doesn't do cloud computing currently : the units are really $/GB/time period, yes? What is the time period? One hour? day? month?
AWS bills instances hourly; both Azure and Google Cloud bill by the minute (albeit with a minimum of 10 minutes). For data analytics that you want fast turn around time for, this ends up being a big deal: a 30 minute job is literally 2x less expensive than "round up to an hour". This also shows up in auto scaling of services, since a standard business day of traffic obviously only has a fairly short actual peak combined with what is ultimately fairly short term load.
AWS on the other hand... A labyrinth of pricing tables, spot instances, EBS optimized, enhanced networking... Complexity.
[1] - https://cloud.google.com/compute/docs/sustained-use-discount...
[2] - https://cloud.google.com/compute/docs/instances/signing-up-c...
[3] - https://cloudplatform.googleblog.com/2017/05/Compute-Engine-...