Slightly unrelated, but since there seems to be some Google Cloud people in this thread: I see that Google Cloud account is linked to my Google Account. What happen to my Google Cloud instances if my Google Account got suspended by Google due to other reasons (e.g. Pixel stuff from the other day, or because of YouTube, or etc.) and I did not bought support tier?
On GCP, you create a separate Project entity that can have any number of Google Accounts linked to it. In that way, the actions of your personal account don't affect the GCP project (and vice versa).
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.
> On GCP, you create a separate Project entity that can have any number of Google Accounts linked to it. In that way, the actions of your personal account don't affect the GCP project (and vice versa).
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.
That is great advice. I have the same setup, except I use OVH instead of AWS because the cost is much lower, but still meets my needs (AWS, GCP, and Azure are all great services that I have used, no criticism intended).
> you can establish a service account with Owner level access
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?
I am compelled to create a HN account just to relate the below.
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 :-)
Google Cloud Support here. If you create Cloud project with a single owner (email), and that sole owner's account is deleted, the project is considered orphaned and will first be suspended, giving you some time to get touch with us if this was not intended, and then deleted after around 6 weeks. (Most running resources are stopped at suspension, but account data hangs around until deletion.)
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).
That is good to know, however my first reaction when reading this is we shouldn't be using G Suite for admin@corp or bob@corp, but rather if I am going to be seriously dependent on Google Cloud I should perhaps move e-mail for said @corp to Office365 (or whomever else actually does e-mail these days). I don't know what the solution/answer is here, but it worries me that actions (yes even bad spam-y TOS violating actions) that someone takes using our company's google accounts can ripple across the Google ecosystem and screw important parts of our company's infrastructure.
YMMV (and this is my personal view, not necessarily Google's), but in general you want to have resources associated with active owners. Otherwise when Bob leaves, and his zombie solo project which you no longer have any control over gets pwned, you're going to have an even bigger problem.
No one's denying that orphaned projects are a problem, but if deactivating an e-mail has downstream effects like this, you'd expect a warning or something before permitting account deactivation.
In my case, where the email was hosted in Google apps, it would have been helpful if Google apps had checked with GCE before allowing email deletion. After all, this is one of the situations where being within Google Eco-system should have been a good thing.
Agreed. Or force the user to have two registered e-mails in a GCE account at all times, unless they're explicitly deleting it. Doing things implicitly with no warning is simply terrible UX.
Why does Google not say "deleting this email will destroy these accounts attached to it"? Surely it can't be too hard to find which accounts an email is attached to, then check those accounts for other owners?
Why doesn't GCP force you to do this if it's best practice for anything remotely important? Surely your target customer generally is doing things that are quite important for them.
An email account could have ben recovered. Or you could have established identity of the user some other way, e.g. the credit card or the billing address.
This is triggered when the user account is deleted, not if they can't login/are suspended, for which the usual account recovery mechanisms apply.
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.
Look, if I a company owns BAR.COM and they delete FOO@BAR.COM they could recreate that account. Any other service in the world tied to that address will be recovered, except Google's own service.
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.
I don't have any experience with GCE but I do have a lot of experience with AWS. What does an email id have to do with your cloud resources? "We now don't delete any email ids" implies you are worried about the same happening again. This makes me wonder why you don't confidently know what an ID is associated with so when you delete you are confident about not breaking anything else.
I think it could be viewed in a different light. It provides a real sense of control over resources (which should be well documented in the first place). If there are rogue resources and objects being utlized unauthorized in an organization it makes it short work to eliminate such things.
As someone whose google account is tied to a scary number of services, e.g. our company's G Suite, Fiber, Music, Play, Store, Cast/Home, Nest, Adwords, Analytics, Webmaster Tools, etc., and is in the process of migrating a bunch (but not by google standards) of data and instances from AWS to Google Cloud the thought that some screwup in some random service gets my account obliterated and my company loses access to our Google Cloud resources (because I'm the admin account) scares the !*^%# out of me.
It's like certificate authorities - it's awesome how easy it makes things if you can trust a single authority. Until the day you realize you can't actually trust it.
This is mathematically misleading. SSO adds a single global point of failure on top of the existing system. Single nodes will still fail in both circumstances, unaffected by the use or not of SSO.
There still are infinite points of failure with SSO. Each service would need a trust relationship established with the SSO provider, any of which is a point of failure.
For corporate accounts, I want the various cloud services to use systems that have been around since forever and a day. I want to be able to use systems like Kerberos to give Google Apps a service ticket so I can manage passwords on my server, with google only getting what user has successfully logged in. The cloud has set us backwards in single sign on, since everyone wants to be the gatekeeper.
My Google account got suspended and I wasn't able to log into GCP. Instances kept running but obviously it's a lame duck when I had no management access.
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.
You should use separate accounts for a business. If you want to sell someday, you'll be glad that you don't need to go through your accounts and delete 35k personal emails.
Yes, I agree that I should have a separate account for business. But my concern was that Google has a lot of products and services that I'm not sure where I might tripped the trigger that got my account suspended.
For example, if my business email were hosted with G Suite, and my admin G Suite account got suspended for some random reason.
Making separate accounts might not be enough considering they allegedly banned accounts related to each others by recovery address. Why would you think they would not do the same with accounts sharing occasionally the same laptop, the same ip address, and the same first and last name ?
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.
This is a great question. Common sense wise to me it's an issue. And given how large a company google is I don't think it even matters what the google cloud people who might respond say. It makes sense to simply isolate things like this.
Slightly related - had a AWS account, the account tied to it was for business use only - at some point I had credits/balance on the business account and someone gained access to the regular amazon account and bought some digital goods, so I notified amazon. They locked the account AND locked me out of AWS. This particular account was not important, but it took weeks to get access back.
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.
> Alternatively never had this issue when I've COLO'd
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.
I don't think that should be a concern as both providers in theory can block or suspend your account. Maybe use a separate account for Google cloud for running world-changing-billion-user app.
That's why like most people publishing an app to the Play Store, I created a separate account just for this purpose.
That way even if my account gets nuked for a reason or another, I won't lose half my digital life.
same principle for GC.
From what I understand, your google account wouldn't be suspended. It would be the individual services that could be suspended. Like you would still be able to access gmail if your YouTube account was suspended.
This. I don't want to end up pleading like a beggar to the google reps (or chase and plead to google employees on endless forums) to enable my sites (or worse, my clients' sites) which are disabled by google because their algorithm detected some "suspicious" activity on my gmail account.
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.
I'm curious if you speak from experience, or from the one article, where a customer let ports open, his VM was taken over by hackers, and proceeded to DDOS the world :)
"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).
I didn't see any mention of Google's preemptible instances.
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.
One thing I forgot to mention is I've had a couple of "we will shut you down" emails.
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.
We pay 10+k/mo for our AWS support, and it has never paid off, even with multiple phantom errors and failures... the top level support supposedly being paged out of bed for me doesn't have answers. Always had to simply restore from backup without a good report to share with mgmt.
Agree. It takes an act of congress to get through to an actual AWS engineer. AWS status site is a joke with how degraded a service needs to be to register a change: https://status.aws.amazon.com/.
That's deeply concerning. Can you pls share your aws account ID with me? If you're not comfortavle doing that, pls share email ID where I can contact you. Thanks.
I have gotten both stellar and not-so-stellar replies from AWS Support. They used to be slower than ideal but these days it's pretty good. We also have a great line of communication with someone who coordinates SAs to help clients (not sure what his title is) and he can get stuff escalated/sped up. For the most part, we haven't needed that despite his repeated offers to, except in one case, when he was quite insistent which it turned out was for good reason.
Either way I would greatly rather deal with AWS support than Google Support, which as far as I can tell is an oxymoron.
AWS support has been rarely worth the cost in my various stops. Even at the highest support levels. Slow responses, having to deal with people sticking to support scripts, etc.
Probably speaking from general experience with Google customer support, which is generally opaque. The few times I have corresponded with Google customer support it's been bad.
This is a common sentiment, but I have to say that it's not in line with my experience as a Google Apps/G Suite business customer. If there is an issue, I simply call the phone number, get a competent support representative promptly, and if they can't resolve the issue on my first call, they will follow up and stay on the case. I haven't used GCP yet, so I don't know whether the support will be more like your experience or mine, but I'm confident that Google does have the ability to deliver good customer support.
I'm speaking from my experience of losing access to my YouTube account (same username as I have on this forum) due to having used my gmail address to sign up. Google later started linking everything to plus and somehow my gmail account spawned a new YouTube profile that clobbered my old one.
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 can confirm that first hand; We're just moving our whole stack from AWS to GC and right now we're running everything in parallel with roughly the same amount of resources. AWS monthly bill: ~$1000, GC monthly bill: ~$600
I would say around 8, but then again, the goal was to use Kubernetes (which we do on GKE), so much of the time was spent configuring it, and we'd use at least some of that time even if we stayed on AWS's container service.
[EDIT] Plus I'm the technical founder, so enjoy this stuff, which means a lot of the work was done in my free time.
You're just missing it. Take a walk around the block some time. Time is more than free when it is your own, especially if you're learning something new or enjoying yourself.
I disagree. Taking a walk around the block is time spent doing something that could be spent otherwise. Everything in life has a cost associated with it. I am not saying a walk around the block or spending extra time at work are bad decision. My point is no time is free, you are always trading one thing for another. Going to the gym, you could be studying. Studying, you could be growing your business. Growing your business you could be spending time with family. Its all a balance in life but to claim your time is free is naive of reality.
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.
Yes it is a balance, but it's important that we always be mindful not to get caught up in the rat race. Life is a beautiful thing in of itself and shouldn't be fractionalized to achieve maximum ego-gain, nor should it be entirely mismanaged that it dishevels your ego completely.
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.
The original was about how much cost is involved in something and what the break even point is. toomuchtodo asked a financially specific question. The reply to that question was vague and added that part of this cost was done in "free time".
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.
I'll bite. I didn't downvote, but I feel that your thinking is relatively binary and doesn't take the dynamism of humans into account. I can throw study material onto a playlist and hit the gym. I can go to my kid's dance recital and hit up the other bored parents there with business prospects. I can turn over programming ideas while I'm taking a shower.
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".
If you always require a short-term win, you will lose in the long-term. When the company is 100x the size it is today, the savings are quite substantial.
True, but if you DO hit that magic growth factor, it'll probably be too late to make a change of such magnitude. Better to get optimization experimentation out of the way (relatively) early.
For nearly all businesses the cost of service hosting is going to be similar to the amount spent on snacks. This seems about as useful as optimizing the brand of cereal you buy.
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.
Agreed, we have 10 instances on AWS, but it's hard to judge the complexity of the migration just based on that because these servers vary in size, requirements, and purpose.
But all in all, yes, it is a fairly small scale migration.
Generally speaking, the number of servers has very little to do with complexity of migration or existential threat from downtime, relative to company size.
Just curious, what type of AWS instances you use? And also is it on-demand instance or reserved instances? I'm using AWS for couple of years, exploring other options.
On demand: m1.medium mostly for Rails and Node apps and db.m3.medium for RDS (Postgres).
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.
m1.medium? That's two generations ago. Just by switching to m3.mediums, you'd get 23% savings. If you could see fit to switch to t2.medium, you'd be saving 40%.
Agreed - primary motivation weren't savings, but much smoother UX with Kubernetes on Google. We're adopting container-based approach to development (and DevOps), so we explored alternatives, and chose Google Cloud.
Thanks for sharing your experience. Why, acc to you, is Kubernetes on AWS a non-starter? Is it too difficult to setup? Or maintain? Or simply isn't the first class citizen, like it's on GCP?
Or does it just make sense to stick with GCP since K8s has Google's blessing?
Two reasons really, the first is that AWS has become this bloated mess of "stuff", making it increasingly harder to use, because so much time is needed to either constantly look at it to see what's new/changed or vigilantly document everything. GKE, based on my experience, uses more "convention over configuration" approach, so the UI is much less cluttered, easier to understand, and comes with good defaults out of the box. And yes, K8s is a first class citizen on GKE and it overall fits nicely in the google compute engine environment.
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)
Thanks a lot for taking time to respond. I've a couple of clarifying questions:
> 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.
I'm not referring to any specific offering, but just the sheer amount of ways to accomplish things on AWS - and the docs don't help, I urge you to compare (or even time) the process of following the docs in setting up AWS versus GKE clusters. You'll notice the process is much faster with GKE, especially because the docs include at least some real-world examples, compared to AWS where the documentation is almost completely abstract.
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.
Nope, but it illustrates my points perfectly. A company like Amazon should have hundreds of those, with real use cases that developers (or DevOps) care about. For instance, I have a Rails/Node/Go/whatever app. How do I deploy it using any of the available services? Which one is preferred? Why? What about the connecting services, like Postgres+Redis? (I know there's an offering for everything, I'd like to know how it all fits together, best practices, etc)
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)
If any cloud project was a single dimension problem. For me it does not matter how much cheaper I could run an instance in GCP simply because we rely on services from AWS that do not exist in GCP yet. Another issue for me with Google is how they handle account problems. I do not want to find out the hard way that I should have done some extra safety measures just to keep our entire production environment safe. With AWS I do not need to worry, their customer first approach proved to be extremely useful over the years, and they were very patient with us even when we did something that was against their policy. My customer trust is not something that is up for sale and I have been disappointed with Google's customer support several times, this is simple cannot happen in a cloud infrastructure situation. I like GCP and Azure because they make sure that I get a good deal on AWS.
Does someone know why Google Cloud can afford to be so much cheaper compared to AWS? Are the costs to Amazon for AWS so much higher than the costs to Google for Google Cloud? Why?
AWS is actually a pretty high margin business (~25% operating margin is public, GM is not publicly known but good guesswork puts it ~50%). So, there's some hard data showing a lot of room for price competition.
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.
Plus they have a real customer service culture, something Google seems allergic to.
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/
>Amazon is a much more formidable competitor than MSFT.
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.
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.
> why is it still so far behind AWS? Why did AWS start literally 10 years before GCP
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.
Worked on google mars in mt view in 2011. Internship.
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.
I try to engage in dialogue, reach folks, provide factual information, and gather feedback on how we can do better. I offer folks to contact me directly. I also try to make it very clear who my employer is, through either direct note or clear context.
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 :)
It would be desirable that Google has a decent margin in its GCE operations, otherwise there is a high risk that they cut it back or even shut it down.
I know Google and a couple other companies are designing their own hardware to reduce overheads like power and square footage. Does Amazon do the same?
One of the things I've heard (from googlers) is that by using KVM as the underlying hypervisor, they do live migration much better than Amazon. Using that, they can live migrate applications to the same servers and bin-pack much better. This allows them to squeeze more jobs onto the same hardware by leveraging their already dominant lead in machine learning to predict workloads.
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.
> Does someone know why Google Cloud can afford to be so much cheaper compared to AWS?
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.
The same reason that Google could launch Gmail with 100x as much free storage as Hotmail: Google's physical infrastructure is dramatically less expensive than everyone else's.
IIRC I think I have seen some people here argue it is because they have close to no customer support.
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.
Our support folks can comment here, but I would disagree with that point. Our support org is massive, there are varying tiers levels of Support SCE/CRE/SRE/SWE-level of support, all the way up to [0].
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.
> It's not unusual for an engineer in charge of a service to help resolve a customer an issue.
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.
> It's not unusual for an engineer in charge of a service to help resolve a customer an issue.
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 actually was not comparing Google to Amazon here, apologies if you got that from my post. I was mostly responding to the parent, whose argument was that Google is so much more inexpensive than AWS because Google doesn't invest in support. My experience has been the opposite.
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.
Perhaps I read too much into something you didn't even mean to compare. Sorry about that. Thanks for clarifying statements and generally taking time to respond throughout the thread.
I am not sure that you can really use the size of your support org when talking about customer experience. Why don't you come up with a 3rd party customer survey about how your customers are happy with you compare to Amazon? If you are absolutely certain that your support is great it would prove the point.
I agree, size of support org is probably not directly correlated to quality. I was mostly responding to parent, who made the argument that Google can afford to be inexpensive due to lack of investment in the support org.
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.
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'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.
Well, AWS has only billing and account related support for free. Any other support is, of course, paid. And it'd be best to avoid commenting on their free support.
I'll toss my personal experiences in as well: we pay Google for support at the 'Gold' level[0] and we've been satisfied with the support they've provided. We've only had a few issues but they've gotten back to us quickly and it's been easy to access their technical staff.
My guess is economics are trying to steal AWS business. Low pricing will draw a % of AWS customers over to GCE and the prices will balance out. Frankly I am more interested in Google's support quality compared to AWS. I don't have any experience with Google but I know Amazon is founded on the premise of customer experience which carries into their support. How is google's support?
I am not familiar with GCP support but with their product support. Once I bought a device from Google and it broke on the first day. The device was completely dead, did not even turn on. When I engaged their support and explained the situation to the customer representative she kept asking me which light is on even though I explained to her 10 times that the device is completely dead. I was lucky because I bought the device through Amazon. I visited the website clicked on the dead device needs to be replaced button and in 10 minutes the replacement was on the way to my home.
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."
AWS is expensive as fuck. If i move the structure of one of my websites to AWS i would get my 99.99% uptime instead of boring 99% but it would cost avout $400 dollars instead of about $50. But sure thats missing the fact that i hafs to self manage right now.
It's Google using their typical strategy: spend lots of advertising cash to develop and then provide something for free / less than competitors, with the goal of pulling you into their ecosystem.
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.
Your latter point is not really a point at all. There is vendor lock in at every corner with AWS. The big 3 all do this.
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.
I've worked with both AWS and GCP (my day job is working on Cloud Foundry).
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.
In every area that I've looked, GCP is so much better than AWS that it's offensive, bordering on obscene
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.
> In every area that I've looked, GCP is so much better than AWS that it's offensive, bordering on obscene.
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]"
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.
Jacques doesn't speak for all of Pivotal. Its of course his personal opinion that GCP is way ahead of AWS. And Jacques, personally, is entitled to his opinion. There might even be merits to his statement here but he hasn't backed it up at all with data.
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)...
It is correct that unless I explicitly say otherwise, I do not officially speak for Pivotal. It'd basically be a terrible idea to give me an official mouthpiece, given how bombastic I am.
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.
Appreciate your feedback very much, and apologize if my opinions were a little too bombastic themselves. I saw an AWS employee disparage a customer opinion, without disclosing their allegiances, and wanted to set things right :)
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.
I like people who are critical and honest with their assessment. I value your opinion very highly, since you claim to have experience with the tools you are assessing.
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.
Remember, I am frequently wrong and fond of bombast.
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.
Again, a weird thing for an AWS employee to say about an opinion from an AWS customer and an AWS platinum partner, and then accuse them of expressing those opinions due to monetary compensation.
shame on you both.
you are biased to google, but I actually preferred the AWS documentation.
I still will migrate sooner or later to GCP, because of the superior pricing model. However missing postgres is still bad for us and we don't want to "go trough a partner". Cloud is already not so cheap, especially when we only need 3 boxes and a database. The problem is there aren't many alternatives that lets you have a managed database and 3 boxes in your own small network. If you want to do it yourself you either need a VPN or you would pay the same price as a Cloud if you want to interconnect hosted servers on non Cloud providers.
merb, I apologize for getting a little heated. I saw an AWS employee attack a customer opinion (without disclosing their employer), and I wanted to set things right.
On the feedback, I hear you. Please reach out to me offline for a further discussion (if you want).
I'll disengage... this argument doesn't really serve our customers well. I'll fully admit that the AWS docs are a pain... but to claim that the google docs are better is... I lack an appropriate adjective.
holy shit you two are embarrassing as hell. absolutely cringeworthy. I'd half consider migrating to Azure since it seems they're the only adult in the room... too bad it's such a terrible service;)
You're right, I crossed the line and sincerely apologize. I post here on my own time, and represent my views only.
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 :/
In any comparison on "cheapest way to run a linux box somewhere" I would expect AWS to lose. AWS is a platform, not a server rental service. You start to see value when you build to the platform.
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)
For me the two big things missing from Google Cloud are a PostgreSQL service and a Redis service. I'd also need an alternative to CodeDeploy, but I think I could something that wouldn't be too terrible to self-host.
> in many ways far ahead of competition
Yep. In my experience, when Google Cloud does something, they do it right.
For those devs who need to convince senior management and big clients “managed by a partner“ does not cut it. They want to hear a reliable name like Amazon or Google. A small unfamiliar brand doesn't give them confidence on reliability front. Many of these people have paid to MS and Oracle just for this purpose. For example on Google's G Suite FAQ there is a big document which details out the elaborate measures Google takes on security front and about no unauthorized access to data. It's unlikely that a smaller third party partner will have same diligence as that of Google or Amazon.
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 also found that it's easier to launch an Elastic Beanstalk Docker app with a Postgres RDS instance. I'm hoping Google's Flexible Environment will address this, but I was not able to get it to deploy. To be fair, I only tried for a bit yesterday and gave up.
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.
No, that is not correct. Direct Connect is a superset of functionality to Cloud Interconnect. Specifically, RFC 1918 networks over BGP on physical links are missing from Cloud Interconnect. Google engineers have a plan for this functionality and a code name. No date estimate has been made available (at least to us).
Even when the comparison is with a web-hosting provider such as GoDaddy or Digital Ocean? I want to host a few custom developed web apps on a VPS and I'm confused between AWS and DO/GoDaddy. Which one would you suggest?
Web apps on VPS sounds like something fit for micro or tiny instances, in which case a month pre-commitment might actually be cheaper if you look at OVH's Kimsufi programme: https://www.kimsufi.com/en/vps-ssd.xml. These are cheap, but in my experience reliable (after multiple suboptimal experiences with DO) KVMs.
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.
I would suggest a DO droplet since the learning curve is very small compared to the AWS services, the cost is predictable and they have a decent bandwidth allowance.
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.
This. Some of my clients are on one of the spectrum with lots of PaaS offering in use especially features such as queues. Others prefer to be agnostic and won't use any specific features. I guess it depends on what you want and how comfortable you are administering Rabbit etc.
We use many services on AWS (S3, ELB, RDS, RedShift...). The costs of the EC2 instances is > 70% of the total bill. It's in the same order for the other deployments I've seen.
The thing is, the AWS pricing strategy is global and most services are built on top of instances.
I hate it when the evangelist swarm the hackernews comments.
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.
"The numbers given in this article do not account for any AWS reservation"
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.
Actually, because you've got to pay in advance a certain amount to get the reserved price, we calculated at my last job that buying on-demand instances was actually cheaper than paying the reserved instance pricing listed, because of the rate at which AWS drops the price regularly. Meaning, if you compare the reserved price with the amount you would pay for on-demand instances and subtract the amount you save when Amazon drops the price (which they do pretty regularly, and have in the past), the on-demand price actually ends up being cheaper in the long run.
I think you meant "on-demand", not "spot". Spot is hands down cheaper. Reserved saves you 30-75% depending on instance type and duration. Spot instances save 85-90%.
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.
Hah, I don't know how you were able to see my first edit. It was up for less than ten seconds and I didn't have your comment for some time after I edited it!
"Anyone intending to be a serious user of AWS will use reservations."
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.
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.
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.
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 ^^).
This article is interesting and the author has some good points about the lack of small non-burstable instances in AWS. There are plenty of things to gripe about.
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.
> 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?
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.
Does anyone know if there are any plans to support Postgres by the Cloud SQL? Because currently it's the major deal breaker to me. I have a SaaS business that works on Postgres and we don't plan to replace it with any major SQL alternative.
There's some indications that Google would support Postgres as part of the CLoudSQL in the future. But there are already multiple DB-as-a-Service offerings that provide PostgreSQL in Google Cloud. My company, Aiven (https://aiven.io) is one of the providers and I believe Compose, DatabaseLabs and ElephantSQL also provide managed PG in Google Cloud.
I want to like Google Cloud, but it just seriously lags AWS.
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...
I recently visited the google cloud pricing page and had a hard time making any sense of it all. The pricing isn't at all clear. DigitalOcean on the other hand, you take one glance at their pricing page and know exactly what your getting. Google can learning something from that.
Thank god I'm not the only one. I keep hearing about how opaque AWS pricing is compared to GCP, yet I personally cannot make any sense of google's pricing. It's difficult to explain, but I struggle ti figure out how much I'll be paying over, say, a month for a GCE instance. It seems like there are too many variables to keep in my head.
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...
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.
How much do google use their own cloud internally? I'm curious and would better appreciate Google Cloud if I could see it being dogfooded with something substantial.
My understanding is GKE on GCP is kinda sorta a rewrite of the Borg system Google has used internally for years. Internal services at Google are encouraged to use GKE, but there's little incentive to migrate from the Borg infrastructure that has a long track record for reliability. So currently only a marginal amount of Google services use GKE, but as old services are retired and new ones developed, the share of services on GKE should grow steadily over time.
Comparing only instance prices is not fair, imho. Amazon charges that because all of the services/ecosystem they have. Google Cloud is stepping up their game though, leading to cheaper prices in AWS.
Amazon has a very broad offering of great fully managed services, but Google's no slouch. In fact, many of Google's offerings can be very compelling - BigQuery, Bigtable, CloudML, PubSub, GKE to name a few.
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)
I'm not sure I'd agree that Google has a broad spectrum of instance types. You can boost up individual components, but for example if I wanted an EC2 instance with as much local SSD space as I can get I could have 6.4 terabytes, while on GCE I could have 3 TB. If I want memory, Google's willing to give me 200GB, Amazon offers 10x as much.
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 a good point. Amazon does give you a better "vertical scaling" story. I'll still challenge you on the "breadth" when it comes to EC2 - the philosophy is just very different. Why do you need a "IO optimized instance" if you want just fast disk - that notion just seems very foreign and arbitrarily-constrained on Google Cloud.
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]
The real problem I have is the low network performance. Yes, yes, before everyone jumps all over me and points to Jupiter etc.. I understand the problems in Pb/s bisection bandwidth for the large datacenters. That doesn't change the fact that I don't need an entire datacenter worth of stuff.. but I do need an Amdahl-balanced cluster. So big machines with wimpy (20Gb non-RDMA) networks prevent me doing my HPCish workloads on GCE.
Followed by waiting on GPUs and other user accessible accelerators of course.
AWS spot instances are a fraction of the price, like 20-30%. In my experience, building the same processing cluster from AWS costs half as much as Google Cloud.
Which is why I find it so annoying when I see these price comparison articles that don't really use the SpotFleet API correctly.
Agreed. The value of AWS is not in the cost of the instances it is the services and customer service which go along with it. Its all of the easy manages services that add up. Its the combination of RDS, SQS, and all of the other features that add up. Sure each EC2 instance may be more expensive, but there are huge savings in time (which is more valuable) elsewhere.
Does anyone know how much of Google Cloud works inside of China? So, would my webapp be accessible from the PRC? And what about services that come from a Google API such as voice-to-text or translation, managed database and so on?
I've used GCE for production servers in the past and was really pleased with almost every aspect. I have really little "serious" experience with AWS, and I'd say it's much more.. um, arcane?
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")?
Is there a spot instance-like mechanism with google cloud? I regularly request high memory spot instances (r3.8xlarge) on AWS for 1-2 days processes (genomic analysis). With spot-pricing it can be pretty cheap.
A very clever way to run genomic analysis on GCP is via WDL ( https://software.broadinstitute.org/wdl/ ) workflows executed on the Cromwell ( https://github.com/broadinstitute/cromwell ) service. Using WDL you define tasks, and compose those into workflows, then Cromwell executes those tasks on GCP using the pipelines api ( https://cloud.google.com/genomics/reference/rest/v1alpha2/pi... ). So you don't need to set up any instances at all, each stage of your pipeline, a task, is executed in its own docker instance, with files from google cloud storage being materialized on that instance for you. When that task is done, outputs are sent to cloud storage buckets, and everything is torn down.
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.
Preemptible Instances only can be used for a max of 24 hours, so would not fit the above usage pattern...though I don't know if AWS spot instances are really meant to be used for that long either. Of course both allow you to use the regular non-preemptible on-demand pricing.
Good article though I would disagree about AWS Reserved Instances. Though they are way more complicated, they can give 40%+ discount and in many use cases you can run quite a lot of them.
Isn't it true that those require a 1-yr or 3-yr commitment? You can't move a reserved instance to another region. IIRC, its tied both to a region and AZ.
OTOH, spot instances can be cheaper but then you should be prepared for those to vanish anytime.
As of September 2016, you can buy a convertible reservation that allows you to move a reserved instance to a different AZ within a region. Your greater point still stands but I just wanted to correct one piece of it.
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 gets a lot more challenging once you outgrow your initial reservations. Or maybe you find that you reserved the wrong sizes. As you add more reservations, it will become something that you are dealing with constantly.
Yes, you can. But doing this is not "free", in that you are spending time doing this (potentially often) instead of an infinite number of other more productive things.
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).
Does anyone know if either Google or Amazon provide credits for non-profits like Microsoft does [1] for Azure? I haven't been able to find any details but also not sure if it's something they do offline on a case by case basis.
It looks like AWS has a credit program for non-profits[0].
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.
The author of this article mentioned running a database server on raid 10 local ssds. I would whole heatedly recommend against this. There is no replication on locally ssd ( at all ). If there is a massive hardware failure there are still situations were all the the data on the local ssds can be lost.
( Disclosure: I would for Google Cloud Platform Support and have seen this happen on rare occasions.)
GCE is a great platform with many competitive advantages including networking, flexible configurations and sustained use discounting. However, I'd argue that using different data points and comparison criteria the opposite hypothesis could be made in favor of EC2 - e.g. burst instance/storage, spot and reserve pricing, local SSD and magnetic storage, and others.
I agree, you can go into higher granularity a-la-carte on both fronts.. but I don't think "spot pricing" is that, and neither are local SSD + magnetic storage (take a look at my local SSD post in this thread).
I would use Google Cloud Storage or S3 Storage but their Traffic charges are HUGE.
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.
GAE has serious problems:
1. security, everything accessible for everyone
2. billing, it stoped accepting my card an your ago without any notice, hover the same corporate card works for all other services
3. support it's 100% per cent useless. They cannot even fix anything, only claiming they have the same issue for the last 3 years (that's from my real conversation).
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.
The web interfaces for Google Compute Engine/Disks/Networking are much more intuitive. The pricing calculator is built right in. And - they offer free consulting services to help you migrate out of AWS. We are moving out of AWS to Google Compute Engine and it has really gone fairly smoothly and within a couple of weeks was already saving us money.
Is there another source for the 220Mbit/s limit for m4 class instances? I was under the impression that you could get enhanced networking with those, and double the speed when paired with placement groups.
sorry, but parts of this article are a bit.... dumb.
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.
Personally I just turn things off when they are not being used and that alone saves me 60% off my AWS bill. Obviously, it only works for non-prod instances but that is the bulk of what we use. see www.parkmycloud.com
last time I explored my options, setting environment variables (ENV) were hard to secure in Google Cloud, I had to push a config.json file that sits on the server? Whats the point of a cheaper price if I can't even figure out how to secure the app. There might be cost gains in larger apps but for the small app I am working on, I'm a big believer of using tools that make you productive and iterate over parts that makes sense. You shouldn't choose a technology like Go lang because its cheaper to run than Node.js if you don't know how to Go
I work at AWS and I have questions for the author about this post:
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.
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.
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.
Until bandwidth pricing is fixed rather than nickel and dimeing us to death; a lot of us will choose fixed pricing alternatives to AWS, GCP and Rackspace.
Note... I work on GCE. That said, numbers I'm posting here for GCE are from plugging custom instance and volume types into the GCE console on my personal account rather than anything formal (I'm on my personal laptop). While you can nitpick the OP's points, our custom instance types make it possible to do something closer to an apples-to-apples comparison, and by my math below (which may be wrong; the risk of posting at 1am) the 50% number still holds up if you ignore reserved instances, assuming the OP's prices for AWS were correct.
> 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 :)
My problem with Google Cloud is I find their pricing too opaque. Will I find myself with a huge bill overnight is my worry. Is there some way to get started with a cap on my monthly bill?
Bandwidth pricing, bandwidth pricing, bandwidth pricing for all the big cloud providers that charge by the bit rather than a fixed price; all of them are too expensive.
The only feature that any company can copy from a competitor without any effort is price. It is well known in product circles that you can't compete with price only, you need to put in other features that make your product attractive compare to the competitors. I am still waiting for something extraordinary from GCP that would make me consider them over AWS or Azure. Price - for me - is simply not enough.
Concerning the Virtual Machine pricings on the discussed platforms, I'd like to mention that – on very small machines – running Windows Server is significantly more expensive on Google Loud than on AWS or Azure, because Google charges you the license fee directly whereas Azure or AWS seem to have a mixed calculation.
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.
what makes me choose AWS, is i can survive a year using it without paying too much money, while in GC you got 300$ to spend in 3 months, which would get you more powerful machine for this period but you should start paying after it
so if you really don't have money to start with, you have to choose AWS
I test and use all 3 main public cloud providers. I keep Azure out in this conversation for now:
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.
I work for Google Cloud. I think a blanket statement claiming the GCP is 50% cheaper that AWS is a bad for all the reasons you stated, there is a lot more than just VM pricing you have to take into account! We are definetly working on a lot of the things you brought up, I hope this time in 2017 your experience will be very different.
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.
