Show HN: EC2 prices per GB of memory(instaguide.io) |
Show HN: EC2 prices per GB of memory(instaguide.io) |
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-...
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.
Ingress Free
Egress inner-zone Free
Egress cross-zone in the same region $0.01
Egress cross-region within the US $0.01
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!").
Disclosure: I work on Google Cloud.
Having Diane Green in charge of GCP is an indication that developing GCP as a business is a high priority.
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.
Would appreciate any feedback!
For me, it would also be nice to see the total price/time unit on the same table as the price/gb.
Disclosure: I work on Google Cloud.
But if you're wondering what the word comes from, slashdot.org
assuming reserved instances with 1yr All Upfront pricing, not counting the really huge xlarge+SSD instances.
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.
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
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.
(work at G)
[0] https://peering.google.com/#/infrastructure
[1] https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp...
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.
Just something I noticed recently. :)
The DC-to-DC interconnects google has are extremely robust.
It's OpenStack Cinder.
They also have object storage, Swift: https://www.ovh.com/ca/en/public-cloud/storage/object-storag...
Time is valuable. AWS/GCE/Azure have a huge head start in making us more productive.
Again, Disclosure: I work on Google Cloud (and this network existed when I got here!)
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.
I'm mirroring my private Git repositories between Gitlab.com and Bitbucket, which can be done for $0.
I might even end up paying for the bottom end Github.com ($7 per month) and Gitlab ($4 per month) accounts and have three way redundancy.
> 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.