"The numbers given in this article do not account for any AWS reservation."
While I agree that Google's pricing model is superior, the author's position on reserved instances accounts for ~40% of the cost difference.
In a drag race between instances AWS tends to lose. If you value the enormous feature and service surface-area that AWS provides it's a different story. Either way we win; both companies will engage in a brutal price and feature war for many years to come.
> While I agree that Google's pricing model is superior, the author's position on reserved instances accounts for ~40% of the cost difference.
Author here :D
Gotta take a stance to draw graphs, right? Comparing no reserved instance with the automatic discount is simple and realistic in my experience.
I could make pricing graphs accounting for 25% of AWS reservations and 75% of automatic google discount. In my experience, that's the proportions we _may_ have in practise. It would still be the same conclusion. Google is massively cheaper.
I could make TCO pricing graphs, accounting for the thing from the last paragraph, plus the human time (500$/day) required to understand, pick and manage reservations. I didn't do all the computations but so far it points towards a negative ROI (compared to not reserving), unless the infrastructure is big enough to have the economy of scale (hundreds thousands dollar per year). (Note: I really don't want to go against all the HN/reddit crowd who drank the reservations marketing koolaid, so purposefully avoid to talk about the TCO pricing model publicly ^^).
Thus, in all scenarios, google instances are massively cheaper. YMMV.
As a real life user of AWS I agree with this decision. RIs are not only a headache from a time perspective but we pay a non-trivial amount for a separate tool to manage purchasing them since AWS's built in tools aren't great.
Even with this tool we frequently make planning mistakes due to shifting business priorities or other reasons. Like - oh hay we have to upgrade our database instance but that needs a newer version because only the newer versions support something we need (i.e more than X GB ram). So engineering needs to modify the app to support the newer version.(Oh by the way AWS has a boatload of subtle restrictions like that.)
In this case we were sitting on a RI till EOY and for some reason you can't resell RDS RIs like normal ones (another subtle restriction) so we couldn't even partially recoup costs. Sometimes if you haggle with AWS Enterprise Support you can get them to help out if you're spending the money elsewhere but it's a pain. Good luck if you don't pay for that though (which itself is 15k a year or more).
No one doing over $100k per month is matching utilization perfectly with RIs. Either you are not utilizing some percent of RIs in which case you are overpaying through breakage, or else you are paying on-demand rates for the instances which are not under RI.
The calculus involved with matching RIs to forecSted demand in a dynamic growing workload is NP complete. And any inefficiency delta pays AWS. There's a small part of the curve where your savings is minimal if you don't match perfectly, it it easily goes to negative on the RI change.
Wait, $500/day to manage RIs? As someone who manages RIs for my org, that's way overblown. At most it'd be four figures per year. And once you get big enough, you leverage tools to help you figure out what RIs to get, which more than pay for themselves.
I would like to hear what platform bits of AWS that you find lacking in Google Cloud. Google's ecosystem of fully managed services is very rich broad and compelling, and in many ways far ahead of competition.
(work on Google Cloud but don't get paid to post here)
From the top of my head, a managed Elasticsearch a-la-elastic-cloud would be very interesting. Their offering is expensive and very frustrating if you don't have a paid support contract. AWS has something similar, but lacking features (kopf, kibana, marvel, etc)
I'm not sure where I'm being inconsistent. Both AWS and Google have broad spectrum of fully managed services. There are places where Google lacks and AWS doesn't, and there are places where Google is superior, or where AWS lacks.
In both cases, there are partners that enrich these ecosystems.
You asked for a gap and when one was clearly identified, you went into a weird defensive sales mode. "partner" solutions are often garbage compared to a real native solution, so AWS is much better in this regard.
For me, the most compelling attribute of AWS is familiarity. Google Cloud has traditionally been more forward with bespoke services that need to be adopted in order to use the platform effectively.
Google has Bigtable and Datastore. Bigtable can be thought of as an events database, and Datastore is entities. Both very very compelling for DynamoDB users.
Google's Lambda equivalent is currently in Alpha. That said, there are bits like Cloud Logging and AppEngine that offer unique-to-Google functionality that's somewhat comparable.
Both technologies are clearly very compelling to users.
This is a bit outside of my expertise, but that page mainly points out that DynamoDB supports 3 more language-specific SDKs, while lacking ACID and what appears to be native cross-region replication (through Lambda). Until recently, Datastore was coupled with AppEngine that might explain it.
Datastore and BigTable looks pretty interesting, and I am having a hard time figuring out when to use which (apart from Datastore's ACID support) as both seem a good enough fit for most workloads.
You're correct in that Datastore does provide more general transactions (Bigtable only provides single-row transactions); Datastore also provides indexing and search (Bigtable, like HBase, has a single index: the row key), and Datastore is synchronously replicated cross-zone and cross-region.
I don't think there's an equivalent to Bigtable anywhere. It's so badass it's not even funny - take a look at [0] - a small team of engineers took O(weeks) to build a system that clocks 56 million qps (and these aren't simple bits - 56 million FIX protocol trades and orders).
You can think of Hbase as a clone of Bigtable, if that helps. Bigtable is actually exposed through the Hbase API. /u/mbrukman here is the PM for Bigtable.
Last I checked the pricing was very different; nodes for BigTable, reads/writes for Datastore. BigTable is more cost effective for large workloads, but it requires buying a minimum of three nodes, which is ~$1,500/mo total. If you're small potatoes it seems infeasible. Happy to be corrected if I misread.
DynamoDB and Datastore are mostly equivalent in terms of utility and pricing. GCloud also has Big Table if you're dealing with really large data sets/qps.
Lambda and Cloud Functions are competitors, though there are some things you could do with Lambda + API Gateway that you can't quite do with Cloud Functions just yet (pretty narrow scope, though). I prefer the environment for Cloud Functions, subjectively.
For me, the beta tag on things like App Engine Flexible instances is the biggest concern. We've had "fun" with Microsoft Azure services being less than fully baked, or Microsoft totally replacing services with different ones. In contrast, AWS has been very stable in this regard.
Yeah that's reasonable. At Google Cloud "Beta" means very far down the line of maturity. But YMMV and buyer beware when using "Beta" for production at any provider.
I am a Google Cloud PM, but not on Dataflow specifically.
Do you know how long the Dataflow processing will take? You may be able to estimate the length of the full-size process (assuming it's batch rather than streaming) by running on a small data sample to see how many vCPU hours it takes and estimate from there, assuming your data takes a uniform amount of time to process.
Since Dataflow is running code that you wrote, it doesn't know how complex your processing will be for any given value, so it's hard to give any reasonable estimate. In general, automatically predicting how long an arbitrary piece of code will take to run on a given input is even harder than the Halting problem (https://en.wikipedia.org/wiki/Halting_problem), which is already undecidable.
Another way to look at Dataflow pricing as it related to this type of technology. Let's just assume for a second Dataflow and other similar technologies execute your pipeline on your data within the same resource-time amount.
Dataflow lets you set an upper bound on these resources, and lets you auto-scale, with essentially per-minute granularity. Alternatively, you can create a cluster of fixed resource amount. Cost of Dataflow is $0.01 per hour per CPU, in addition to those resources.
Dataflow's model hence either guarantees 100% resource efficiency, or you specifically opt into the upper bound of spend. A deployment model that lets you "spin up a cluster and pay for it" is intrinsically less efficient.
I wrote a blog on this WRT BigQuery, but Dataflow is right there [0].
Thanks. I know it's tricky due to scaling, etc, but I guess in the same way dataflow works out when data should arrive by (this is a streaming task btw), an estimate of the daily cost could be calculated and would be useful.
Try using https://www.cloudorado.com/ . It will calculate price for specific configuration for AWS, GCE, Azure and more. And you can choose if you want long-term commitment or not.
A nice attempt, but the comparison seems way off for anything beyond the lowest setting on the CPU slider. Choosing "1x" compares an EC2 c4.large instance type to others with a single vCPU (like a $6 DreamHost instance).
While I agree that Google's pricing model is superior, the author's position on reserved instances accounts for ~40% of the cost difference.
In a drag race between instances AWS tends to lose. If you value the enormous feature and service surface-area that AWS provides it's a different story. Either way we win; both companies will engage in a brutal price and feature war for many years to come.