Google Cloud is 50% cheaper than AWS
thehftguy.wordpress.com
thehftguy.wordpress.com
I finally had to call my rep at AWS and said - you are putting your business with us in jeopardy (On other accounts that we spend significant money on) because its taken me so long to resolve this. Got it unlocked in 24 hours, but the whole thing left a sour taste in my mouth.
I suspect Google WILL have this issue as well, it has the potential to be a huge issue for your business.
Alternatively never had this issue when I've COLO'd - food for thought.
Taking it one step further in precaution (and from experience): We have some servers colo'd at a small datacenter. We use it strictly for our operating website and don't put anything for customers in that data center at all even though it would be convenient and save money. The reason is we don't want any bad actors that we might have as customers potentially impacting our main operations. This is in addition to vetting customers as well actually.
For example, if my business email were hosted with G Suite, and my admin G Suite account got suspended for some random reason.
To my knowledge there is nothing preventing an automated banning machine to start firing at random on someone's accounts. And since, it appears, you have absolutely no recourse (except having friends working at google), and they are not held accountable for these "false positives"... You better start planning for it.
Their "Terms of Service" clearly says that the main account and "all related accounts" will be suspended
The alternative implying 100 separate accounts is so much worse.
A year ago while planning to move from AWS to GCE, I created some instances to test under a company email id. Our emails were hosted under google apps. At some point, the email id got deleted for other reasons. I was in for a rude surprise. The instances disappeared, as I found out when the test urls didn't respond. Apparently, GCE deleted the instances without warning. I was later told by support staff that I should add another admin email to prevent mishaps like this. Seriously.
Anyway, we use GCE these days along with AWS and I quite like GCE. Of course, we now don't delete any email ids :-)
I know this seems harsh, but there's really not a whole lot of other sensible options. The former owner can't be contacted, since the only email we have for them no longer works, and the project is literally unmaintainable, since nobody has admin rights to it anymore.
So TL;DR, for anything remotely important, please assign multiple owners and use role accounts (admin@corp) instead of users (bob@corp).
By far the most common scenario for this to happen is that Bob leaves Corp, and Corp intentionally deletes his account. If Corp has set up billing sensibly, the project will have a central billing account whose admin will be notified, but if Bob signed up on his personal credit card, there is nobody to contact here either.
You have knowledge the account belongs to BAR.COM company, why not contact them? How about a warning to the person deleting the account, telling them that a particular GC service is dependent on it? You know exactly what you plan to delete, after all. How about requiring at least two emails on the GC account so that there is an escape hatch? Can you think of any other ways of preventing this disaster?
Yeah, I get it, the user should have avoided that mistake. People make mistakes, it's the fact of life. You have built a minefield for your customers and left them to sort through the carnage of the explosion.
If you're worried about access, you can establish a service account with Owner level access. Or you can add other Google Accounts to the project. (Here are the docs on that: https://cloud.google.com/iam/docs/overview)
I personally have all my Google stuff separated into 3 accounts (work, personal email, and personal Google-y things). My work account has access to the projects on GCP, along with some coworkers. That puts up enough of a firewall between various services so that if Google throws down the banhammer, it's not totally game over for me.
My understanding from the recent Pixel-orders-account-banning incidents that Google had nuked even marginally related accounts, including gmail accounts whose only relation was being the recovery e-mail for one of the offending accounts. I just read this in one of the articles, so I don't know if it is true, but if so that seems to devalue the possible solution of just linking a number of different Google accounts to your Google Cloud account with owner access to the project. In fact that might be a larger concern if any one of those accounts raises the ire of whatever Google department does the nuking, they might extend the action to all accounts associated through the Google Cloud project. Hopefully not likely, but this stuff worries me.
And it is a telling indictment of the corporate character displayed by Google:
- Exploitable for minor personal convenience ("Use Gmail! Use Gcal! Simple and free!")
- Not to be trusted under any circumstances with important matters ("We can evaporate your existence from the internet for all practical purposes and there's not a damn thing you can do about it.")
Some day, it will become important for us to own our own lives again. And I say this as someone who runs his business on GApps. I'm as guilty as everyone else.
Are you planning to run your own email servers (or any other service that Google provides)? Or just switch to another vendor?
But it irks me that I follow the easier, softer way -- knowing that I am causing trouble to myself by doing so.
For search and maps, I use Google, for personal hardware, Apple, for cloud servers, AWS, for email, Fastmail on my own domain, and so on.
It is slightly more inconvenient than having one Google account to rule everything, but it helps me at leas feel a bit saner..
Eventually, this may be true.
In practice, I believe Sandstorm still requires nontrivial amounts of handholding when updates occur.
I just checked back with them, and they confirmed that I'm entirely mistaken.
Never realized I could do this. Is my understanding correct that Google Cloud won't suspend a project as long as there's a service account associated with it?
With google, you have to be extremely cautious (no pun intended), especially after they have become big. AWS is far more reliable in this sense, and even Azure may seem better.
Issue resolved with a call to a Googler friend :/
Googlers are very active in many forums, including HN, Stack Overflow, mailing lists, and other forums, not just via paid support.
If a customer is having trouble reaching someone at Google regarding Google Cloud Platform issue, I'm sorry to hear that, and would love to hear what was tried and did not work so we can improve the process, but we are listening and paying attention, and happy to hear constructive criticism.
It's definitely NOT the intent that you must personally know someone at Google to resolve an issue with your Google Cloud Platform account.
Sorry to hear you ran into this issue, and glad that it was resolved.
Just curious: did you try any channels of getting in touch with anyone at Google before reaching out to your friend? And if you did, and they did not work, we'd definitely like to know so that we can fix this.
We'd certainly like to make it easy for anyone to resolve issues with their GCP accounts easily, without requiring you to have a friend or acquaintance at Google to help fix this.
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.
RDS instances with Postgresql.
Let me know if there are any others.
Like AWS?
I see.
In both cases, there are partners that enrich these ecosystems.
Most alpha services do not yet have gcloud support.
I'm PM for another Google Cloud database (not Cloud SQL), but will share this with the team.
Postgres
Integrated domains (a la R53)
S-N/E/Q-S
I'm generally comparing AWS to colocation, not other IaaS offerings.
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.
(Work on Google Cloud)
http://db-engines.com/en/system/Amazon+DynamoDB%3BGoogle+Clo...
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.
Would love to hear more thoughts from you.
(work at Google Cloud)
Is Datastore Spanner?
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.
[0] https://cloudplatform.googleblog.com/2016/03/financial-servi...
Datastore and Bigtable have different characteristics and use cases; see https://cloud.google.com/storage-options/ for an overview.
Datastore is a document database (compare it to MongoDB), while Bigtable is a wide-column store (compare it to HBase or Cassandra).
> Is Datastore Spanner?
Datastore is built on Megastore, which builds on Bigtable. :-)
I am the PM for Google Cloud Bigtable.
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.
But does it support commas?
There's PubSub, Cloud Logging, Firebase (including Firebase Messaging), and all 3 don't really have a great direct AWS equivalent.
Take a look at the AWS/GCP equivalents at [1]. Mostly full coverage, although, again, some services work differently (usually better I hope!).
Email is indeed handled through either SendGrid or Google Apps [0]. Spam reasons I believe.
[0] https://cloud.google.com/compute/docs/tutorials/sending-mail...
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.
Details on Dataflow pricing: https://cloud.google.com/dataflow/pricing
Pricing calculator to estimate cost for Dataflow and other products: https://cloud.google.com/products/calculator/
Hope this helps!
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].
[0] https://cloud.google.com/blog/big-data/2016/02/understanding...
(Work on Google Cloud)
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.
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.
You have to get pretty big to get discounts from published prices, far bigger than $1M/year, more like $1M/month.
To get a rep (that's unrelated), you have to pay full support which is about 10% per month (with a high minimum fee).
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).
And there is a 3rd competing tool that I can't seem to remember the name.
I've used them, and they're much cheaper than ordinary instances. They happen to fit my use case, which is a simple copybigfile-simulate-writeresults done over hundreds of days of market data.
Preemption does happen, but it tends to happen very early on in a simulation. Also you don't get billed if it's in the first 10 minutes. For some reason GCE won't let you auto-restart that instance, but you can just write an API call that accomplishes the same.
There's also the added benefit that your instance will die after 24 hours, so you won't get billed for leaving something on by accident.
Something about the automated abuse detection seems to not quite work, and so I've gotten emails saying the account is suspected of DDOSing other internet users. It's a bit unnerving, but they've been pretty prompt at getting back once an explanation was put forward.
Would you rather have your mission critical apps relying on Google's customer service or on Amazon's customer service?
Either way I would greatly rather deal with AWS support than Google Support, which as far as I can tell is an oxymoron.
(Disclaimer: I work there.)
I spent many, many hours over many years trying to get access to my old account again and never did. Email is pretty sticky, so I'm stuck relying on Google for it, but after this experience I'm overwhelmingly unlikely to ever rely on Google for another service I care about.
I've also had some significant technical issues with other Google services where there is no support (e.g. the talk plugin for Firefox simply won't install and the troubleshooting page suggests using Chrome), but losing my YouTube account is something I'll never forget.
Every experience I've ever had with Amazon's customer service has been fantastic. I wouldn't want to be one of their suppliers but as a customer, they're great.
I'd assume that you can count them on your fingers if the bill is only $1000/month. That's a "reasonably" small scale migration, if not locked in on AWS services.
But all in all, yes, it is a fairly small scale migration.
[EDIT] Plus I'm the technical founder, so enjoy this stuff, which means a lot of the work was done in my free time.
edit: To those down voting you are welcome to present a different perspective. A down vote by itself doesn't mean much but I welcome criticism and feedback on my point of view.
In many cases, taking a break from the task at hand has great effects on resetting the fatigue that builds up when you focus too hard on a narrow set of problems. I wouldn't consider those breaks a "cost" when they're ultimately used to allow you to more efficiently use your time while at the same time reducing burnout.
Don't get me wrong - time is finite and it shouldn't be squandered. But at the same time, perhaps what looks like a walk around the block is much more than a 15 minute "cost".
Your time is free and will continue to be so. As a human, hey you got some time left and if you got goals, well then perhaps you haven't time to waste. Yet, if you wish to speak of "reality", you must tell me who's the one demanding any payment for any second of your time? Is it no one but yourself? Is it not your idea of what that time could have (perhaps _should_ have)? No, that's not reality -- that's your superego, which is in your own head.
You should watch your tongue a little more carefully; it's rude to reply "no time is free" when it's not at all the topic of conversation. You deserved to get downvoted for that reply and the reason you're getting downvoted for this one is that it's too binary. Lighten up. All someone said is "I do this in my free time" and you had to step in as protector of truth and say "no such thing." There's no valor in this behavior.
My reply was perfectly suited for that response. It wasn't binary, it was begging the OP who said he/she works in his free time to stop calling it free time and answer the original question.
Pro: Can't make hot cakes fast enough.
Con: I wish I could switch ovens; a white one matches my kitchen's decor.
Now on GCE, we use Kubernetes, which means the type of instances is rather insignificant as they can be instantly scaled up when more resources are needed for containers.
source: http://www.ec2instances.info/
Or does it just make sense to stick with GCP since K8s has Google's blessing?
Or...
The only downside is that Google Cloud doesn't have a hosted DB offering for PostgreSQL, like AWS RDS, so it took me a while to set up everything properly.
Finally, from a purely subjective point of view, Google's Material design is easy on the eyes.
This is roughly what we ended up with for our stack: https://cl.ly/1z141g0e1w38 (The top three instances are K8S, then two GlusterFS instances which hold persistent volumes for pods and finally three PSQL instances that also run Redis Sentinels with a quorum of 2 - Redis itself is on Kubernetes as a DaemonSet)
> Two reasons really, the first is that AWS has become this bloated mess of "stuff", making it increasingly harder to use
Are you referring to any specific offerings: CodeDeploy/Beanstalk/EC2? Or generally the entirety of AWS catalog? I agree that the sheer amount of configurations and the breath of offerings might appear bloated and there are parts where AWS looks its age, not necessarily a bad thing, though.
> because so much time is needed to either constantly look at it to see what's new/changed or vigilantly document everything
I am not able to relate to this. AWS is pretty serious abt backwards compatibility and making transitions smooth unless there's a serious security risk.
Re: Console: This complaint comes up often on HN. Thanks for pointing it out.
Re: Convention over configuration: K8s seems to be a great piece of software from what I keep reading abt it. I can understand why anyone would choose to use it. I am left wondering why it isn't as easily usable on AWS infrastructure... I guess I must try it out myself, someday.
And as a "very" curious developer, I always get pulled into analysis paralysis. Not so with GKE. There's one way to accomplish a particular thing, the only choice is UI versus CLI - and since most of us have Google accounts anyway, gettings started with GKE is maybe a couple of commands and you have a cluster up and running.
Try googling how to set up Jenkins/WordPress on AWS/GKE. A VERY real world examples and Google provides docs, AWS does not - I'm not interested in high-level overviews, I want to solve a particular problem.
What AWS needs first and foremost is a competent UX team.
I am a Google Cloud PM, though not on Cloud SQL itself.
Seriously. Every time I sign up, I have no option to sign up as a individual, only company.
Friends in other regions of the world can sign up as individual, but it appears google ( in the UK/EU ? ) as decided for whatever reason ( I assume VAT calculation ) they won't offer it.
I can sign up to and use AWS ( as much as I really don't really want to ) as myself. Yet there are all of these really nice things coming out of GCP that I can't use because I simply can't enable billing. (that being said, I do use google app engine for my blog, and it's fantastic)
[1] https://thehftguy.wordpress.com/2016/06/15/gce-vs-aws-in-201...
Under the Obama administration we didn't see any antitrust/antidumping actions because of how much Google managed to embed themselves into the administration. Don't know if it will change.
EDIT: fixed a typo
In my view, there's really only two things that can reduce cost enough to make a difference: 1. Reducing energy consumption, 2. Reducing drive / component failure.
I believe Google may be better at both of those than Amazon.
From Amazon however I have even heard about them forgive bills where the customer was really to blame.
All this is hearsay though and I don't think Amazon does this out of the goodness of Jeffs heart but as long as enough people think this is how it works it might be part of why people will use AWS even if it is more expensive.
I'll also comment that Google's Eng/PM org is very engaged. It's not unusual for an engineer in charge of a service to help resolve a customer an issue.
[0] https://cloudplatform.googleblog.com/2016/10/introducing-a-n...
(work on Google Cloud but do not get paid to post here)
This is not related to Google Cloud, but to GSuite: Or, if you get an engineer on the phone, through the support number, they just insult you, and hang up on you, as has happened to me once (back when the free tier of GSuite was still a thing).
I know Google support spends gobs of time quantifying customer success and happiness, gets measured and rewarded by these numbers. Nature of support anywhere is that sadly you'll always have some folks with a bad experience, all you can do is try to make it right by all.
I do assure you that Google Cloud invests a whole lot of time and money thinking about customer happiness, as should all organizations. In the public cloud business, customer happiness is everything.
This is the norm with AWS, in case you didn't know.
Like someone pointed out, having a deeply engrained customer-focussed culture is different from having a massive support org that quantifies customer happiness as datapoints on a review board somewhere in cozy SV offices.
I am also not going to get into a discussion with an AWS employee about culture health between the two organizations. Both are trying to do it right for the customers, and both have unique challenges, regardless of the amount of coziness of their offices :)
It's unfair to paint Google as "out of touch" and "not customer focused", just like it is unfair to bring up horror stories about Amazon culture, especially if you're employed by a competitor.
Apologies, again, but are you an AWS employee? I don't want to inaccurately label you as such, but your posts hint at it.
(work at Google Cloud)
I work for Amazon, yes.
In the last three days I have been able, in my day job, to personally ask a Google PM to pull Google Cloud engineers into a shared slack channel to help.
It took us longer to set up the slack permissions for the googlers to join than it took for Google folk to identify who to pull in.
We are also a major partner of Microsoft.
We've also been on AWS, spending a shit ton of money, for a long time.
And as whelmingness goes, my personal experience with AWS has remained squarely in the "under-" camp.
I am not an executive, or director, or anyone with any political or financial pull. I am a plain engineer. Yet Google folk came to our aid, quickly, when we needed it, without needing to stump up buckets of cash or wait for someone somewhere to take our ticket.
I wonder what you should be disclosing.
--
Assuming that this is true, having no customer support is still better than the AWS support ;)
If you'll allow me to get a bit more wibbly: I've been an engineer at both companies, and from a technical perspective, Google is much better at this stuff. In order to provide their own services, they've been operating at much larger scale for much longer than anyone else. There's a pretty long record of the new hot thing in the industry being something Google's been doing on the order of a decade. The basic deficit in experience is exacerbated by Amazon's relatively poor retention of its best talent.
Putting all of this together, it is my expectation that Google be able to build better services faster, and to operate them more efficiently. AWS started with a massive first mover advantage, but my expectation is that in the long run Google will have little difficulty closing that gap and pulling ahead, should it wish to.
Correct, see how much profit AWS contributed to Amazon in the past quarters.
> I've been an engineer at both companies
Same here, so I offer my perspective.
> Google is much better at this stuff
Not much, but noticeably better across the board. Overall it's substantially better when combine everything together. But as others point out, the technical superiority does not account 100% of the quality of product offering. Being in 2 companies, I think you have similar experiences. Otherwise, GCP should already eat AWS in 2012.
> Google will have little difficulty closing that gap and pulling ahead
I think so. But my expectation is that Google needs operate Cloud as its top priority, and treat AWS as a tougher competitor than MSFT in the search/browser war. The thing is, that Cloud is a much much bigger market than internet ads. The race will be long and difficult to predict. Amazon is a much more formidable competitor than MSFT. They have proven to be the best in retaining customer and build a brand. They are also extremely fast in execution. And they are not afraid to try crazy ideas and abandon them if proven wrong.
Edit: posts further down from mine seem to suggest my sentiment is outdated and Google takes cloud support very seriously in their teirs. https://cloud.google.com/support/
The individual teams however have been fantastic, available on both Slack and Google Groups.
I don't know about that. Going further, majority of the spend is going to come from established businesses. They need software and not just infrastructure. And msft has those accounts. Has the reseller network. Has the software. I really can't think of any good b2b/productivity software that google wrote. Probably they haven't tried, but looking at what they announced last - data studio, survey and optimize - the talk was like they were super serious about it. The result is very, very far from the competition.
The only thing I can think of is the google apps for business (Gmail/Docs).
Also worked at both companies. Google is not better. Google is a retirement home for engineers. Few creative things happen there (anymore--wasn't always true). If GCP is so star spangled awesome why is it still so far behind AWS? Why did AWS start literally 10 years before GCP?
Google reacts to competition while Amazon proactively responds to customers -- this, as always, is the difference that allows amazon to succeed.
A "bias" disclosure would be helpful here.
(work at Google Cloud and don't get paid to post on HN)
Totally possible I didn't get to see the full benefit of the culture there. I have however seen friends disappear into google over the years and emerge with a distaste -- obviously the same can be said for amazon. A constant bias disclosure is cumbersome but you're right that it would have been helpful, you've forgotten it on some of your posts as well.
My comments were off base sorry, obviously google does a ton of cool stuff. I let my emotions around this ridiculously biased post get in the way of my reason.
You also tend not to address the merits of the post, instead using ad-hominem and misdirection. I'm actually noticing a pattern here :)
And what are you doing?
I certainly am not in a habit of disparaging my employer's competitors' cultures and technologies through anecdotes (the last ex-AWS bit was the notable exception in the heat of the moment).
I urge both you and "ignoramous" to get into this habit as well :)
(work on Google Cloud)
That seems to answer the first question. AWS had a multi-year head start, but GCP is catching up and has the fundamentals covered, and the primitives they offer are very strong.
Basically, they can do a better job than Amazon predicting current and future workloads. As a result, they can more efficiently place workloads and literally do more with equal or less hardware. That and the fact that they have been building their own hardware better means their hardware is also very likely more advanced. Those together mean they can do the same thing for cheaper and still turn a profit.
Amazon optimizes for doing something first and doing the most. Google optimizes for doing things smarter and as a result often does them cheaper. However, it also means that Google provides massively fewer services than Amazon.
They have better hardware utilisation and a lot of their infrastructure was fully-depreciated before they opened GCP.
Unlike AWS, Google couldn't design systems assuming a customer would bear the price of any moderate inefficiencies. So they've had more design pressure on cost from the beginning.
I also suspect their cost of networking is much lower -- they own their own fibre network and a lot of it will also be fully-depreciated.
I do not want to draw any conclusion here but when it comes to which company gets my money decision I always prefer Amazon.
The following applies to customer trust too:
"It takes a lifetime to build a good reputation, but you can lose it in a minute."
― Will Rogers
In every area that I've looked, GCP is so much better than AWS that it's offensive, bordering on obscene.
It's faster, cheaper, more configurable. The documentation is actually comprehensible. The APIs are consistent. There's a single console, rather than a fruit salad of conceptually different consoles under a single domain. The console is, in fact, navigable without invoking curses. Not even a small one.
AWS has the massive advantage of inertia. If you're deeply woven into the higher-level AWS services, I'd probably stay put.
But if you aren't, or you're just beginning, then holy moly you owe it to yourself to look.
The docs have more 404s than trumps twitter account... who payed/paid you to write this?
>The docs have more 404s than trumps twitter account... who payed/paid you to write this?
(ranman works at AWS..and talking to an AWS premier partner... the delicious irony)
I recently noticed that AWS employees throw (sometimes not so) subtle shade at their competitors on HN without disclosing their allegiances. That's all fine, but I saw the same undertones directed at opinions made by a very good customer, which upset me.
Throughout the thread I've attempted to engage in discussion, gather feedback, and share some info. I was set off a little :/
On the feedback, I hear you. Please reach out to me offline for a further discussion (if you want).
Pls do not pass off his statement here as an official stand by Pivotal. Unless of course that's what Jacques here meant to do (I wouldn't know)...
And, of course, my opinion of GCP is just, like, my opinion, man.
In my personal projects I have stuff on AWS. In fact I'll be adding more soon, since Pivotal Web Services is housed on AWS. And there's still a lot that AWS can do that GCP can't. It's just that, for the tiny slice of the world I've seen, I like GCP a lot more.
No matter which platform you prefer, everyone will benefit from the fierce triangular tug-o-war between Amazon, Microsoft and Google.
Especially if they're on a relocatable platform like Cloud Foundry (disclosure: Pivotal sells a version of this) or OpenShift.
Thanks for clarifying statements and for the feedback.
I would appreciate immensely if you can elaborate your frustrations with AWS apart from the ones you have mentioned already. You could either do it here or I could email you, or if you have a comment trail on this topic on reddit/hn/twitter, I'd appreciate the links. Thanks once again.
I feel that AWS has a strength and weakness in the fact that its longevity has led to a massive feature set. For those who've grown in expertise alongside it, AWS seems natural and obvious.
I have instead come to this super-featuresome platform and found myself totally lost. If I was one of the people who'd consumed the new features piecemeal over the space of a decade, it wouldn't seem so daunting. I guess the same will happen to GCP.
But even so, I find it much easier to get around in GCP. The console is obviously built as a unified experience. It still has a CRUDish flavour to it, insofar as it requires you to have some of the underlying model in your head to use efficiently.
But it needs less and it tends to be less of a hunt for the foo that uses the bar that depends on the baz based on the quux which is ten bloody screens away under an ill-chosen name.
Oh and AWS console seems to have a vendetta against allowing me to open up a bunch of tabs easily. I hate that. I usually want to look at two things side by side because weirdly, I find it hard to retain randomly-generated strings in my short term memory.
As for performance, GCP brings up VMs extremely quickly, the networking is really fast and the prices are nicer.
Truthfully, I've touched maybe 5% of what AWS or GCP offer. But the 5% I've seen is compelling. I think Google are going to finally break their total reliance on advertising revenue.
Rest assured AWS isn't turning a blind-eye to its shortcomings. Exciting times ahead for everyone involved.
For what it's worth, James Watters (Pivotal VP) agrees with the overall sentiments of the article[0].
To the folks on this thread, please don't hesitate to reach out with any feedback or suggestions directly.
[0]https://twitter.com/wattersjames/status/800030791954677760
The AWS docs are enormous, cover every angle, and take me quite a while to work out. I'm not very bright.
That said, Google's concepts are confusing in places. The one that caused me a lot of head scratching was the difference between forwarding rules and global forwarding rules. AWS has better diagrams in a number of places.
As I said below AWS docs could be dramatically improved for accessibility.
GCP's major weakness for me is locations. They will (if they deliver on their plans) get a proper global footprint in 2017, but right now it's a US and EU centric service that simply can't match AWS's global reach.
I know. That's the feeling I have every time I compare them.
It's just borderline insane. There is enough materials to write an article: "100 little details that AWS got wrong but Google Cloud got right [and the 4 exceptions that are the other way around]"
While KS is probably more important for EU customers, the KS-VPS line has three regions to choose from: Gravelines (Northern France), Strasbourg (Eastern France) or Beauharnois (North-America). You can also DIY your own cloud with https://www.ovh.ie/vps/vps-cloud.xml, though I've never tested this.
Personal point: I may be very old-fashioned, but after using GCE and AWS for various tasks, I still prefer the transparency of pre-committed billing. E.g., I don't know if this changed by now, but I ran into dozens of inexplicable administration errors with GCE, to the point where I couldn't manage my own projects anymore. Plus, after creating billing details, I couldn't detach my credit card from the platform. The only way around that was to disable all projects, but that still left me with an uneasy feeling.
I don't have automatic billing setup for KS/OHV. I get billing reminders 30/15/7 days before each cycle and authorize each payment.
Essentially a VPS provider is someone who rents you a server instance on a much larger server running other instances of other people's servers. You are in complete control of your server instance. You have to manage all the application installations, firewalls, security, etc.
A GoDaddy or Bluehost is someone who gives you folder space on a server. They have the web server, database, and any other application all setup for you already. Typically those types of providers only allow you to serve static content, or certain scripting languages (mostly PHP).
It depends what stack you wrote your web apps with for which provider you should go with. With a VPS, Linode is going to be cheaper than Digital Ocean, which in turn is cheaper than AWS when you compare specs to specs. If you're app is a simple PHP app that talks to a database, you could probably host it way cheaper on GoDaddy or Bluehost. You just wouldn't have very much control over all the different versions of the DB/PHP, etc. that you might want.
If you want to compare for prices, just search for "VPS with hourly billing" and you should find some alternatives to DO which may be worth considering.
And if you want to dig deeper, I have written a book [1] which I hope can clear the confusion and give you a better idea of what hosting you need for your apps.
(work on Google Cloud but don't get paid to post here)
Let me know if there are any others that you feel strongly about?
It'd be great if you can share how to best spin up a managed Postgres instance.
I'm using GKE and it has been working like a charm so far.
I do not remember to have read about Google equivalent of EFS yet. This can make it relatively easy to migrate legacy apps to cloud.
And as the other comment says above, familiarity. We have around 20 programmers at our company who are comfortable managing deployments on AWS. We had to spend a lot of time and money on their training. Google hasn't given the 10x reason for us to switch.
I don't want some 3rd party to manage Postgres. I want something seemless like RDS.
> in many ways far ahead of competition
Yep. In my experience, when Google Cloud does something, they do it right.
The thing is, the AWS pricing strategy is global and most services are built on top of instances.
On another note, I'm not surprised Google cloud is cheaper as its trailing behind and offer no other advantage but price to catch up. GCE, Azure and AWS all pretty much match each other technically, so I suspect the one with least customers to always offer the better value. So if GCE were to ever become number 1, I'd suspect it's price to rise and others prices to lower.
Well that's a huge caveat. Anyone intending to be a serious user of AWS will use reservations. The discount is large, well over 50% off IIRC. And then there's the spot instances/spot fleets with even steeper discounts.
For better or worse, AWS's pricing is more complicated then its competitors. A serious comparison would have to include those details.
Not in my experience... It's impossible to predict the kind of usage you're going to need over the next 1-3 years, especially when you're first getting started with AWS. If you underestimate, you waste money. If you overestimate, you waste even more money. Google's concept of "sustained use" discounts is _much_ more appealing to me.
Then I respectfully submit that you are not (yet) a serious user of AWS.
> It's impossible to predict the kind of usage you're going to need over the next 1-3 years
I call BS. Office 365, JIRA, Slack, Loggly...these all have monthly price plans, and discounted yearly plans. People managed to predict needs, despite a uncertain future of their needs. In the case they underestimate, they just purchase more at anytime. In case they overestimate...I don't know; I just know that a price comparison would very likely use JIRA's yearly prices, not its monthly ones.
Unlike those examples, reserved instances can be bought and sold on the AWS marketplace (https://aws.amazon.com/ec2/purchasing-options/reserved-insta...).
I understand (and agree) if people criticize the complexity of AWS EC2 pricing. But if you're not going to use reserved instances for your non-trivial stuff...you're flushing money; go with another provider already.
These services have different, not comparable pricing models. See http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...
They only sell packs (like 5, 50, or 500 users). All customers have to pay for the superior pack. There is little price prediction, you just _seriously_ overallocate to the next plan available. That's a revenue optimization strategy for the company. It's very costly for the customers.
> Unlike those examples, reserved instances can be bought and sold on the AWS marketplace (https://aws.amazon.com/ec2/purchasing-options/reserved-insta...).
Nope they cannot... UNLESS you're American, and you have a bank account in America and in dollars, and you have an official American tax number, and you fill some paperwork... and more unknown hiccups you'll only find out too late! (I couldn't continue the procedure to see what's next, didn't fit the criteria at this point ^^).
I'm not sure how this matters to my original point, but AWS charges in packs too. One m4.10xlarge is cheaper than twenty m4.large.
Anyone can buy RIs, but you are correct that selling a reserved instance requires a US bank account.
As for on-demand, AFAIK the only time a discount came close to 30%/year was in 2014 when Google Cloud slashed their prices. So...yeah, it might be possible, but I doubt it.
But the headline assertion is ultimately unsupported except in terms of simple comparison graphs of paper numbers about the raw CPU and memory numbers. Are the CPU units comparable? Is the networking what it's cracked up to be? How easy is it to autoscale? Is the capacity you need available when you need it? How long do instances take to start? What are the dynamic storage options? How does disk IO performance compare?
I'd be really interested to read an article that attempted to break these down and do a real comparison. But this article doesn't even attempt a real world comparison.
In order.
Yes. Google networking is superior (cheaper & faster). Variable, depends on your application/workload, not just the cloud. Yes. < 30 seconds on Google, 1-3 minutes on AWS. lcoal SSD, remote SSD, or remote HDD on Google VS a mess of many complex & expensive disks on AWS (it would take more than a blog post to explain their disk offerings). Google disks are 3-10 times IOPS and/or bandwidth, lower latency.
This article is just on basic pricing. I plan more articles for the future. Starting with one on disk benchmark and one on network benchmark.
Amazon got everything so right with an ID and secret. GC's oauth is just cumbersome, and the CLI tools are nowhere near as user friendly as aws-cli.
Two other recent examples - the lack of granularity and inflexibility of GC's IAM perms (you need to faff around with roles which even as an Owner you can't create - they need to be done at the org level, WTF?), and GC support is miles behind.
I opened a support ticket for a critical issue recently, and the initial response I received when someone looked at it fell into the repeating-back-to-me-what-I'd-told-them-in-the-ticket category. Then they suggested I "check the permissions are right", which as I told them "I don't know what's wrong or what needs checking, that's why I opened the ticket". It's just lucky the issue didn't affect our prod account or we'd have been in real trouble since they're still investigating even though we're probably one of their top-tier customers.
AWS support has always been second to none for me. GC support has always for me been second to, well, Amazon...
But I'm just a tinkerer/hobbyist. So maybe the reason is because I don't have a clear idea of what my monthly utilisation is going to look like, or whether it's going to be consistent. I imagine this would be much clearer for those running businesses. I dunno...
And they have a calculator: https://cloud.google.com/products/calculator/
If you're talking about Compute Engine utilization for billing discounts, they just mean how long you have it running continuously over the course of a month.
- AWS has a 12 months free tier [1]
- Google Cloud has a 2 months free trial [2]
That will make a huge difference when I'll have to choose.
- AWS gives you specific usage allotments per-month for specific services.
- Google gives you $300 cash for 2 months to use however you please. just don't mine bitcoins or generate email spam :)
- Some folks did the math on AWS free tier to total $247.20 [0]. That is, if you 100% utilize all the allotments.
- Google BigQuery, Firebase, and AppEngine also have perpetual free tiers.
[0] http://searchcloudcomputing.techtarget.com/tip/How-much-are-...
(work on Google Cloud)
I wanted to give the free trial a go, but wasn't able to register because it did not let me choose account type as "individual".
Just in the "only instances" space you mention Google has a different strategy. A couple things to mention:
- Google doesn't have a broad spectrum of instance types. No storage-optimized or networking optimized. Instead, any instance can just get great storage attached to it, and any instance gets best-in-class networking.
- Google's Preemptible VMs are like Spot instances but fixed 75-80% off. Again, with less fragmentation against instance types + fixed cost, much easier to rely on Preemptible VMs imo.
- Google's Load Balancer is global, scalable, anycast IP driven, and backed by Google Network. If your packets originate in, say, New Zealand, they'll be talking to a "GCLB instance in our pop in Sydney", which will carry packets on Google's backbone to the VMs.
- Custom VM sizes - you can set your own VM/RAM combination for instances.
- Live Migration. Google manages instance health and maintenance for you, without forcing restarts.
(Work at Google but not on GCE.. and I don't get paid to post here)
My impression is that Google has a first class general purpose instance but you don't really get the breadth of options that EC2 will give you.
You bring up Local SSD. Google's Local SSD is just badass by comparison:
- 680,000 Read and 360,000 Write IOPS included in the cost [0]
- $0.218 per GB per month. Instance cost is separate.
- Again, you can attach these to any instance type (hence the point on fragmentation of instances on EC2)
- AWS goes up to 365,000 Read and 315,000 "First Write" IOPS. Only if you buy an i2.8xlarge [2]
- An i2.8xlarge is $6.82 per hour.
You do the math :)
And someone else did more comparisons here [1]
[0] https://cloud.google.com/compute/docs/disks/performance
[1] https://medium.com/google-cloud/new-google-cloud-ssds-have-a...
[2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/i2-instan...
Followed by waiting on GPUs and other user accessible accelerators of course.
1) The highest memory instance on Google is about 200GB, on AWS it's 2TB.
2) Google doesn't have GPU instances yet. They're been announced for 2017.
Other than that, google instances have more options and more flexibility.
Which is why I find it so annoying when I see these price comparison articles that don't really use the SpotFleet API correctly.
I'm genuinly curious, what kind of project/situation would be to actually prefer AWS to GCE (aside from "we're already on AWS" or "I know AWS and don't know GCE")?
Picard can pull reads directly out of the google genomics API, and more of the Broad tools are adopting the GA4GH api, so this means an increasing amount of core tools anyone doing genomics will want to use, will work directly with google genomics.
OTOH, spot instances can be cheaper but then you should be prepared for those to vanish anytime.
Source: https://aws.amazon.com/blogs/aws/ec2-reserved-instance-updat...
We are moving to aws before the end of the year and it will be a 50% price cut from the dedicated providers we have been using. Our dedicated servers are just about out of space and their bs cloud environment is about 350$ for what you get for 70-80$ on linode. When we need 10-50 processing servers quickly cloned up we go to linode do our work and try to sling the data back ...it's all too annoying now. We're moving to aws, reserving some instances for our client front ends and and booting up what we have to when we need it for mapreduce jobs. For us reserve pricing isn't so bs.
It's terrible.
You can resize RIs within the same family (ie 1 m4.xlarge to 2 m4.large)
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-modify...
This alone isn't going to kill your productivity, but it's one of many of the annoyances of managing a large fleet using RIs. It's a cumulative burden, between figuring out reservations per-region, consider your baseline vs spot/on-demand levels, potentially put some other stuff you don't need on the RI market, and audit how many RIs in your inventory are actually in use.
This is an annoyance when you have a small fleet, but it quickly becomes an expensive nightmare when you start talking 100+ VMs. You start having to pay for expensive external tools to manage your expenses because this stuff sucks so much. Or write a ton of your own tooling (which is not free at all). Or just have someone who does this manually all the time (also really sucks).
[1] https://www.microsoft.com/en-us/philanthropies/product-donat...
GCP has one for education[1], and a program to use GCP to protect journalists[2], but I'm not seeing anything for non-profits. You may be able to get credits by asking them, however.
--
[0] https://aws.amazon.com/government-education/nonprofits/
[1] https://cloudplatform.googleblog.com/2016/06/new-Google-Clou...
( Disclosure: I would for Google Cloud Platform Support and have seen this happen on rare occasions.)
500 GB Storage (Google Cloud Storage Nearline) Storage Fee= $0.01 x 500 = 5 Dollar Retrieval $0.01 x 500 = 5 Dollar Bandwith Charges $0.12 x 500 = 60 DOLLAR
I mean SIXTY DOLLAR just for downloading my backups, they are crazy. Both companys.
Would use rClone for my backups but OVH OpenStack is kind of buggy and could not get it to work.
This is really intended for business. Definitely not a good fit for a personal backup solution.
https://www.ovh.com/us/cloud/storage/object-storage.xml
10 times cheaper than GC oder AWS
"To Apply, contact your VC, Accelerator, or Incubator and ask about GCP for Startups application details." [0]
That's why I highly not recommend to have nay relationships with Google Cloud. It's unpredictable, you just cannot build your business around it. Now it exists, in 5 minutes they may decided to close the service, change the billing to unbillable, whatever. And the most scary, NONE, just NONE helps you. It will be your issue.
Saving 500$ / month is minuscule compared to the time it will cost engineers to migrate from AWS to GCS and get used to the new service.
Look at Ansible (or Puppet, Chef, Salt, etc.) With the right configuration management tooling, it's much, much easier to migrate services.
It is with HVM and enhanced networking. You can "wget http://ipv4.download.thinkbroadband.com/100MB.zip" and see what speed you get.
Between two m4.large in two different AZs.
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.00 sec 3.13 GBytes 449 Mbits/sec 39391 sender
[ 4] 0.00-60.00 sec 3.13 GBytes 449 Mbits/sec receiver
CPU Utilization: local/sender 1.4% (0.0%u/1.5%s), remote/receiver 7.2% (0.8%u/6.4%s)
for example, "minimum production instance", it's comparing a 2cpu aws instance vs a 1cpu gce. no wonder its "50% cheaper".
I use GCE over AWS, and run aprox 50 vm's. GCE is cheaper, but not nearly as much as the article claims. the savings is for hardware. data egress cost is basically the same.
But quite obviously only read the headline.
TL;DR -- I urge all readers to take this post with a grain/boulder of salt: The author is anonymous, prone to hyperbole and error, and makes multiple unverified claims. I'm sure he's a nice guy/girl and if we met in real life I'd be happy to converse over a beer -- but I find the language and misinformation in the post overly polemic and disingenuous. If this stuff interests you guys tune into the reinvent livestream next week: https://reinvent.awsevents.com/live-streaming/
All numbers are from EU-WEST-1 (Does anyone know why GCE doesn't have a eu-west-1a? only b,c,d? I'd be curious to know the story there... not trolling -- just curious.)
Graph 2: c4.large has 2 CPUs... n1-standard-1 has 1... comparison on price is strange? Your point below about optimizing for manageability doesn't really make sense to me as manageability would stem from config/deploy/etc. -- not from instance type? Perhaps your language isn't clear. You're anonymous but I'm guessing english is a second language for you (judging from sentences in post) so it's possible we're missing your point there. Could you clarify please?
>"an ancient virtualization technology" source? details? KVM came out in 2007. Xen came out in 2003. I don't consider either of those dates particularly ancient but whatever it's your post, use the language you want.
Graph 3: A c4.4xlarge has 16 CPUs, and 30 gigs of RAM. An n1-highcpu-4 has 4 CPUs and <4 gigs of RAM. Comparing the two on price is disingenuous. Your claims that these are the "production instances" don't make sense to me.
>Network Heavy: So this is a test between two t2.micros in different AZs: https://s3.amazonaws.com/ranman-code/2016-11-20+00.58.23.gif
It shows 1gbps... I ran it literally a minute ago...
So that's 1gbit... Do you mean inbound from public internet or outbound to public internet? I created an n1-highcpu-4 and had it talk to a c4.xlarge at 1gpbs in (both in eu-west) so your claim that you need a c4.4xlarge for 1gbps seems dubious.
Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 7.40 GBytes 1.06 Gbits/sec 1297597 sender [ 4] 0.00-60.00 sec 7.40 GBytes 1.06 Gbits/sec receiver
It actually seems like Google's network was the limiting factor there because when I ran a similar test on a 10gpbs instance I couldn't get faster than 1gpbs. Which is fine because that's what's advertised -- just pointing out that the need for a c4.4xlarge is wrong. On a c4.large I got 900mbps.
>C4/m4/r3 have a hard cap at 220 mbits
This one is just false. What am I missing here? Where did you get this info? From eu-west-1 to us-east-1 I get faster than that using public routes and t2.micros. Internally across availability zones I get much faster than that.
Local SSD #s: Use PIOPS volumes, tunable size, lower cost, can attach to any instance type. Also consider the numerous other instance types that offer ephemeral SSDs.
>It is quite flexible. For instance, we could recreate any instance from AWS on Google Cloud. I don't think you mean any instance... but ok sure!
>Amazon does everything wrong, and Google does everything right, A message by an employee from Amazon than Google, not directly relevant but still a good read.
^ I don't think you read the above post when listing it as a reference. The title is ironic. Steve Yegge quit Google. Famously... on stage... He also goes on to say that Google can't do platforms. I'm sure that's changed in the past few years though.
In the end I'm super excited about both AWS and GCP they both have awesome products. I encourage people to continue researching and writing posts around these topics. It's hard to not take some of the criticisms personally when you're passionate and invested in your work (at least it is for me). I've got a google employee DM-ing on twitter calling me "petulant child" among other things. We don't need that. It's not helpful for our companies and it's not helpful for our customers.
I'll encourage everyone to tune in to the reinvent livestream on the 29th, 30th, 1st: https://reinvent.awsevents.com/live-streaming/
> Does anyone know why GCE doesn't have a eu-west-1a? only b,c,d? I'd be curious to know the story there... not trolling -- just curious.
Just guessing (I've worked on GCE for a bit over three and a half years, but I don't remember the history here) -- I suspect that it was a zone that existed prior to GCE going generally available that was turned down and there was a desire to not re-use the name.
> c4.large has 2 CPUs... n1-standard-1 has 1... comparison on price is strange?
Well, ok, but a custom 2 vCPU instance with 3.75 GB of RAM is $45/month (including a 10 GB PD root volume), so still nearly 50% lower than the c4.large price.
Similarly, if I build a c4.4xlarge equivalent custom instance type (16 vCPUs and 30 GB RAM) it's $358/month, again putting it at just about 50% of the rack rate for a c4.4xlarge.
I'm not sure where the OPs claims were coming from for networking. Certainly you can get 1 Gbps out of relatively small EC2 instance types, although at a virtual NIC level GCE is considerably more generous, providing virtual 2 Gbps/s/vCPU link speeds (so up to 8 Gbps for a 4 vCPU instance versus 750 Mbps for a c4.xlarge). Bandwidth-to-the-edge will be lower. That said, when trying to find an upper bound on bandwidth it's really best to test (regardless of which platform you're evaluating) with multiple streams ideally to multiple peers. Single stream can end up limited by a number of factors including RTT and congestion window scaling bounds as well as getting unlucky in terms of ECMP path selection for multi-path links.
> Local SSD #s: Use PIOPS volumes, tunable size, lower cost, can attach to any instance type.
PIOPS volumes are EBS-SSD, not local, aren't they (looking at https://aws.amazon.com/ebs/pricing/)? Our analog would be PD-SSD. GCE PD (including PD-SSD) IOPS scale with volume size — let's say you needed 20 GB of storage at 10000 IOPS. On EC2 you'd be paying $0.125×20+$0.065×10000 = $652.5. On GCE you'd need to buy a bigger volume, at 30 IOPS/GB for PD-SSD you'd need a ~334 GB volume. However, at $.17/GB you'd get the same 10000 IOPS at $57/month — for this example EC2 is more than 10x as expensive, and if we scale the storage up so you get the same 334 GB on io1 EBS PIOPS SSD it's more than 12x as expensive.
I picked these numbers somewhat arbitrarily; EC2 would've come out looking better for very large volumes with very low performance requirements, but with PD-SSD priced at $.17/GB and io1 volumes priced at $.125/GB + .065×1IOPS = $0.19, io1 volumes are still more expensive even at the lowest IOPS bound (above 1GB they get cheaper, but only below 3 IOPS). General purpose SSD is cheaper than PD-SSD, so I suppose for users who can live without a performance SLA it might be a good choice, although at that point I'd be tempted to benchmark it against our vanilla PD offering.
You can also attach GCE's truly local SSD (as opposed to PD-SSD) to any instance type (with really fantastic IO performance -- up to 680,000 IOPS read perf with multiple volumes), although I'll grant you that the 375 GB granularity is a little... coarse.
> source? details? KVM came out in 2007. Xen came out in 2003.
To be fair, GCE doesn't exactly run on stock KVM (nor, I assume, is EC2 running on stock Xen), and our userland is not qemu. I don't think it's meaningful to try and assess these technologies from the outside[0].
> Steve Yegge quit Google. Famously... on stage...
He didn't, he just switched projects... he's still at Google. He went on to say that Google couldn't do platforms; one of my favorite things about working here is the company's ability to be introspective and recognize when a rant like Steve's has more than a grain of truth to it. Google adapts. I think comparing the GCP APIs to Google's historical API efforts makes it abundantly clear that Google has improved by leaps and bounds at building a cohesive platforms.
[0]: I do lead the team that owns our virtual NIC and a chunk of our host dataplane in addition to prior involvement in broader aspects of our hypervisor architecture, so I'll admit to more than a little bias on this front :)
Who of the cloud companies is treating California as a first class citizen?
Pick whichever service has the cheapest TCO, not what some paid blogger says.
Having the smallest Windows VM on AWS is like 6-7$/month, whereas on GCE you're at at least 14.60$ higher due to the license.
A quick comparison of GCP & AWS :
The services & flexibility of options offered by GCP is not even in par with AWS. Yes I may be able to spin up a couple of VMs but when it comes to enterprise GCP can't be an option. It is like buying the new macbook pro and can't add more than 16gb memory! A designer for sure needs more ram regardless even if Macbook pro is offered for free.
- There are about 50+ 3rd party offerings in Google Cloudlauncher compare to thousands in AWS Marketplace! - Choice of server/OS! maximum 8vCPU-7.2Mem in GCP compare to 192 vCPU and 2TB memory in AWS -NoSQL Big table ( max 30 nodes) - compare to ( virtually unlimited DynamoDB) -SQL (only MySQL in GCP ) compare to ( Almost all with exception of DB2 in AWS). - and so forth - Just having Lambda, F5 support is damn good reason to go for AWS regardless of how much it costs. Those are the basic needs of SMB that google can't even offer. - 60 day trial and 300 dollar limit! compare to 1 year
The whole point of moving to the cloud is to have no limits and be able to have access to resources whenever you want. Google offering is very limited for now. This is just a lame marketing move by google and I hope they first fix their offerings and then compare. I can go to godaddy and say I'm cheaper maybe! Just check the list of services offered by both and see which one should be considered for a serious customer.
We are all professional and judge products by testing them, open an account in both and judge by yourself. When I started using GCP it sounded refined for basic services but when it comes to Bigdata, monitoring I did not find the console very integrated nor usable.
Want to clarify a few things though:
> - Choice of server/OS! maximum 8vCPU-7.2Mem in GCP compare to 192 vCPU and 2TB memory in AWS
The biggest instance on GCP currently is 32vCPU-120GB. Also, with custom machine types you can tune your machine and pick exactly how many cores / memory you need; you are not stuck with predefined instance types.
Curious what OSs AWS supports that GCP does not?
AWS definitely has a better vertical scaling story though.
> - NoSQL Big table ( max 30 nodes) - compare to ( virtually unlimited DynamoDB)
BigTable and DynamoDB are not really comparable. BigTable is much lower level. The apples to apples comparison is DynamoDB and Datastore, and Datastore is also unlimited.
> - 60 day trial and 300 dollar limit! compare to 1 year
I'd also like to see a longer trial for GCP, but the AWS trial gives you 1 year access to basic usage. With GCP, you can spend the $300 any way you like. Personally I'm not sure which model is better or worse, though I lean towards the AWS model.