Google Cloud vs. AWS Onboarding Comparison
kevinslin.com
kevinslin.com
My company has gone through 4 reps in 3 years. Every time we get a new GCP rep they just want to talk to us about "expanding our use of GCP offerings". The only thing they want to talk about is starting to use BigQuery - not my business at all.
I signed up for a Google Cloud Security summit, and afterwards a sales rep reached out me. It was obvious from the start they had no idea I was a gsuite or GCP customer. They then directed me to a NEW account manager (#4) even though I had been working with a different one. I had worked with the prior account rep going over our architecture to make sure everything was kosher (sustained use discounts etc). I even made them a schematic of our architecture on GCP at their request. Once I provided that to them I was met with radio silence.
It's really insulting, and to me obvious they don't care about my company at all. We're looking at other options.
I wouldn't be surprised if somehow this post leads to me getting an email from another rep "Wanting to start over and doing things right", which will inevitably devolve into the discussion of how can I use BigQuery.
Yep, drives me up the wall. We put a lot of work in making sure we're zero-downtime, pay for "Highly Available", and every couple of months I get the dreaded email. No explanation, nothing. Then we have to do the whole downtime dance.
If anyone from Cloud SQL is reading this, please, please stop doing this.
It’s insane that even with all of their HA and failover turned on they take the whole cluster down for as long as they like every few months!
To an engineer, things are things, because of how they architect and build them.
To an engineer who understands a customer, things are things and all the things people actually use them for. Big difference.
It also makes "Well, that customer is using it wrong" less of an exceptable engineering dodge.
When we first launched on GCP, there was no question that it was the way to go (frankly, because of BigQuery). Working with AWS, when we launched, was going to cost us significantly more up-front, before we had even brought on our first customer.
Fast forward 5 years... AWS has closed the gap in every way that matters. I still, frankly, trust Google's Security more than Amazon's, but I don't encourage folks to use GCP the way that I used to.
Just the opposite. In 2021, no questions asked, it's either AWS for general compute, or something more targeted if your business doesn't need it.
Until you get to the point where your bill is larger than a dozen engineering salaries, you won't get any respect from these people.
> I still, frankly, trust Google's Security more than Amazon's
If you have the time, could you expand on this? While I'm not directly involved in security at AWS, I'd be down to forward your thoughts to people who do.
My comments are mostly backed up by my experience at startups and are not colored by my experience at Google (too different a beast).
GCP is great for teams that are also using GSuite because you can set permissions at the level of a Google Group and have them propagate to individual members. You can, of course, also create groups in AWS but they don't have the same semantics of Google Groups and don't cover the wide range of use cases that Google Groups does.
The AWS scopes -> policies -> roles -> resources chain of abstractions is less natural conceptually than GCP's GSuite accounts + service accounts with attached scopes per project.
Also the fact that each managed service (GCE, GKE, Cloud Builder) has its own service account that you can attach scopes to is really nice. GCP service accounts just feel more discoverable than AWS IAM roles - I think it's because the number of AWS pre-built roles is so overwhelming.
Just some thoughts off the top of my head.
I’m sure they exist, but over the last dozen or so years I’ve worked with public cloud offerings across 5 or 6 industries and domains, I haven’t found a use case that can’t be easily implemented in the simpler GCP model.
AWS support is really nice. That I miss.
Top of mind things I found weak/weird: - Basically can’t do least privilege, only want a role to read messages from one pubsub queue? Nope not possible - IAM policies seem bolted on, legacy roles seem much better fit in the ecosystem, but they suck obvs. - different gcp resources have somewhere between very coarse grain to just acceptable iam operations. Might just be GCS that lets you do proper least privileges policies like you would do in AWS.
I was very surprised how bad it was, AWS IAM is some black magic shit that is deeply impressive and often taken for granted, even GCP can’t replicate.
The biggest problem I have with GCP is that something will say "you need the foo.bar.baz permission", and when I go to the IAM page to give that to myself... there is nothing in the search results for "foo", "bar", or "baz". Instead, I have to guess the "friendly name" for the permission.
Often the UI, and docs make it seem like everything is all over the place but AWS feels like lego with some pieces tucked away. That is where I think AWS can be improved upon with a better documentation UI and discoverability.
I do have to commend Google on Flutter + Firebase + Firebase Functions. I think if Amplify focused on serving Flutter users more it could pull me away from Google altogether.
Unfortunately, Google has done a fantastic job with making Flutter integrate with Firebase through Android Studio and there really is no product from AWS that matches its developer friendliness and low learning curve. This makes it very easy to switch.
I guess it is somewhat of a threat because the Firebase Cloud Functions also offer something of a counter to AWS Lambda as much as I love using it with API Gateway.
Integration with our org GSuite (this alone is a massive plus).
I trust virtually anyone's security over Google's. I've never had issues with AWS. I've consistently run into serious Google security failures. Google has airtight security for its own data, but not for its customers.
Examples range from Chromebook and Android security update policies (tons of expired machines on the public internet, in the case of Android, usually without people knowing), to pay-for-security on GSuite, to really difficult-to-audit Google Drive security (there's no convenient way to track and audit what was shared with whom or where data went), to just a ton of other things.
I've never seen Amazon be callous with my data. I've seen Google do things that even nineties "we don't need security" Microsoft wouldn't have imagined....
The only people I know who really trust Google security worked for or are close to people who worked at Google. There's a reality-distortion field based on how much Google invests in its own security that people fail to notice very basic failures, like millions of expired Android devices, or a lack of audit logs if someone physically accesses your machine to rifle through your gmail....
Nov 2019 - interviews
Dec 2019 - passed hiring committee
Dec to June 2020 - emailed recruiter every two weeks never heard back
June 2020 - cold email from recruiter “here is your offer letter to join Google! Let's talk team match.”
Needless to say I did not accept that job. This was for a software engineer role.
(edited to add line breaks)
Many weeks to generate offer and paper work and then 24 hrs to accept with a "take or leave it" ultimatum.
Just a very poor taste and I know some fine people who work at Google. Its unfortunate they don't seem to value warmth and humaneness when communicating externally
Noped out of that as quick as I could.
It crushed me because I found a team that I was unbelievably excited to work with.
Me and a friend of mine interviewed in Nov and passed HC in Dec 2019 as well (different recruiters between the two of us). Our experience was different from yours: Immediate timely followups from the recruiting coordinators, team-matched and hired in the same month. Hopefully our experience is more common...
Some European-based customer apparently had a requirement if we engaged with them, that our service be offered via an acceptable vendor such as GCP, for some reason AWS apparently wasn't, but it was such a nightmare to even prod about an architecture that would have feature-parity with AWS, it wasn't even worth it. Also as an fyi, I'm no AWS fanboy, I don't use it in any of my own projects to avoid vendor lock-in this company suffered from.
Since at least when we started spending about $100k/yr we've had a dedicated account rep we can contact at any time. They also get in touch to schedule a check-in every few months.
They've been genuinely helpful in several situations and have scheduled meetings with various teams around AWS (like, actual engineers) to get us answers to questions, support, and guidance. We've been put in touch with team leads and engineers working on beta features when we tried to use them and had issues to report.
Obviously this is all a sales tactic: if we have questions about X, putting us in touch with experts in X makes it more likely we'll successfully implement it and then pay them to use it. But it's the kind of sales we're getting value from, not just blindly pushing us to pay them more money.
We don't pay for any support package or anything.
Developer support $29/month, and business support is $100 (both go up if you spend more).
I paid for business support. You get
24x7 phone, email, and chat access to Cloud Support Engineers
Unlimited cases / unlimited contacts (IAM supported)
This is for $100/MONTH!! That is the deal of the century.
And they are ridiculously helpful.
I don't understand this - AWS must be losing money at least on support side, though they obviously get happy customers (myself included).
And even at $150 this would be great.
I had a client on gsuite with google 8 years ago - we COULD NOT get anyone to help with some weird admin state flow issue - it just was not possible to talk to a human being for ANY amount of money.
In general the AWS support has been great. In many cases, they've forwarded our requests to product teams who have even fixed bugs we've run into and contacted us directly.
Our other experience is with paid Azure support, which did little else than direct us to the (not related to the question) docs. They also had a really hard time understanding our technical questions about specific APIs. To their credit, they did eventually escalate to the PM of the service in question.
In general, the team responsible for the service really must be able to help out with support requests. In AWS this is definitely the case, in Azure as well but there's a bit of gatekeeping. Does developers and PMs in GCP participate in support?
There are plenty of cloud agnostic platform out there that does VPS, load balancers. digital ocean, linode, etc.
If you want to be green there is also the Advania they use geothermal energy. And since it is in iceland better data protection policy than US companies.
I'm not affiliated with any one of them, it is just from year of cloud provider hopping.
Only thing I miss is firewalls for cloud (they have it for dedicated).
While everyone else is talking about game engines, design and programming techniques, Google's talks are mostly around their cloud offerings, and customer telemetry.
So why is Google this way? They already have a terrible reputation for their non-existent support. Never thought they'd treat actual companies this way though. It makes no sense...
Of course, now when they enter a business that needs direct customer interaction, it shouldn't be surprising that they aren't good at it. No supportive processes and probably no internal appreciation for what reps do. Thus the turnover. They will have to build out a sub-org that nurtures and develops this part of the business.
I personally find customer interactions problems to be epidemic with fast-scaling internet businesses. It does however create a space for others to come in and do it better. We can hope...
>> Hahah. They did that to me too. I doubt they even looked at it. It was a fun homework assignment though.
"Once I provided that to them I was met with radio silence."
>> Hahaha. Same here.
"which will inevitably devolve into the discussion of how can I use BigQuery"
>> This is a trap. Once you are on BQ there is no sane way off.
Experiences with support or lack of support concerning other Google product areas and divisions, especially those not designed for businesses really don't apply if you know how Google operates.
I don't use GCP in a personal capacity at this time and I work for a competitor (though am certainly not speaking on behalf of the competitor).
It is true there are individuals that shine, but across the board, Google sucks at support. It starts at the top with what kind of company they want to be, and goes from there.
They do not like humans.
You should have seen the extent to which the rest of the team and I tried to resolve customer issues.
Random App Engine app getting 500s calling an Open ID endpoint (the service wasn't strictly speaking managed by GCP). I absolutely could not reproduce this and had no other reports, but I knew it was happening for the customer. I examined everything that could be different... After 2 weeks I finally got it: The customer app was running in a different data center compared to where I was testing. Calls to the API endpoint were timing out internally (pretty aggressive timeout interval). It turns out the Open ID service wasn't running in the same data center region. That should not have been the case but occurred because the internal BigTable service had to be upgraded in a particular region and hence all App Engine apps in that region were moved to another one - a fairly seamless process. The Open ID service unfortunately wasn't provisioned in that region (it's not a dependency of App Engine). Once I identified the issue it was a matter of telling the on call SRE about it who then spun up Open ID in that region and thereby resolved the issues in a matter of 5 minutes.
Often a new support case meant discovering platform limitations - for example running into BigTable anti patterns because App Engine Datastore allocated IDs sequentially by default. That could cause poor read / write performance, in part due to automatic sharding behavior of BigTable. We later switched to snowflake IDs.
And then there were lots of Java folks used to Classpath scanning (default behavior of Spring Framework?) which for larger projects caused App Engine container startup to exceed the allowed time limit. That became a user education issue for which we then had to write an in depth article.
Good times :)
I absolutely hated dealing with billing inquiries though... so difficult to map someone's code to billable operations. Some SDK methods were of course utilizing multiple billable operations. Determining SLA violation refunds was much easier.
(no, I'm not and have never been a Google employee)
Back in the dotcom days companies would spend a fortune on Sun kit but I bet when averaged out over time a comparable company would be spending a LOT more on cloud billing.
I would like to learn more about this. I'd have thought costs should go down over time. Are we doing more or is the cost per unit (not sure what that means) is truly going up?
GCE also isn't so much predatory as incompetent and apathetic. If a Google failure wipes out your startup, you're a statistic and it's okay.
The massive number of newer services are propriety, often buggy, and poorly documented.
I don't use any AWS services introduced past 2015 or so.
Not to say that isn't a useful article on its own, but it's hard to draw too many meaningful conclusions for the rest of us when the first line of the AWS bullet points is "reach out to dedicated YC email".
I'm in a similar position and those credits would be lifechanging.
The grants start out small (I think the first one was $3k) -- but then once you spend 75% of them you can apply for the next round, which for me they gave me $17k out of a possible $30k based on previous usage. After I spent around $15k for that over the next year I applied again and got $100k.
Just one note though that I already had an MVP that I was running on GCP at the time I applied (but I was within the $300 free credits that I started with so I didn't pay out of pocket).
I like Firebase, but the moment the utility runs out we're heading back to AWS.
Just from a technical perspective I'd advise to avoid the firebase databases like the plague.
It's not completely wrong, but incomplete.
So if you want to work on building your business and not debug cloud provider issues, avoid the new upstart.
If you just want to get started with GCP, you just sign in with your Google Account for $300 in credit. When you run out you can just start paying with a credit card.
AWS: makes me apply to a program to get credits and if I want to price out anything it's almost a full-blown research effort where I have to dig through documents and cross reference tables between different services and I still probably miss something important. Free tier is opaque enough to frustrate even "use it at small scale and see," because you still have to do the research to see if they are pulling a "your first hit is free but try to scale and WHAM." Oh, but they're customer obsessed, so after much begging and pleading they'll refund half of WHAM, one time.
If I punch in the services I want to use, I can quickly see how much they will cost, and it's easy. I recommend clicking "Advanced" inside services on the calculator if you want to be sure you're not going to run into an edge case that costs lots of money unexpectedly.
If you use any of the megaclouds without first understanding the price structure, good luck.
Personally, I think a lot of companies would be better off using DigitalOcean or some other medium-size cloud. The pricing is much simpler, and pretty much all medium-size clouds charge $0.02/GB for egress bandwidth, either globally or in the US, depending on the provider.
In contrast, the megaclouds make shocking amounts of money off of their extremely pricey egress bandwidth, among other highly profitable aspects of their business.
Even still, AWS is a solid cloud platform, and they really do seem customer obsessed compared to what I've seen happen on GCP.
That said, I'll grant you that AWS is not the only megacloud leveraging opaque cost structures. They just leverage them more.
AWS support is genuinely a cut above, though.
Apples and oranges.
It's really nice to hear from high-prestige companies about their experience because it gives outsiders a sense of what prestige might fix. If you're a small startup looking for help using AWS, finding someone to introduce you might really help! Not so much with GCP.
All in all, it had taken our incubator at least 1.5 years to get enrolled in AWS Activate, and 4 days in GCP for Startups.
When we applied for GCP for Startups, we were approved in a week, and were contacted right away by an account manager and a support engineer who offered us help with anything we needed. When we applied for Activate, it took a month with lots of followups, and being shuffled between 4 support team members who were communicating with the Activate team (there was no way to contact them directly).
It definitely felt like our business was important for GCP, and for AWS, it wasn't. It was an easy choice.
Google has never had a good reputation for Customer service, they believe they can solve all Customer Service with bots and Automation, this will ALWAYS lead to a lower level of customer service.
Amazon started in retail sales where customer service is king, so it naturally has batter customer service philosophy than Google.
Google has shown zero signs it even desires to have a customer service philosophy that is remotely similar to Amazon, or even Microsoft Software which is somewhere between Amazon and Google on the customer service scale
My point is that obviously AWS thinks that on average being in YC is going to result in more revenue for them and therefore they prioritize support for YC companies. As a non-YC company I won't get the same treatment which makes any conclusions from this article less useful.
Recently, I needed to increase a CPU-limit quota from a small number (like 16 vCPUs to 64 vCPUs) - nothing crazy. In the past, the quota increase system was more or less automated and would only take a few minutes to process.
This time, however, GCP denied my quota increase and forced me to schedule a call with a sales rep in order to process the quota increase. It was the biggest waste of time and kind of goes against the entire point of instant cloud resizing.
It also feels like the velocity of new features, instance types, etc has slowed down dramatically in the past year. Also, while I'm ranting, Google Cloud SQL is probably the worst cloud service I've ever used (and it costs an arm and a leg for the pleasure!)
1) Increase the disk size to 100GB as this increases the IOPs
2) Switch to using private IP addresses. Huge speed increase
3) get rid of cloudsql-proxy. Another huge speed increase
^ Do not use cloudsql-proxy ever. GCP docs are wrong. DO NOT proxy all your db requests through a single VM.
Switching to private ip definitely had the largest impact by far on performance.
Interesting. I'm looking Cloud SQL right now and the advice seems to lean in the opposite direction: use public IPs for ease of connecting. Can you quantify the decrease in latency? All I can find is bits about reduced network hops.
I didn't have to worry about the 'ease of connecting' when using CloudSQL as all my GCP services are in the same VPC.
Also, private ip is one less security problem to worry about.
We abandoned cloudsqlproxy partially because the sidecar in Kubernetes caused random disconnects, but also because it just had bizarre network errors sometimes. (That was mostly when connecting from outside GCP though.)
- No way to upgrade major postgres version without full export and import into new cluster.
- Incredible delay between postgres versions. IIRC, it took nearly 2 years for them to add postgres 11 after it was released.
- HA is basically useless. Costs double, still has 4-5 minute window of downtime as it fails over, doesn't avoid maintenance window downtime (both primary/standby have same maintenance window) and you can't use it as a read replica. Honestly, feels like a borderline scam since I'd imagine a new instance could be spun up in the same amount of time a failover takes (but I haven't tested)
- With default settings, we experience overly aggressive OOM-killer related crashes on a ~monthly basis during periods of high utilization. On a 32GB instance, OOM killer seems to kick in around 27-28GB and it's incredibly annoying.
- Markup over raw instances is almost 100%, with no sustained use discount outside of a yearly commit.
It's just a lot of money to pay for a crashy, outdated version of Postgres.
To be fair, it looks like GCP supported Postgres 13 (Nov 5, 2020) before AWS did (Nov 27, 2020) and AWS currently marks Postgres 13 as a preview. Maybe GCP had a large initial engineer-cost to support multiple versions of Postgres and now the incremental cost to add new versions is small?
> It's just a lot of money to pay for a crashy, outdated version of Postgres.
Have you looked at other options? I'm evaluating GCP SQL and the comments in this thread are scary. Seems like Aiven might be a good way to go. I've also briefly looked at CrunchyData's Postgres Operator [1] for Kubernetes but it's a lot of complexity I don't really want.
Things that seem similar in AWS:
- For major version upgrades, you need to bring up a new instance from a snapshot and catch it up with replication.
- HA failover results in a few minutes of downtime. (They claim using their SQL proxy will reduce this.)
- Lag in providing the latest Postgres versions. GCP seems to be a bit ahead of AWS here.
Is there a managed Postgres offering that you prefer? Aiven looks nice, feature-wise.
Am using SQL proxy but doesn’t do much re: HA.
I don’t know, I’ll probably just run my own Postgres at some point. The only peace of mind that I get from Cloud SQL is the automatic backups.
I will guess that you are much higher scale than us.
AWS has a similar thing.
I am founder of another YC backed company. We based our startup on GCP infra. They have great tech (for the most part) but I regret it so deeply for two reasons:
Support or desire to help customers is non-existent. For any questions, they want us to upgrade to paid support and pay them at least 10% more every month for that (we ask like 1-2 questions a year). What? We are already paying you thousands of dollars every month! I get included support for all my software subscriptions - so this is my biggest beef. Also, when they do help, they keep passing you around from team to team and dont resolve issues as well I’d like. It is just not a company I can love as a customer.
Their status dashboard is a joke. They dont even report minor outages, when they do, they start after a huge delay and update very slowly. And worst of all - when it only affects a single zone or a single region, they remove it from historic reports so everything looks green/great.
I’ve experienced both these times multiple times.
I have to assume AWS is better.
Basic business hours support is $29/month or 3% of your service spend, whichever is greater. 24/7 is $100/mo or 10%, which also includes outage assistance.
I’ve also worked for places with enterprise support ($15,000/mo or 10%) but of you’re bringing in millions per month it’s definitely worth it.
The AWS personal health dashboard is also pretty reliable. The public status page is the source of many jokes.
For Media services, the supporter will almost always need to coordinate with an internal team, which there is no visibility over, and then it becomes a game of telephone to make the supporter relay the information in a way the internal team understands. I've had the same thing happen with peering/networking related questions.
For EC 2, VPC, DynamoDB kinda questions, they are indeed pretty good.
1.) Try to figure things out ourselves 2.) If we can't figure it out, subscribe to AWS Support. 3.) Get question answered and then turn off the support plan.
You'll have your support plan for the rest of the month and pay a prorated amount for the days during which you had support. It's quick and cheap.
I guess grass is not greener on the other side. Oligopolies for the loss.
This whole onboarding felt like some caricature of what I thought were exaggerated stories of how bad the support was.
Lol no. AWS NEVER updates its status page unless it is a massive incident that everyone notices.
As for support, if you pay for the most basic plan you will get a basic answer within 48 hours usually. Its decent. The more you pay, the better the support.
https://cloud.google.com/support
For most organizations role based production plan is good enough
Did you know that the grass is always greener on the other side?
Better would be to think about what the general initial usability of these services are. How easy is it to spin up the compute load? Create reasonable IAM policies? Debug problems?
My own experience (and bias) is that while AWS has vastly more features, GCP is much more usable. The latter feels like a coherent setup with projects and IAM. AWS always has a surprisingly amount of work around org accounts and IAM setups.
So maybe it's faster to get AWS credits, but it's much harder to make use of them.
AWS Organizations is atrocious compared to GCP projects. I truly do not understand how/why AWS is doubling down on the awful user experience of Organizations, cross-account access, creating multiple accounts, etc. It's truly the antithesis of customer obsession and yet they show no signs of moving away from that model. And not only is the user experience bad, it also just feels hacky. AWS Organizations and Control Tower feel like poorly applied band-aids rather than real solutions.
I actually prefer AWS to GCP in most respects, but the AWS Organizations shitshow is something I can't personally get over.
Effect of ToS violations
Google-wide disabled account
In some cases a Google-wide account (which covers access to a variety of Google products like Google Photos, Google Play, Google Drive, and GCP) will be disabled for violations of a Google ToS, egregious policy violations, or as required by law. Owners of disabled Google accounts will not be able to access their Google Cloud resources until the account is reinstated. If an account is disabled, a notification is sent to the secondary email address provided during the signup process, if available. If a phone number is available, the user is notified via text message. The notification includes a link for appeal and recovery, where applicable.
In order to regain access to their GCP resources, owners of disabled Google accounts will need to contact Google support and have their account re-enabled.
To minimize the effect of an account being disabled on Google Cloud resources, we recommend that you add more than one owner to all resources. As long as there is at least one active owner, GCP resources will not be suspended due to the one of the owners being disabled.
[0]: https://cloud.google.com/resource-manager/docs/project-suspe...
A few years back, our business credit card was somehow stolen and used to buy Google Adwords. We disputed the charge with our bank. A day or two later, at 4am local time, our GCP account was suspended for fraud (presumably because the same, stolen, card was attached to that account). All instances were stopped and our service was brought to a halt.
We couldn’t contact Google Cloud support because our account was suspended. We had to go through our network to get our account re-instated. Pretty awful way to start our morning, to say the least.
You can fairly easily swap billing accounts a project is using if you still have an organisation admin account that isn't suspended. I saw this risk coming at a previous company and tried to get them to treat billing accounts like any other important resource and go for redundancy, but the director could not see the value and our Google account manager denied the risk existed, luckily they have been more fortunate and this has not happened to them yet, although it did come close once with some issues with the payments.
We actually created a portal where you can report unknown charges to Google directly; https://payments.google.com/payments/unauthorizedtransaction...
Credit card companies tell you to work with a company before issuing a chargeback, as chargebacks are a last resort. The above form helps you keep you account active without being swept up in the chargeback process.
It's something we all want to keep improving. I'm hoping as SCA (strong customer authentication) rolls out across europe and maybe other countries pick it up, it should cut down on issues like this.
The only logical thing to do in the case of a stolen or copied card is to contact the bank directly, so that the card can be canceled and fraudulent charges reversed.
Hold on while I go mine myself a ton of crypto coins.
When even Google themselves is recommending gaming their system since they can't guarantee it won't screw you over, that should be a warning sign.
The support isn't perfect, nor is the product -- but I would say the level of customer service for GCP can't be compared to other Google products.
1) AWS was extremely expensive
2) Our GCP bill is about 1/3 of what AWS was
3) The Kubernetes offering is top notch
4) Google giving us credits and offering us consulting were the triggers that started us talking.Always like to see why people make these big changes though, thanks!
This makes very little sense for Cloud Computing where each one your clients gives you large amounts of cash. Maybe they are too used to the first scenario.
edit: revenue GROWTH is declining
https://venturebeat.com/2020/07/31/probeat-slowing-aws-micro...
If you've lurked on HN over the past decade you'll have seen tons of stories about how bad Google's customer support is. I don't think GCP's support is anywhere near as terrible as it is for Google's consumer products, but it does have a lot of room for improvement. If you work with a reseller, you'll get much much better results.
There are several GCP resellers that are really good and knowledgeable, and often are staffed by former Googlers that worked on GCP. The very first thing you should do if you've chosen GCP is to find one.
EKS sucks. AWS data offerings outside of RDS are not as good as Google's.
AWS hierarchy also sucks. GCP projects/folder mechanism is vastly superior, also org policies.
I've also found integrating access controls via IAM to be really powerful and also pretty user friendly. In one experience, this helped us scale the sales process and allowed us to easily address sales push-back on data security and compliance.
Also, engineers really seem to enjoy using the cloud console, even at later stages when it was mostly just read-only and had a lot of access controls. The UX is just way better than AWS.
As mentioned, I've experienced issues with GCP and there are reasons to choose AWS instead. I can expand on these if anyone is curious, but wanted to list out the reasons to use GCP, as I feel like most of the posts you see about GCP on HN skew more negative than my own experiences.
I recently worked on a project which had a potential vendor spend in the millions if not tens of millions when it went to production and scaled.
Without exception, all of the vendors we spoke with early doors were horrible. Only interested in qualifying the size of the opportunity and when it would sign, not giving us access to the right people and playing horrible politics with our client.
I won't list them all, but the worst of the bunch was Snowflake. They were a nightmare and completely shot themselves in the foot.
If these vendors would have just helped like a partner with even a medium term focus, any one of them could have signed an enormous deal within a year.
Instead, we ended up going open source and AWS native, just because they are so much easier to deal with than many other vendors.
Having ran an AWS partner and seen them up close hundreds of times, I agree they are generally very nice and easy to deal with. I did see a recent cultural change when I had a problem in my own startup, but suspect they are still nice to the big boys.
But the sales rep knows that their job isn’t strictly needed, because the customer can sign up and use services without talking to anyone. They only exist to upsell services.
There’s almost no intersection between what a customer wants and what the salesperson provides, so why wouldn’t it be a bad experience for everyone?
That said I have heard even better stories about Azure actually - apparently it is yet in another league of its own in terms of perks and actual service game.
A client once requested we file a support ticket with Azure to help deal with a performance issue my team was working through. It wasn't really all that urgent, but the client requested we use the highest urgency level anyway. So I filed our ticket.
In less than a minute I felt like my phone was being blown up by every engineer at Microsoft. And the messages they left made it clear that the fate of humanity hinged on resolving our issue within the next five minutes.
On top of that, the depth and intelligence of the support was downright humbling to this fellow engineer.
(At the end of the day, it turns out we'd screwed up and left debug logging on.)
AWS has had many years to build and polish their sales process, and it shows.
GCP felt like the engineers built a good platform and then tossed it over the wall to some old school VP of sales type people to pitch it in whatever way maximizes their commission checks.
Azure feels like a finely honed enterprise sales org that understands what they need to do as underdogs in this market.
AAD ties everything together (this is a pro or a con depending on whether you use it), meaning you get secure SSO (including biometric security) for everything from device provisioning to machine identity (through service principals), and then Microsoft 365 E3 and E5 licenses offer every internal business tool you'll probably ever need in one place.
Azure basically only works if you go all in.
Microsoft is not without their faults and I know a few sprinkles of comments in this thread have definitely highlighted issues I know people have had with them, but in the whole I have to say this:
- my previous company switched from AWS to Azure and had significant savings, their sticker price is not the price you pay, and we were not spending millions to get deep discounts either (they were more interested in us being in a contract instead which makers some sense)
- the support we dealt with was really good for the most part, I felt it was pretty comparable to AWS
- they have really good uptime for the services we used (blob storage, cosmos DB, mssql and postgres, container hosting)
Biggest downside though is they seemed to always be going through SDK changes. I think this had a lot more to do with migrating everything to .NET core though, still was very annoying. Their non .NET sdks were a bit more stable though.
I'm not. Nobody likes Azure.
The only people who like Azure are managers that get bonuses for their stupid contracts. Azure is not built for engineers. All of their offerings, especially the automation and tooling, are vastly inferior to AWS and GCP
AWS crushes it with customer service. Google is a PITA.
Obviously there is a balancing act here to avoid slamming the engineers with too much load answering support questions, but it is not uncommon for customers to be getting answers from the people who built the thing. And on my team at least we always try to use support questions to know where we need to improve documentation with more troubleshooting steps, etc.
Absolutely. In my ex-team at AWS, you could literally see visceral pain on the on-call's face when a customer tickets-in with a totally avoidable issue. The feedback from such customer contacts did inform most of the product roadmap.
And most certainly, the most heavily prioritized and celebrated feature launches were the ones improving operation excellence including fixing things that a lot of customers had complained about.
That said, cloud support engineers, often times, in my experience, were more knowledgeable than software engineers owing to their interactions with customers which lead them to internalise a tonne of troubleshooting patterns. Only a novel issue would stump them where a software engineer would have to work in-tandem to sort it out.
The detailed internal knowledge-base that these support/software engineers write for issues impacting customers probably also plays an important role, because then even semi-technical folks like TAMs can more or less help the customer out pronto by searching through the knowledge-base, without requiring to escalate further.
As a converse, I've also had the extreme displeasure in dealing with Oracle and Tenable/Nessus support...
With Oracle, its either a continual feature-push to go to professional for only starting $50k/yr more (NO), or troubleshooting ends up asking 100 questions for your question.. And if you answer them, they give you 100 more. Effectively its a technical DOS in the hopes you abandon the ticket.
Nessus/Tenable is similar. They want you to use their terrible tenable.io (which isn't fedramped), and will badger you incessantly. And service tickets demand enhanced logs be turned on and provided to them. Their tool can censor some passwords, but have caught passwords in there along with services, addresses, and exploit data about them. And even if you censor the logs prior to shipping to them, they will put their foot down and demand unedited logs.
This would explain the response I got (backstory - I am a contributor to a number of open source packages / not totally clueless, but was coming in from a micro personal account). I was like, how the heck do they afford this response for $99! (or whatever it cost back then - this was a long time ago).
I kept my support plan active for a year as a courtesy though I never had another question aside from the first two I put in.
That said, as a programmer I like time to focus so being asked customer questions would drive me nuts, hopefully they filter out the idiots who just can't setup things right (80% of issues are not bugs but customer setup issues).
1.) Support engineer receives the case. In most cases, for most services, the run-of-the-mill support engineer has gotten enough training on the service that they'd considered a SME at any AWS partner/enterprise.
2.) If front-line support engineer can't solve the case, they talk to their more tenured friends.
3.) If they still can't solve the case, they escalate to Premium Support SMEs in the service. These are support engineers that have proven they have solved complex enterprise-level cases and get specialized training from the service teams on the internals of the service.
4.) If the SME can't figure it out, it's escalated to the service team (i.e. the actual software engineers that write the code).
Steps 1-3 deflect a lot of the annoying, unnecessary escalations. But sometimes escalation to the teams is unavoidable. For example, some service limits are hardcoded into the service and updates require a code push. Or (somewhat rarely) there's a service bug.
That being said, Premium Support engineer have access to the backend service code for most everything. While not every PS engineer knows how to code, on more than one occasion, I've dug through a code repo to figure out why something was behaving oddly.
I keep throwing large sums of money at AWS because they insist on making their products useable. AWS wants to me adopt their products, they want to remove barriers, they want to help me make money. I have no problem continuing to invest in their services.
"Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers."
Out of interest, here are the other values:
Ownership
Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job."
Invent and Simplify
Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here." As we do new things, we accept that we may be misunderstood for long periods of time.
Are Right, A Lot
Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.
Learn and Be Curious
Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.
Hire and Develop the Best
Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.
Insist on the Highest Standards
Leaders have relentlessly high standards — many people may think these standards are unreasonably high. Leaders are continually raising the bar and drive their teams to deliver high quality products, services, and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.
Think Big
Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.
Bias for Action Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.
Frugality
Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense.
Earn Trust
Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.
Dive Deep
Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.
Have Backbone; Disagree and Commit
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.
Deliver Results
Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.
Also another interesting thing with AWS, there representative give you honest suggestion on how to reduce your bill.
I've had similar calls from google in the past that were disasters, just someone hammering the up sales button, I actually had to block a google rep on my phone.
That was it. Other than that one conversation, my experience with AWS has been _absolutely stellar_ every step of the way. We’ve struck deals with them for several products and have felt like they were fair for both parties. Instead of continuing to focus on getting me to pay for support, they focused on areas where we’d want to rely on other AWS products and have come back with some amazing suggestions. I am extremely impressed with the teams I’ve worked with at AWS - it seems like they really understand the customer, and that incentivizes me to stay and use even more managed services when the unit economics work out for us.
For GCP I’ve had reps reach out. I tell them there’s no way we’ll go multi-cloud because it doesn’t make sense for our business goals and detracts from them. They respond as if they never even heard what I said. I get that you have to be persistent as a sales person, but the response wasn’t even talking about how _part_ of our infra would be worth hosting with them. There’s no conversation - it’s just what GCP wants me to do for them.
Once Google Cloud manages to hit the numbers, you would expect things to be much better for the smaller players (this remains to be seen).
Not excusing their support operations, but I did manage to get on chat with someone about a Billing issue (to understand my billing better), and I was pleasantly surprised at the response time (immediate).
The slow and free support route is to use the Google Cloud issue tracker: https://cloud.google.com/support/docs/issue-trackers You tend to use this if you are not critically impacted and you are also a developer.
By and large, things works as advertised. You can keep spamming that Feedback form in the Cloud Console. Product Managers do read it and address it.
GCP wants to front load revenue concerns, making product usage secondary.
Even apart from AWS's first-mover advantage, GCP should not be lagging as far behind as they are. Azure for example started a little later than GCP yet still appears to have more of the market.
We use Google for oauth, map and geolocation APIs for which we pay thousands of dollars every month and all my interactions with them have been very painful.
I remember when we asked for a meeting to discuss price raise on Google Maps APIs; The raise was ~100x for us. They came with the head of the local market and 4 people. Basically told us to fuck ourselves and that from now on we'd have to be billed by a reseller instead of being billed by Google. And then they spent an hour trying to convince us to move from AWS to GCP. I had the impression I was at a car dealership.
This is just an example out of many so even if I don't have direct experience with GCP I'm not keen to try.
I've been managing the AWS company account and the collaboration with AWS for the past 7 years. And while not everything is perfect, my experience was great overall and I would do it again.
GCP‘s primary target and starting point is enterprise.
OP‘s experience is no surprise.
On AWS: fast, close to our needs and all setup in days. After our one year program cam to an end we still had around 50k in credits. One email asking if they could extend for one or two months, they extended for 6. We also messed up the last month as we did not setup any limits and spend more than 17k in cloud computing - they offered us an 80% discount!
On GCP: We got accepted very fast (2 days). But we struggled for 2 months to get GPU quota. The communication is not fluid and we were pointed from sales rep to support to sales rep.
Also from the management perspective (but this is purely my opinion), GCP is a labyrinth. You need a phd in GCP to setup your users with permissions. And i still could not figure out how to create good usage reports out of it.
It could instead convince them it isn't a core offering, resulting in the decision to shut it down.
How is this an apples-to-apples comparison at all? Very disingenuous. You have a special support tier for your YC company.
I am in computational genomics and this was exactly my experience with Google as well.
AWS: Eat-your-own-dogfood, consumer company
Google: Eyeballs are our product, cloud,apps,services is a side-effect of our underlying ad business
Microsoft: Developer first, keep people in our ecosystem, make it easy to adopt, hard to get out of.
Google has good technical product inside GCP, nice fancy stuff like Spanner, etc. All spun out of their own requirements and needs, which is a scalable, invisible, processing engine. Their ad business has two sets of people, ad buyers that bid for their business and don't have alternatives, and anonymous viewers that google sells back to the ad buyers. They're rent-seekers that clip the ticket coming and going, using their search as the lock-in.
No wonder they have trouble setting up a true B2B or B2C business. They're not built for it.
Both AWS and Microsoft are at least either B2B or B2C and understand that it's not clipping the ticket, it's making margin over the cost of supply of goods and services.
Microsoft has even learnt the lesson of losing your lock-in advantage of the desktop.
Google has lost that fundamental trust to be able to both operate as a rent-seeker in the ad business while also delivering actual goods and services as a B2B/B2C business.
We've had pushy account reps trying to upsell from both vendors (and not knowing that we already talked to another rep). We've also had reps get actual engineers on the calls early who advised us fairly on which of their products to avoid and how to exploit various savings options or soon to be released features. We are a consultancy and so these reps were sometimes interacting with us as a direct customer/potential customer and sometimes via our clients (both larger existing customers of AWS/GCP and totally noob unknown startups)
I'm my experience, there is no pattern other than some CS reps are good and some are aren't. Getting credits in both cases has always been a PITA at the start and than easy when the right person to make the call was reached.
*AWS* - Lots of sales calls, but eventually redirected us to a "partner", who came up with basically a lift-and-shift.
*GCP* - The Regional Business Head was in direct contact. We were provided almost limitless access to a very helpful and experienced Customer Engineer - who spent _weeks_ with us, designing architecture, doing presentations, giving us learning material and eventually was instrumental in my team's increased capability and skill level to do the new infra design. Both came to visit the office several times. Eventually more senior engineers got involved.
We were also repeatedly given generous credit extensions. And best of all - there was a GCP summit in the country, during which I literally had a sit-down with PMs from a lot of GCP's product offerings - including Spanner, BigTable. 1:1 video calls with PMs from FileStore, Dataflow and BigQuery as well as early access to some key features.
Worth noting that we were hardly a "big" customer, or a huge money spender. Perhaps it was the technical challenge that interested them, or perhaps the reputation of the company/founder in the region. Whatever it was, I've had great experience with GCP.
just go rent some VMs/bare-metal and focus on building your product, everything non-product related is just a waste of time, money, and effort.
it looks almost as if engineers forgot how to scale bare-metal applications (hint: still doable, pretty easy and damn cheap!)
Also, the basics on all major clouds are pretty baked at this point.
cloud offerings are massively overpriced and their goal is to hook you up to their ecosystem and then eat into your margins once your startup lifts off
That said, the risks around customer support and occasional account termination worry me substantially. I'd be less worried if I had a corporate G Suite account with admin.corp@example.com with an invoice system and a corporate counsel on retainer to write grumpy letters as needed.
If you need a specific service like BigQuery then that's the only service you should have on there.
Though Jeff Bezos stepping down worries me a bit.
Google doesn’t care that much about their customers. They mint money from their web ad monopoly. They don’t have aligned incentives, they don’t have a customer focused culture.
I recently switched over to translating with AWS because Google. Keeps. Breaking.
There’s a decided lack of focus on user experience in Google Cloud services, from invalidating my credentials, upgrading the tool chain (and invalidating my credentials), to the usability of the gcloud CLI tool itself. With AWS I was up and running in literal minutes.
I don't want white glove service where they try to architect my architecture for me. Pushing me into cloud specific features (like everything in Lambdas stitched together with API Gateways). I don't need that level of help.
Also, of the three startups where I have heavily used AWS (personally "owned" the AWS infra), I never had that level of service offered. The only time I've had that "we'll help you architect it" service from AWS was at a startup that used GCP, and there were high level (CEO and CTO) discussions with AWS about partnerships. Then AWS wanted to help us architect (with Lambdas and API Gateways).
For me, GCP is way easier. Their products are more complete products. They work together out of the box. They are optimized for the 90% use case to just work. It is far easier to get a really good complete architecture working with GCP. Using their products push you to industry standard ways of writing and packaging applications (12-factor, Docker containers, etc.).
The startups I've seen build on AWS often have very bad setups. Hand rolled and poorly managed EC2 messes. Bad logging and monitoring because AWS doesn't have good logging and monitoring. Having to manage everything themselves because AWS doesn't/didn't have good managed platforms (Elastic Beanstalk has enough problems that people don't use it, and EKS barely counts as a managed service).
I've seen multiple startup with hand configured EC2 instances, running some generic web service. These systems create huge burdens and risks as the company grows. The app then grows and becomes locked into the special snowflake hand configured mess. One company I joined couldn't deploy for 6 months because their last deployment (a manual process) took 7 hours of downtime. When I see those systems I wish they started on Heroku or GCP App Engine (2nd gen). They would be way better off with a fully automated platform and 12-factor apps. Once you grow and hire people with infrastructure expertise you can take that clean 12-factor app and move it somewhere else. Non-experts trying to use AWS results in scary things.
GCP gives you that easy on-ramp. You can start with App Engine. If you need something a bit more custom, you can use Cloud Run (same basic tech as App Engine v2 but with Docker containers). If you need to move to something even more customizable for growing special needs, you can use GKE for a fully managed Kubernetes. With all those services you can write normal apps that use environment variables and log to stdout/stderr. All three give you logs in an easy to use logging platform. All three give you metrics in an easy to use monitoring/metrics/dashboard platform.
At every level GCP is easier. Cloud Pub/Sub is easier than SNS+SQS, Amazon Kinesis, or Amazon MSK (Kafka). It is multi-region and just works and scales. GCP VPCs and networking are easier because GCP VPCs are global (not regional), and subnets are regional (not zonal). No need to stitch VPCs together. GCP even has Shared VPCs so you can have a single address space shared across multiple projects (GCP projects == AW accounts). GCP authentication is simple and sane, even across multiple projects, no federation and role assumption needed. GCP IAM is far easier than AWS IAM. Cloud Datastore provides a really simple yet powerful NoSQL store, totally simple, no tunables, just works and scales, and even has some multi-region options available. Want a multi-region consistent database that spans large geographic regions? Amazon doesn't have an option, GCP has Spanner. Want a multi-region consistent blob/file store? Amazon doesn't have an option (S3 is single region), GCP offers GCS in multi-region, dual-region options that provide consistent multi-region file storage. Do you have some weird old app that writes to disk, and you would like it to be able to survive a zone failure? AWS EBS is single zone, GCP persistent disks can be regional, and because subnets are regional that means an instance in another zone can take over the disk and the IP.
For me, GCP is way easier to get started with. And will result in a better system in the medium term. In the long term, when you have thousands of engineers and experts in infrastructure engineering, it probably doesn't matter.
I'd be more interested in how easy it is to use a credit card and get a service off the ground. What is the relative quality of the products on offer by either vendor?
Long story short, on my first day I couldn't get the console to log me out, even after explicitly logging out, etc. I thought I was going crazy or just doing something wrong, but I absolutely could not get Azure to log me out. I had to create a support ticket and it turned into an incident. It was honestly all a bit ridiculous. I wasn't going to veto Azure purely on that, though it obviously was not going in Azure's favor, I did have to explain my experience and it was effectively banned based on that experience, because we were a small/medium business subject to HIPAA and more senior folks didn't like the idea of us going bankrupt due to HIPAA violations from our data getting exfiltrated.
It ended up being a pretty straight forward choice between GCP and AWS. GCP was already easy for us, because of G-Suite, but also our primary product encapsulated a TensorFlow CV ML model and TPU training was very appealing from both a cost and speed perspective.
Not to mention the way Azure handles networking and security is atrocious, bolted on to Active Directory.
I don't know GCP at all, but I do know that AWS Serverless is brain-dead simple to implement and very low-cost even when you begin to scale.
"Oh you have office365 and adfs? just move your monolithic enterprise java app to azure and save!"
I'm pretty tied to AWS at this point because that's who my employer uses but Azure was really great and their startup benefits were very generous.
Scenario: Run some expensive resources by mistake during learning period
AWS: Awww shucks, we'll refund you today.
GCP: Sorry no refunds.
Found it super easy to use and to quickly deploy things. Replaced our usage of Heroku and Vercel.