Hacker News new | past | comments | ask | show | jobs | submit login
Google Cloud vs. AWS Onboarding Comparison (kevinslin.com)
668 points by kevinslin 50 days ago | hide | past | favorite | 382 comments

It's not much better if you end up being a GCP customer.

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.

I've had the same experience with GCP account reps. They always go missing and someone new emails us about how they are taking over 6 months later. Every call we have had with them has not resulted in anything meaningful. Our biggest issue is how their "highly available" Cloud SQL goes down every couple months for maintenance, not how we can use BigQuery.

> "highly available" Cloud SQL goes down every couple months for maintenance

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.

We’re currently migrating to Spanner for a variety of reasons - but the mandatory downtime on their Postgres CloudSQL offering will be the part I miss the least.

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!

One thing that customer obsession at an entire-organization-depth level does is encourage broad customer use awareness.

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.

Surely product makes these decisions, not engineers, right? I agree that customer empathy is important, but I don't think we can conclude that the engineering team (rather than the product team) is the source of the deficiency?

> Surely product makes these decisions, not engineers, right? I agree that customer empathy is important, but I don't think we can conclude that the engineering team (rather than the product team) is the source of the deficiency?

I haven't worked inside AWS or GCP, but I've never seen product get everything they want, especially around maintenance/downtime. If "less downtime" is on the roadmap but engineering is constantly pushing back "that'll be really really hard and take a long time and they're just using it wrong anyway," I can't imagine it getting done as quickly as at a place where the engineering team was also focused on customer satisfaction.

> that'll be really really hard and take a long time

It probably is hard and intensive. Engineering shouldn't lie and promise that it will be easier. Product has to take that engineering estimate and determine whether to work uptime or some sexy feature (and sexy features usually win because of perverse incentives).

Moreover, I have a hard time believing this for a couple reasons: first of all, I've scarcely met engineers who were opposed to improving product reliability, maintainability, etc. The portrait of Google engineers arguing that database services fundamentally shouldn't be HA (and customers are "using it wrong" for wanting HA DBs) is particularly incredulous. Secondly, I've never heard of an organization where engineering held political power over product decisions, but I have worked in several places where product dictated engineering solutions. Businesses trust product more readily than engineering because the things that engineering is always petitioning for are abstract and "costly" (deferring some immediate profit for reduced costs in the long run) while the things product wants are usually tangible and profitable.

Sounds familiar. Product and sales areas of the business look at immediate revenues - and hopefully profit - but are always more keen to do that at the cost of increasing technical debt within the engineering side of the business. Unless sales see a real impact to technical debt, they will always choose the short-term approach.

Agreed, and I don't think that's even necessarily the worst thing. It just means that engineering and product/sales have to have a conversation, mutual trust, and a shared vision that extends beyond the next quarter. These are hard things to cultivate, however.

Most of the places I've seen this go bad were because one side was incentivized to not care about the other.

If product has PM or financial incentives that reward without regard to technical debt...

If engineering has PM or financial incentives that reward without regard to user experience...

If you want people to cooperate, set up shared, team-based incentives!

I agree. In whichever case, blaming individual engineers seems weird. Rarely are individual engineers to blame, and even when they are the organization should be robust enough to route around the occasional deficient engineer.

It's a full-company culture problem where ~everyone has personal responsibility.

Behavioral properties are end-to-end, like speed, security, customer success, uptime, etc. Everyone and everything on the hotpath for that has to be on board, as just one violator means nobody is achieving it. Operationally, part of achieving that means company norms, such as when collaborating, planning, executing, etc.

It's 100% fine not to provide any of these, and is even reasonable given it's hard to change one's DNA end-to-end... but better to be an explicit decision. Likewise, if starting a company... a lot easier to pick & ingrain these habits ahead of time.

I tried explaining this to some Azure product teams, and they gave me a blank stare in return.

Sure, you can have zone-redundant Azure SQL Databases, but not Azure App Service!

You can have zonal Azure App Service, but with a different network model than the default, so it's a breaking change for some apps.

It's as if nobody has actually sat down at Microsoft to build something similar to what their customers are building. It's all just tech demos, "get your blog hosted in 5 easy steps", and crap like that. Nobody at Microsoft has ever built anything of substance with the majority of their own platform.

It was the same story with Windows Presentation Foundation (WPF). It was hot garbage when it was first released, but Microsoft kept telling all their partners to prefer it over the legacy GDI+. People tried and failed to write GUIs in it. When after many years Microsoft finally tried to convert Visual Studio to WPF -- the first time they had used their own framework for one of their own apps -- magically the core issues were fixed and WPF become viable for real apps.

My experience with MSFT is that the account reps are clueless by design. Even the sales assistants with fancy technical titles are short of clues. Easier for them to oversell when they don’t know what’s really going on underneath. We have to go 3 or 4 deep into their product org to find someone who will fess up to product issues that we are already aware of.

Also they now require you to become Microsoft Partner, if you want to use the oauth2 login not only for personal Microsoft accounts but also other Microsoft accounts such as those provided by a business running Office 365. They changed it ~ 3 months ago and are now not able to verify people in time. Even if they just want to check your name, email and maybe a profile picture and nothing else. The process is much less obvious than for the same thing with Google or Facebook. Even the ZIP-Code has to include spaces as if it was written on a letter, otherwise you will not be able to send the form, aaaand there is no hint about this requirement.

In general, Microsoft, Google and others are behaving really enterprise-y in that they are slow, you cannot reach anybody of importance to solve massive issues with their products and everything is actually quite expensive for what it does.

I had no idea this was a thing, is there any justification at all for this behavior? Sounds like a massive dealbreaker to me.

I use Aurora just for this reason. RDS is just a great product. Doesn't even need the cloud sql proxy equivalent since you can just install the authenticator into the database.

Aren't RDS and Aurora two different things?

> Aren't RDS and Aurora two different things?

NO, RDS includes non-Aurora versions of many DBs, plus MySQL and Postgres-compatible Aurora servers, plus MySQL and Postgres compatible Aurora Serverless.

Aurora is one of the DB things you can launch in RDS.

Thanks for clarifying. I'd associated RDS with the non-Aurora offerings of Mysql and Postgres. Judging by upstream version compatibility it appears Aurora is more heavily forked than their non-Aurora siblings.

I don't think Aurora MySQL/Postgres are just forks, I think they are a completely custom datastore behind a MySQL or Postgres-compatible interface (which probably uses a lot of non-engine code from the open-source base database.)

Regardless it looks like anyone choosing Aurora should not hold their breath for Mysql 8 or Postgres 10+ compatibility. Seems like only one major version bump has happened since they launched the first one (Mysql 5.6-to-5.7).

Which is fine. It can just be a little confusing as they drift and the caveats grow.

> Regardless it looks like anyone choosing Aurora should not hold their breath for Mysql 8 or Postgres 10+ compatibility.

Current Aurora Postgres is compatible with pg 12.4; pg 10+ support has been around so long that several versions that support 10+ have already been EOL’d by Amazon. Even Serverless, which lags behind, is on 10.x.


Wonderful! Not sure how I missed it the first time. Thanks for correcting me.

I use it in Postgres 12 mode.

WAIT. Be careful. That is a super expensive product with a high likelyhood of lockin. It doesn't support all SQL features. Also! I run hundreds of GCP databases and never ran into: "but the mandatory downtime on their Postgres CloudSQL", maybe it is only Postgres?

Same here. I have sent my GCP rep 5-10 follow up emails by now and still no response. It really feels like I have no one to talk to over there and I'm spending thousands per month.

Hit me, more than happy to make fun of the salient GCP rep for you in a way they really won't like :)

Curious what your approach would be?

That said, this is not some poor rep's problem. This is a problem of Google culture and one that will be very difficult to fix. They simple don't care much about their customers and never needed to.

I’ve seen both! Plenty of culture issues, or tools, and sometimes someone’s just checked out...

Bit of a surprising comment coming from the CTO of a large Google partner?


I think you’ll find me surprising :) It’s surfacing and chasing down root cause of these misses that make things better for all customers, and that’s my goal :)

What do you think partners are for if not this?

I helped a major user of GCP migrate off the platform to AWS for this exact reason. Totally insane that they still do this when AWS has had a rock solid offering in the form of RDS for like 10 years now.

Does RDS not do this to their customers? This alone would make me seriously consider taking my business away from GCP.

Absolutely not. I'm sure it's happened but I have never personally seen an RDS instance go down, in over 10 years consulting and building in AWS. Google Cloud SQL was going down for multiple minutes every month for one of my clients, and their support just said there was nothing they could do about it. That cost Google cloud at least a million dollars in revenue over the next few years as this was a fast growing startup.

I’ve been a long time Azure user, their SQL Azure product was very glitchy and had constant outages (“just add retries!”), it’s gotten better in the last year or so, but it was totally unacceptable.

AFAIK that's a "feature", not a bug. They throttle concurrent requests and return a different error code compared to the on-premises SQL Server.

I just watched a load test hit that issue, the developers cranked up the traffic until the response times were measured in minutes. At that point Azure SQL started throwing errors related to too many concurrent queries.

Compared to just locking up or timing out, it's probably better.

See: https://docs.microsoft.com/en-us/azure/azure-sql/database/re...

And: https://docs.microsoft.com/en-us/azure/azure-sql/database/re...

E.g.: the 4-CPU pool has only 210 Max concurrent workers per pool, but if you think about it, that's over 50 queries running at once per CPU core, which is nuts!

I’ve experienced that too, but these errors were literally “server is currently unavailable” and downtime.

Ps: if you’re working on a production load system, and has decent traffic, lean towards premium/business critical tiers for true HA

Do y'all just like, ignore SLO's? Cloud SQL has a 99.95% SLO, going down for multiple minutes every month is within that. No smoke and mirrors here, there are ways to mitigate it but it's not Google messing around with expectations. HA doesn't mean 100% uptime.

It’s worth noting that the dreaded maintenance everyone is talking about here is not part of the SLA:

“Downtime as part of Scheduled Maintenance will not be counted towards any Downtime Period.” - https://cloud.google.com/sql/sla

I’ve never seen an SLO document for CloudSQL though so the SLOs may be slightly higher internally?

Does that include or exclude "maintenance windows".

AWS tells you when your maintenance window for an RDS instance will be and you can delay/reschedule as needed.

I wouldn't consider a maintenance window as "downtime". That 99.95 applies to all the time outside the window.

Yet AWS manages to give near 100% uptime with RDS at a similar price point. CloudSQL downtime in the cases I've seen was caused by them rebooting both master instances at the same time. This is amateurish and totally unnecessary, the whole point of having multiple masters is to the ability to do maintenance reboots in a staggered schedule. This should be a trivial problem for Google to solve and would result in much better reliability for their users, yet it's been years with no change.

I had some instances that needed to be rebooted because they were running a vulnerable MySQL version. AWS gave six months warning (before forced reboot) and ended up extending it to 12.

This has also been my experience.

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 work at AWS)

> 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.

I used to work at Google on Cloud, and am now an AWS customer. Have used both clouds extensively.

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 think all of these replies so far capture my thinking. However, I think the simplicity of the GCP IAM model is what I will miss most going back to AWS.

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.

Gone deep on IAM in AWS, attempted a similar thing on GCP later for another project, was very surprised how weak GCP IAM was.

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.

Haha, my company is still pretty small and I have very few policies with star-less ARNs. :)

But I agree, AWS IAM is some black magic and is very powerful.

One thing that GCP is far better at is account setup. Having everything nested under a single gsuite organization with folders and projects and IAM flowing through is incredibly easy to work with and makes permissions simpler to understand. AWS has a long ways to go in this regard.

I came from an AWS background to my current company's GCP setup and was very confused at how IAM worked on GCP for a long time. Now that I know the system, though, I agree with you. It really makes a ton of sense and works really well.

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.

I can totally relate. The amount of times I've spent scouring the docs for the "machine name" to put into TerraForm, or vice versa, to do through the UI...

I disagree. Once you learn IAM and able to segregate users into groups each with its own layer of security, then it is good enough.

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.

IAM shouldn't be a thing to learn. It's account management, default and easy to access options should be sane enough for most people to use. At big companies, sure someone has it as a dedicated part of their job description. But if you're in the majority of smaller companies, ones maybe that's just doing e-commerce and tech isn't their core skill set, account settings should be near invisible and still be trustworthy. It's not the Slacks of the world that have an issue with this, but the long tail of the world we now live in that software has eaten and companies are just scrambling to exist in it. Flutter integration is not in the list of concerns of this long tail.

And telling them to "just learn it" isn't the customer focused mindset, it's the engineering one.

I created all of the IAM roles that our 100+ person company uses. It was and is important from a security standpoint that we do not just blindly give too many permissions to employees. I had to do some research to understand what the bare minimum was and it wasn't too difficult to do.

Custom roles created through Terraform helped a lot.

It absolutely is required beyond small 3 person startups. Google is great to get started but when you are dealing with a dozen or more developers, especially at large organizations IAM offers that granular control and overview.

Yes its a bit of a pain having to add policies sometimes when you are first getting started but once it's up and running you can rest easy.

Learning it isn't that much more time consuming or difficult, its just a bit of effort that is all (we are talking a few hours at most).

What exactly are you disagreeing with? Segregating users into groups is possible with either platform.

The discussion is about GCP having much better functionality around it where projects and permissions are naturally integrated with gsuite organizations and users. This is objectively true. AWS has an archaic project system with a dozen different attempts at uniting it all but nothing comes close to GCP's smooth and easy manageability.

Thoughtful features like supporting UEFI Secure Boot with vTPM attestation. This allows building setups where even a full GCP account compromise can be mitigated.

Integration with our org GSuite (this alone is a massive plus).

Just wanted to say thanks for the responses. I've forwarded this comment chain over to some people who are interested in this space.

> 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.

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....

Sounds like my experience with their recruiting.

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)

I had a similar experience with their recruiting. Some interviews were cancelled and had to be rescheduled only after I inquired.

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

Got an offer from a dream company. But it was lowball take it or leave it quickly thing.

Noped out of that as quick as I could.

To be fair, Covid likely played a part in that long silence. I believe there was even a hiring freeze for a bit in spring. Not that it excuses bad behavior...

I had virtually the same experience in 2018. Gave me an offer for less than half I was currently making too.

It crushed me because I found a team that I was unbelievably excited to work with.

I should mention though that I did re-apply last year and they were much more prompt

If the recruiter replied and said as much I would have been ok with that. At least they were communicating. Plus covid didn’t effect the US big time until March. That’s all of Jan + Feb they had to let me know something was going on.

Wow. Not even a call from the Recruiter to walk you through the offer letter?

They called me eventually were kind on the call. But the whole communication issues leading up to that really ruined it for me. I was initially quite excited too. I have no idea if this is common or if my recruiter was especially bad. Reading the parent comment made me think of the similarity.

Wow, that's a pretty horrible experience. Weird too since AFAIK recruiter/recruiting coordinatiors comp tied in some way to shepherding the successful candidates through the hiring process.

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...

I know why. HR received so many resumes which they don't do any additional effort, do they receive compensation for each hire, no. Most of them are not FTE.

Sigh, I remember a similar experience. It was a third-party rep they pushed us to, but we would be asking for ways to re-architect one thing we already had setup on AWS, and all they would do is just try and upsell us on random offerings that clearly did not resolve our specific needs.

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.

Same terrible experience here with GCP sales and support, but the other options aren't much better. The reality is that unless you are in the 7 figure range, you don't get serious attention. I'm still surprised why sales is so dysfunctional but billions of quarterly profit means there's little need to change.

AWS has been good for us.

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.

I dunno, I spend $3 monthly with AWS, but when I click the support button I’m talking to a real person pretty much immediately.

you only get billing/account support unless you have subscription, starting at 150 US$ month

Huh? Please look at the actual AWS page: https://aws.amazon.com/premiumsupport/pricing/

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.

I suspect that AWS is 'losing money' on this in the same way that Apple are 'losing money' on their high Street retail shops.

Working at a place with AWS enterprise support by contrast, for the second occasion, I would suggest that many of the places paying $15kpm don't cost that to support.

Yeah. AWS is probably "losing" tens of dollars per month hosting my personal account. They've made a few million dollars in sales as a result. I've personally started several projects on top of AWS which spend that much now. That started with the free tier back when AWS was young.

Google has treated me so badly so many times now on my personal account (as well as on business accounts, for that matter) in so many different ways that they've, conversely, lost MANY million dollars in business sales. It's hard to even count; a lot of people ask me for advise on decisions, and whenever someone even thinks about using Google Cloud in a business setting....

This is not a hole I see Google getting out of, except by eventually shutting down the Google cloud. Too many people have had too many bad experiences, and reputations take a long time to recover.

And the failures just keep on piling up.

Google is great for personal use, but I think they're diversifying in all the wrong directions. They're not structured for success there.

And yet Google Cloud has some great features that AFAIK AWS still hasn't, presumably due to different priorities.

Like regional disks [1] or live migration of compute between hosts if problems are detected with the host.

1. https://cloud.google.com/compute/docs/disks#repds

> live migration of compute between hosts

When would you ever want to rely on this? Seems to me like you should have two hosts in the first place.

Google has been relying on it for years. It's completely seamless and means you get even better reliability by insulating from the underlying hardware issues.

When you don't want to lose the requests already in progress, and to avoid the failover window

The price starts to go up steeply once you hit the % of monthly spend.

I'd guess they don't get many resource intensive support queries from the < $10k a month customers (and at that level you probably don't get the A team support)

Another comment later identified this - I actually did get a weirdly A-team support response. That's what made me scratch my head because I was coming in the poor / cheap / don't know what they are doing door (and most support is crap user misconfig issues at least from my experience). I just wanted the thing noted somewhere in case others were hitting it, instead I got a way above standard support specific technical response and some suggestions.

The other poster indicated it is possible for stuff like this that you get bumped, even on the el cheapo plan, to someone actually on product team. While I'd hate to be on the product team having to answer these, it perhaps keeps folks aware of customer issues so they can at least improve docs for corner cases?

Looking at support as a cost kind of misses the point. Bugs are bugs, and your big-ticket customers might just drop you rather than helping you figure out what is wrong with your product. Ignoring paying customers (even small-time ones) prevents you from improving your product. If they took the time to reach out (and especially if they're paying $100/month for support) you really need to listen to them and try and figure out how you can fix the issue so it won't affect big-ticket customers.

That's what it says, but in practice I've asked some really general and technical questions of AWS support and always received a helpful reply without a paid support plan as well. With a paid plan the response time is better.

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?

Microsoft support is always useless in that way and the TAMs are pretty powerless. I hired an intern just to contest the hours to effectively cut our (large) premier bill 70-80%.

Their model was fault-based, and a “bug” gets billed to the support group. So the game was always for MS to avoid assignment for non Sev-A cases, and our game was to find a product defect for anything.

Or support helpfully suggests that you file a suggestion in the public Azure feedback forums.

Yeah... just like the other 5 dupes of the same suggestion with hundreds of upvotes that the product teams have dutifully ignored because it only matters to customers.

Speaking from experience, yes, customer issues that can't be answered by support agents do get escalated to the engineering (and PM) teams.

GCP loses more than a billion a quarter: https://www.google.com/amp/s/techcrunch.com/2021/02/02/googl...

Isn’t it neat how if you Google something and share the link you find, you end up directing people to Google’s AMP service!

Google Cloud, AWS, MS Auzra are made to lock you into their system. I guess if fine if you are ok with it and you don't have an experienced systemadmin/dev op on hand.

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.

Couldn't agree more. I am on both DO and Linode for many years and I have had an amazing experience. Not affiliated with any of them, just a happy customer.

Yeah, Digital Ocean $5 per month is where I started. Do it yourself, the tools are out there!

same and ended up with hetzner.. great inexpensive service.

Only thing I miss is firewalls for cloud (they have it for dedicated).

How does AWS lock you more than DO? Because they have a more comprehensive offering?

Have you tried deleting an S3 bucket? Go ahead, I'll wait. How about egressing any amount of data? I hope you have a Diamond Platinum AmEx attached to your account because you're about to lose your house with that bill.

Route 53, S3 storage, load balancer, everything is encouraged to work other AWS services! Smells much like what MS was doing. Don't get me wrong, it is more open than Google Cloud and Azura.

Somehow your comment reminded me how Google talks go at GDC and similar game development conferences.

While everyone else is talking about game engines, design and programming techniques, Google's talks are mostly around their cloud offerings, and customer telemetry.

The reason why the account managers change this way is because of so called territory or account realignment. These are sales terms but ultimately it means don't sit on one client for too long. Salesforce does this every single year, last week I received an email from 6th or 7th account manager since I started using them. The story is always the same: they get in touch,try to understand your business,ask questions,and see if they can spot something that previous guy missed. I hate it. However, this seems to be working on their end,as the sales keep growing...go figure.

> they don't care about my company at all

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...

Inevitable. The entire company is built on a scalable business that required no direct contact with customers. Direct person to person interaction is the antithesis of their successful business model.

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...

Even their customer facing engineers who aren’t total a holes act like they are from a superior type of existence and we should be honored to be graced with their specialness without meaning to, but it is ground into them.

To be fair, BigQuery is probably their best product since Search so I can see why they try to milk it. It capitalises on what Google's best at, distributed systems engineering, while avoiding what Google's worst at, API design (by instead using SQL, which wasn't invented by Google). I say that as a customer who otherwise has little positive to say about Google.

This seems to summarize my experience with software sales processes and interactions in general. I’m hopeful that software sales culture is beginning to evolve into something other than the pack of hyenas on a carcass that it is today. I personally have resorted to rejecting any and all conversations with software sales people unless I can dictate the direction of the conversation.

"I even made them a schematic of our architecture on GCP at their request."

>> 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.

As the guy who designed the architecture diagramming system, mostly to help folks keep straight what they're trying to help folks build, I hate that it's being used as a qualification/filter/etc. Sorry yo.

It's interesting that you've had that experience - it mirrors mine in dealing with Oracle reps: no engagement, no interest, very high turnover, always under pressure to sell, sell, sell. I wonder if appointing someone ex-Oracle to head GCP has carried that culture over.

I mentioned this a couple of times, but Google's CS is non-existent. That's #1 issue holding me back from trying any of GCP offerings.

You need to see GCP as its own brand with its own support team and policies (though they are impacted by some shared technical infrastructure and associated policies). I cannot say whether these are good or bad, only that they are distinct for GCP.

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).

I use a lot of Google products. All of them I pay for, except search.

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.

Once upon a time I was one of 3 people globally that was the entirety of the GCP support team :)

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.

One thing that AWS Premium Support does very well is make situations like this seem unremarkable. This is the default way you do work. Going above and beyond is solving the issue, the next issue the customer hasn't asked you about, and giving practical guidance on things like cost optimization or availability concerns after weeks of deep diving.

I'm not saying you didn't do great work, but I think the secret to success at AWS Support is normalizing this level of customer obsession.

What I am saying is that this obsession was normal to us also. I didn't know any Googlers (whether in support or engineering) who didn't care about customers.

We did whatever it took to resolve a support case in the quickest yet most satisfactory manner, even if it meant doing some crazy research, meanwhile we got of course overloaded with more support cases coming in.

I had 100% customer satisfaction from all surveys. That was definitely hard to achieve because happy people usually don't complete surveys. :)

These were the early days of many GCP services. I worked there when Compute Engine and Big Query GA'd. This was just before and possibly during the time the paid support tiers were launched (I don't recall). I left mid 2013. No idea what their support is like now.

And those technical account managers just bounced customer questions to us 3-5 support engineers (technical solutions engineer)

Anyways, your AWS comparison may apply to the GCP support culture now (I have no idea) but back then we were all extremely customer obsessed - by choice.

I really appreciate that. Both as a customer, but also as a fellow practitioner.

At the end of the day, I don't think the complaints you hear about GCP Support / Service has anything to do with the people working on the line. There's always better or not better examples of folks you encounter as a customer.

As a support consumer, I've learned that my feelings about the person on the other side are very much colored by the fact that I almost never call support when things are going well or I'm in a good place. I typically call support when all else fails and I'm probably ready to throw a product out the window. That's not their fault, and it shouldn't be their problem, either, to a certain extent. They're humans, doin' a job, just like me.

As a support provider, I've learned that the same is true for all of my customers. I need to know that this isn't who they are (usually) when they go home to their family, or out with their friends. They're under a lot of stress and, one way or another, we've let them down and have to deal with that.

I think the challenge with GCP support is all about the overall strategy as a business. My experiences with GCP support is that I have to work way too hard to get past the robots and the scripted responses in order to find someone who is willing to listen and engage with my question or problem. And then, to make matters worse, about 80% of my interactions with Google support involves them trying to introduce me to some consulting company or third party provider. That is pretty much never what I want. I don't want some third party billing integrator that is going to mess up my reporting with their "value added" service. I already pay for support, I don't want to hear a pitch about paying for more support when I feel like I'm not getting what I've already paid for.

I don't hold this against the support folks at Google.

I hold this against the leadership at Google.

This is their strategy to contain costs or to juice sales.

If it were working, I think their numbers would be very different in the market. So the proof is in the pudding.

Something isn't working at GCP.

I don't think it's the engineers or the teams. It's the leadership and the strategy.

What you are describing unfortunately is due to the external vendor teams managing support -- a business decision as you rightly mentioned.

A lot of support became outsourced and the original support team became more of a tier 3 backline support with the first 2 tiers being handled by vendors. This started for GCP just after I left in mid 2013.

The vendors responsible for support have contracts to meet certain customer satisfaction metrics and time to first response metrics (based on customer tier and ticket priority). The majority of inbound support cases would get auto assigned to the vendor team. Only the top customers would reach Google employees directly.

The vendor and their staff simply have no incentive to troubleshoot an unusual issue - they also cannot have access to the tools that may expedite such troubleshooting. It's all about pattern recognition to quickly resolve a ticket. As many vendors were overeager to escalate support cases to the Googlers it became necessary to impose more requirements on the vendor team to be able to escalate an issue - invalid escalations were being tracked and the vendor would be penalized for the total of these.

I built the internal tool via which GSuite and GCP outages or significant issues would be managed from a support perspective. This had the advantage that vendors didn't need to waste their time (poorly) parroting (with a delay) the status of an outage as related incidents could be (manually) grouped together and then all be updated at once by the current incident manager on the support team - freeing up lots of support folks to work on other support cases.

I definitely agree this vendor-based support model is a frustrating experience for everyone involved. I witnessed that myself after leaving Google. By the way, I'm very surprised GCP tries to upsell you on consulting services based on your support interactions.

Running a support organization for a very technical product with so many unknowns and variables at scale is hard. I wonder who does that well and how they accomplish it (from an operational perspective).

I have no idea how AWS manages support internally. I work at Azure - until last week as a Developer Advocate, now as a software engineer in Azure CTO incubations - I have no idea how our support organization is run or what their quality is. However, from what I hear Azure support is eager to help anyone and everyone. I remember being very confused I got a phone call to inquire whether I needed help within a day or two of signing up for an Azure free trial.

Is paying extra 3-10% of your already expensive invoice worth the premium support that you _might_ need? Not sure I would consider that customer obsession... more like insurance.

Honestly given how good BigQuery is, I don't blame the sales rep for keeping their eye on their wallet. I know a lot of companies who are primarily AWS but use Google Cloud exclusively for BigQuery analysis.

(no, I'm not and have never been a Google employee)

I've used both GCP and AWS at multiple companies and personally, and my take is that a handful of important GCP products are significantly better than their AWS counterparts (Bigquery, Bigtable, Spanner, GKE), and a lot are just OK, usually slightly behind AWS in terms of features. If one of those products that's significantly better could be a differentiator for you, GCP is the better choice.

why not just use snowflake though if they aren't on gcp already?

Why use Snowflake over BigQuery?

don't have to move data to another cloud?

These guys must be commission based

Aren’t the all sales reps commission based? I would be very surprised if AWS reps are not.

I'm not a rep, and I don't know anything about your use, but I'm 100% ready to learn about it and see if any of the stuff I know can be helpful to you and your team. Sorry this has been your ride to-date :( miles@sada.com

I'd say your experience isn't unique to google. I think at some point we are going to hit a place where people realize the convenience of the cloud doesn't outweigh the additional cost of having a mostly predatory business partner.

the convenience of the cloud doesn't outweigh the additional cost of having a mostly predatory business partner

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.

> 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?

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?

I think a number of factors add up over a 3-5 year timeline (obviously this will be more or less true for different organisations). There is the way the cost scales for a given instance in the cloud - in the old days, for example, doubling the memory or doubling the CPUs didn't double the cost of the kit, but it does for clouds VMs.

Another example is that the cloud bills you for everything, in the old days I could have a database server on a network and query it as much as I liked, the cost was fixed upfront for the lifetime of the hardware. Whereas it's very cheap to get started with a managed offering but e.g. BigQuery charges you for every query, Cloud Functions charge you per invocation, bandwidth is chargeable etc.

Speaking of hardware, in the old days you could look at your hardware and say, actually, it's fine, we don't need to upgrade/replace it this year after all, and it will just keep running. Whereas in the cloud the payment is continuous (perhaps offset by the fact that it's easier to "give back" excess capacity).

There will come a point at which the cost of DIY vs cloud will cross over, the question is whether you will reach that point, and if so, what you will do about it, since you may be well and truly locked in at that point.

When was the last time a landlord reduced your rent?

You always can drive cost concessions from sales, especially for base workloads where you have time flexibility.

For a big company, cloud rarely saves money for many categories of expense. In a normal market, it is almost always faster time to market to rent, and always cheaper TCO to own.

> When was the last time a landlord reduced your rent?

This is a different market and one which is ultimately constrained by the availability of land. Notably, cloud prices do fall especially relative to the compute power. Specifically I remember when Fargate moved to firecracker and prices fell by like 40% or something similarly considerable.

Maybe managing your own internal cloud is indeed cheaper (especially if you don't account for support or maintenance!), but arguing that cloud prices don't decrease or making some housing analogy seems like poor reasoning.

Maybe cars or trucks are a better example. The ROI of buying, leasing or renting a vehicle varies and the optimal answer depends on the scenario!

It’s always better for you as a person to rent box truck to move. If you’re a company that needs a truck 3-5 times a month, there’s a probability that leasing may make more sense.

I’d say that businesses that suck at managing on-prem will not magically get competent in a public cloud.

> I’d say that businesses that suck at managing on-prem will not magically get competent in a public cloud.

It takes time to build a competency. If you have to figure out how to operate everything from the hardware and networking all the way up to application, then you might very well fail as a business. If you can pay Amazon to manage your networking, hardware, databases, managed services, etc while you work on your application-level competencies, you stand a much better chance of succeeding ("I don't know if I could build everything from the ground up, but I can probably fumble my way to a container image"). As you become very proficient, you can cut costs, and if you're super proficient you might get off a public cloud altogether or more likely you'll just use that as leverage to negotiate a lower cloud bill.

Interestingly, you don't hear about many businesses that are so competent that they move from the public cloud to their own private clouds. Some people will shout "Lock in!", but I don't buy that--I've migrated between public cloud providers before and it's work, but if you're competent enough to run your own private data centers then you're plenty competent enough to migrate to them.

I haven't looked, so the number after the dollar sign might be going up or down. But if it is not going down by more than inflation then the cost is basically going up.

I haven't found AWS to be predatory. Or Azure for that matter.

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.

Part of the beauty of it is that you don't realize it's happening. You just use more, and more, and more of their services...

No, I don't, and I advise other people not to. The baseline dozen-or-so services are awesome (EC2, RDS, S3, etc.).

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.

Well I am actually in the same camp as you then :)

Title should maybe be switched to "Google Cloud vs AWS Onboarding Comparison for YC companies".

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 was able to get 130k free GCP credits (over 3 years) just by filling out the startup forms... as a complete nobody. You don't even need an affiliate to sponsor you.

I'm not saying anything for or against AWS or GCP. All I'm saying is most startups experience with AWS won't begin with "Send email to dedicated YC email address" so it's hard to draw conclusions from this article about what AWS support is like for "regular" start ups.

While I agree that this is a confound and as someone who also went through the same process, GCP also knows that you're applying as a YC company, and is a PITA regardless - in that way, there's a normalization factor of applying to both entities' startup credit programs with similar social factors. I've heard the same pains with GCP from non-YC founders about the free credits process and from non-YC technologists about bad customer service.

I worked briefly for a startup that changed their name and then got an additional round of credits.

Did you apply via https://cloud.google.com/startup?

I'm in a similar position and those credits would be lifechanging.

Yes, exactly.

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).

What does GCP get in return. If they give you free credit, do you have to give then equity in your company, do you guarantee them X spend, etc?

If you hit it big, you’ll spend on their platform for a long time. You don’t have to explicitly promise anything because you’ve built everything around their platform for months/years.

Moving clouds is hard if you use the cloud features. Giving credits to startups is a cheap way to get them locked in for the future.

If you have enough funds, you might not care about building an efficient architecture, and when the credits run out, you’ll spend more?

Also good PR.

Your future spend. Once you start using them, it would be a decent amount of work to change.

probably vendor lock in

my understanding is that GCP has recently changed their startup programme. I applied a few weeks ago, and had the same bad service as the OP.

Oh you'll pay in the end.

Care to elaborate?

vendor lock-in. Good luck switching away from GCP once you're tied in to their cloud services. Might as well spend the VC money and not worry about moving.

How does spending VC money help with this? You will still inevitably end up getting locked into whatever company you use

How!? I am a VC backed startup, just went through the same grief described in the original linked post.

I like Firebase, but the moment the utility runs out we're heading back to AWS.

Maybe things have changed since I applied - but I have not talked to a single sales person and only communicated via email with the google cloud for startups team. The process was so quick and painless that I at some point felt like I was being scammed and had to make sure I was not going to end up with a huge bill after they pulled the rug out from under me.

> 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 too bad if you use the firebase store. But yeah using the firebase realtime db for anything that requires relationships/indexing can be kinda cumbersome.

> It's not too bad if you use the firebase store

I've built a prototype on top of it and it's fairly rudimentary but you can make it work. My biggest concern is that there are no case studies I can find of people using it past the prototype stage and how the pricing/scalability works out at that point.

We've spent a lot of time working around the limitations of FireStore, but it does work reliably. Pricing is VERY hard to extrapolate from early use; all it takes is one feature request and your assumptions are blown.

Love to hear from anyone who has gone beyond the prototype phase.

Why's that? I haven't looked into it but thought I might someday.

In 2015 I worked at a start-up and was in charge of applying for various cloud start-up benefits at AWS, GCP, etc. At the time getting GCP credits was the hardest and required meeting with a program coordinator after getting a referral from an industry recognized VC. It may have changed since then, bottom line YMMV.

Are there similar forms for AWS? I got 100k credits for my prior YC startup but I'm exploring new projects for a possible future startup and if I could even get 10k credits it would be a big help.

That used to be the case. They recently (last year?) changed it to make it much harder.

If you're planning on building your business on the cloud, the availability of free credits seems like the worst way to evaluate a cloud provider. Generous "free" credits might even be a warning that they have to pay people to use the platform.

If you truly need cloud hosting then that is $130k of free money no? That's more than many pre-seed rounds. If you use that for a bunch of Linux machines running some kinda containers and a non-proprietary database then I don't see any downsides.

This ignores the other big reasons to take losses early, when one is a new(er) player in a market with a dominant competitor.

It's not completely wrong, but incomplete.

Doesn't the same logic apply -- that new upstart is unproven and is essentially paying people to use their platform. The last thing your burgeoning new business needs is trying to debug issues on a brand new platform, you can't even hire industry experts to help because there are no industry experts.

So if you want to work on building your business and not debug cloud provider issues, avoid the new upstart.


This is also pretty specific about needing more free credits than GCP provides out of the box.

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.

Exactly. Google: gives me $300 of credit no questions asked and tells me what things will cost upfront.

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.

I don't really agree with that comment. I think all of the megaclouds have undesirably complex pricing structures, but they also all provide pricing calculators. AWS has one here: https://calculator.aws/

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.

I don't really agree with this comment, because we've gone through year after year of new AWS cost analysis and pricing tools that always seem to miss the mark in a major way that's only obvious in hindsight and always seem to be consistently worse than GCP and Azure. They never seem to fix the flaws in old tools, they just tack on new tools with new blindspots. Hence my comment about cross-referencing. If you're willing to put in a lot of effort across tools, you can get a complete picture, but it really does take a lot of effort and foresight into the exact structure that your solution is going to take (which involves cross-referencing documentation). Amazon doesn't make any effort to quote you a price once they have enough information, they always make you work for it. If a price transparency tool is gated behind enough effort, is it really a price transparency tool?

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.

My experience with AWS customer support was not so good. At the time I had very little knowledge about what I was doing so I can't recount all the details here, but the short version is I had a wildcard cert tied up with a resource that wasn't mine (something on Amazon's side was referencing it) so I could not delete the cert which prevented me from doing something with the associated domain name. AWS has no mechanism AFAIK to report a bug in their system, so I had to pay for developer support (which was expensive to me at the time). Even then, the issue was never actually resolved for me. I think I actually switched to a totally different domain name just to get around it. Here's a support thread where people are having the same issue:


I use GCP now. I find their tooling and UX to be about 100% better and will not use AWS in the future if I can avoid it.

> pricing tools that always seem to miss the mark in a major way that's only obvious in hindsight and seems to be consistently worse than other clouds.

Can you provide an example of a service that the AWS calculator doesn't compute the correct price for?

I honestly can't remember ever being surprised by what things on AWS cost, and I don't think I'm that shockingly good at detecting hidden costs.

Cloudwatch costs have been the ones my coworkers complain about. The one that got me was sagemaker -- the console had a bug where if you went to a region without endpoints, it would pop up a tutorial screen and the tutorial screen would "stick," hiding endpoints in other regions. Which led to hanging endpoints, which were covered by free tier for a few days before costs exploded. We had alerts active, but they alerted when we span up the resources, which was expected, and didn't make it obvious that paging through all the regions ensuring there were no running resources (itself painful) and watching daily costs for a few days was insufficient to ensure that we weren't going to have a $700 bill at the end of the month (or maybe $1400 -- I forget if $700 was the half refunded cost).

When I shared this anecdote at Re:Invent, the sentiment at the table was "lol that's cute, here's my story with an order of magnitude higher price tag." There were 5 or 6 of us, and my story was the smallest surprise cost except for one other person who was even greener than I was.

> Can you provide an example of a service that the AWS calculator doesn't compute the correct price for?

Can you tell me how I should have used AWS calculator to prevent my surprise charge? You can't, because AWS calculator assumes you know exactly what you're asking for, and the problem with opaque pricing structures is that you sometimes don't.

Other clouds tend to be much more upfront about "this will cost X," "this is costing X," "you're out of free tier," etc.

Yeah, that was weird to me also. It just sounds like YC companies collectively use enough AWS to get some premium tier support. I assume GCP has something similar, but YC companies don't spend enough there to get it.

Apples and oranges.

AWS has, for a few years now, had a team dedicated to ensuring that AWS wins all of the successful startup business, which they know may turn into huge amounts of revenue for the few startups that succeed. The team was headed up originally by Paul Zimmerman (https://www.linkedin.com/in/paulsloanzimmerman/); he may be a good person to reach out to if you're hoping for some credits.

I definitely raised my eyebrows at "access to AWS YC slack"

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.

For what it's worth, as a non-YC company, I found the GCP onboarding process to be far superior in every way, and my experiences were essentially reversed. For context, we started with GCP for Startups 1.5 years ago when we were just getting beyond a demo, and with AWS Activate 1 year ago, when we had almost no revenue and just about 1,000 users. We were based in the Santa Fe Business Incubator (NM, USA).

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.

Yeah, I think having a YC dedicated mail address at AWS helps. As I am still waiting for a response from AWS regarding joining one of their programs while GCP response was within the day. All access sorted the next day.

Based on other stories though, the customer experiance between the 2 companies appears to be simliar even if not a YC Company.

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

We got hella (official size) AWS credits by using Carta to manage our captable/409a.

Why? Why can't Google offer the same thing?

Of course Google could offer the same thing. My proposed title change would be even more recommended in that case.

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.

I don't think it's surprising at all that an article posted on a Ycombinator.com subdomain about news talks about Ycombinator-related topics.

It wouldn't help much if they did, seeing as how that would be specific to YC. As such, it's not representative of the general experience.

Not a general experience but common for many incubators, even for some with bootstrapped companies.

I used to be a huge fan of GCP and bet on it to power my startup, and have come to greatly regret it.

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!)

CloudSQL was slow for us until we do the following:

  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
These 3 things have kept our database instances very small and costs low.

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.

Ours cloudsql-proxies were on running on GKE so they were not "that bad".

Switching to private ip definitely had the largest impact by far on performance.

If you need very high throughput I can appreciate this advice. Generally though, cloudsql-proxy is fast enough for most use-cases.

What about running it as a sidecar in the backend pods?

This causes some other problems... Kubernetes doesn't do a very good job of treating the sidecar as part of the main container so you will get random disconnects in your app when the proxy is restarted unexpectedly. This is actually why we abandoned it, just to deal with the random hiccups. Hadn't even benchmarked it.

Yeah, have hugely over provisioned disks for IOPS. Am still using public ip + cloudsql-proxy because the alternative didn't exist when I first deployed, but I'll try switching.

I went through this during last summer. The nice thing is that you can switch to private ip and cloudsql-proxy will still work. At least you can isolate your changes.

> Switch to using private IP addresses. Huge speed increase.

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 honestly don't know what the difference is but the number of hops is probably a contributing factor to the decrease in speed. There could be some translation layer happening when going from the CloudSQL instances private IP to public IP with some security checks that slow it down.

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.

Is it speed of establishing a connection or does it affect pooled connections? What database engine are you using?

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.)

We are using PHP and thus no connection pools at all. This definitely doesn't help us with speed. With public IP there was some mystery point that just slowed everything to a crawl.

MySQL for our DB.

Is the call just so they have a window to upsell you?

100% upsell. Felt like sitting through a high pressure timeshare sales pitch to get the free gift at the end

I got the same treatment but I think I came off as annoyed enough in my message to sales (with an implied threat of just moving to AWS) that I didn't get an upsell conversation.

I just started using Google Cloud SQL – the allure of a managed Postgres service was strong. Can you share some of your experiences with it?


- 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.

> Incredible delay between postgres versions

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.

[1]: https://github.com/CrunchyData/postgres-operator

Amazon RDS waits until the "dot-one" release of a new PostgreSQL major version before releasing to general availability. This ensures that all supported extensions and modules (71 in Amazon RDS for PostgreSQL 13) have been updated to work with the new release and with in-place major version upgrades. Amazon RDS releases beta and "dot-zero" versions of PostgreSQL in the Preview Environment, so that customers can start testing and developing against new features in the latest major version.

I’ve only looked at CrunchyData which does seem like more complexity than I want - I was willing to suck it up pay the premium but the monthly OOM crashes have forced my hand - but to where, I don’t know yet

I need to run Postgres in production soon. I've used AWS RDS (MySQL) in the past, but am also considering Google Cloud SQL.

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.

To clarify, it’s a lot more work than bringing up a snapshot. You need to do a full export as SQL and reimport as SQL. Super annoying, slow, and requires hard downtime.

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.

Why don't they make the upgrade seamless? If it's truly an export/import process, then it should be dead simple for them to do that on their end. Especially after they've snatched your db from serving requests

Interestingly, we don't have any of these problems with MySQL. We have several read-replicas on our DBs and things have been stable.

I will guess that you are much higher scale than us.

Wait what, it's not available through an API? That's ridiculous.

Your project is limited to quota ceilings. Those can be increased if you spend enough money on GCP.

AWS has a similar thing.

Of course there's an API for creating and resizing instances. The issue is there are quotas that cap how many CPUs you can have, and increasing that is a manual process.

64 is awfully low for a sudden manual process though.

Hi Kevin ;-)

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.

Eh. It’s similar in AWS-land.

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.

While you do pay for AWS support, I must say that in my experience AWS support is pretty top notch. I don't particularly like the (somewhat) recent changes where the priority of your ticket is based on your support plan but I'm guessing it's because everyone always chose "critical" when making small support ticket.

In my experience with AWS support, it's a major difference on whether you are asking EC 2 questions or some of the lesser used service questions.

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.

I guess that makes sense. The quality of their support is probably directly correlated to the level of internal tooling to help diagnose issues. For more popular/older services that tooling is probably better.

I don't know about Google's support offerings. But when I worked for a startup that was on AWS, here's what we'd do:

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.

You can do the same with GCP

Last I checked GCP has a minimum one month billing for support. Then again, we're talking about $100/mo here, saving half of that pays for how many minutes of engineer time?

Thanks for adding the AWS perspective.

I guess grass is not greener on the other side. Oligopolies for the loss.

Even in the "millions per month" company realm, I've often felt that AWS treated us like a cash cow to some extent.

Appreciate the additional insight. I really wanted to like GCP - they have good people and good tech.

This whole onboarding felt like some caricature of what I thought were exaggerated stories of how bad the support was.

You can get GCP support for as little as $100/month. AWS charges for support too.


>I have to assume AWS is better.

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.

Support has been very good for us. Their support pricing model changed from percentage of your bill to a fixed cost per support user


For most organizations role based production plan is good enough

> I have to assume AWS is better.

Did you know that the grass is always greener on the other side?

This feels like a somewhat narrow and biased comparison. It is focused around getting startup credits, and while that's important, I think it's a very limited view of onboarding.

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.

I agree, post is very focused on customer support and getting the credits, not at all on product usability. I didn't start building on either AWS or GCP with the expectation I'd have a human to talk to, and from that perspective, GCP was much, much more usable. I found (and find) AWS's interfaces and documentation to be a maze.

>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.

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.

Google's business model is to have no customer service and have customers discard-able without notice when Google chooses. Why would a business want to do business to business with Google and actually pay them at this point? They do 'free' sort of well but they are a terrible option for dependable partner whether you pay them or not.

From GCP docs [0]:

  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.
Given the Google account horror stories that pop up every few months, seems risky if you're solo/only have one GCP owner.

[0]: https://cloud.google.com/resource-manager/docs/project-suspe...

Google will suspend entire accounts even if you have more than one owner.

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.

On the link above there is a separate section for billing account suspensions and it seems to work how you described.

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.

Googler, opinions are my own.

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.

I believe that the "work with a company" guidance is for a dispute (e.g. you ordered something, but didn't get it or are otherwise unhappy) -- not an outright unauthorized purchase by someone other than the card holder. I don't see what most companies would do if you approached them in this case: you have no order number, no information about the purchase, nothing to return, etc.

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.

Point taken. I thought of that same point after I wrote the above.

What happened once the account was reinstated and everything was up again? The customer service obviously sucked; did they acknowledge that and try to make it right?

That's why one should not use GCP for anything

AWS doesn't suspend your account if you chargeback your AWS charges?

Hold on while I go mine myself a ton of crypto coins.

AWS does not suspend your AWS account if there's an issue with you Amazon account. AWS reps are contactable and dare I say it capable of escalating and resolving issues.

The idea that someone could use a stolen credit card associated with an account, buy something on some Google service, have a chargeback processed as fraud and that would trigger Google's suspension of services on GCP is absurd.

> 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.

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.

Having more than one owner is just basic common sense though. What if the single owner is hit by a literal bus?

I was involved in a mid-sized software company migrating from AWS to GCP. My experience was that the GCP team was very hands on, and that enterprise support was very responsive.

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.

Why did the company choose to migrate from AWS to GCP? Just curious.

Not the original poster but we migrated to GCP because:

  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.

Seems like k8s is a big seller for a lot of companies. We don't use it currently on our team and the larger company is whole-sale in on AWS I'm not sure they'd ever be able to make the switch.

Always like to see why people make these big changes though, thanks!

I spent over a year doing a full migration from AWS EC2 + ECS instances to GCP + docker + kubernetes. It was a huge task that has paid off very well.

  1) Costs per customer are lower because you can fit more containers per VM due to kubernetes doing the scheduling for you. Customers also include developer environments.
  2) The number of deploys is way up because there is a simple and established pattern that everyone follows.
  3) The speed of creating new services has increased because of the established patterns with containers, kubernetes resources, and deploys. Thinks days vs weeks to get something running.
  4) The number of Ops issues are lower because kubernetes handles so many things for you. For example, if a deploy is incorrect for some reason, the old service is sitting there running. No outage = no escalation = everyone sleeps at night.

Even if I was a tiny startup, I would still recommend using Kubernetes. The patterns, tooling and insight that Kubernetes gives you will save you TIME. The time saved is worth more than the tiny cost of a 3 node Kubernetes cluster. That is time you can use to develop your product and sell it vs time spent ftp'ing binaries to your Digital Ocean instance. :)

I know you're only picking on Digital Ocean incidentally here, but their managed Kubernetes offering is Pretty Okay. I use it for my personal stuff and it's pretty much everything I expect from a managed Kubernetes offering.

Just don't use EKS. That is managed Kubernetes in the checkbox marketing sense only.

Definitely. I have nothing against Digital Ocean or their offering. It was only an example of a different mindset.

What makes GCP's Kubernetes offering better than the competition?

There are several reasons:

  - Google has a lot of experience running containerized services because of Borg. Google Research says that they have been running these workloads since 2005.
  - The above gives them insight into how to do this well. They would have the internal infrastructure, logging and monitoring already setup.
  - They are the creator and still a major contributor to Kubernetes itself which means they can insert their influence on it.
To be fair, my only experience running Kubernetes is on GCP so maybe they are all this easy to use and run. The internet tells me that other offerings are not as good. Compared to running workloads on EC2 instances and ECS, using GKE is amazing and pain free.

Note: I am responsible for 5 clusters, 300+ nodes total and several thousand running services. Not huge by any means.

The Borg thing is pure marketing.

Amazon also has been running internally on containers for years before ECS. But workloads for massive FAANG companies designed by FAANG engineers turn out to be quite different than most AWS/GCP customers.

Just like EC2 wasn't Amazon selling its "spare capacity during off-peak" but always a purpose built service with completely isolated data centers and network fabric from day 1, the connection between Borg and Kubernetes is tenuous at best.

Honestly, I would encourage you to evaluate ECS and Fargate. Forget Kubernetes and direct instance management. Try a construct like https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws... and see how much simpler it is than all the K8S overhead.

Source: I'm at Amazon but I work on none of these services and opinions are my own. I played with K8S and am eternally confused how it's as popular as it is. I guess it gives you the illusion of not having lock in?

I only have one thing to point out about Borg and that is large numbers of Borg developers started working on Kubernetes. They got rid of Borg mistakes and replaced them with all new mistakes. :)

I don't see K8S being about lock-in at all. Using a cloud provider gives you some sort of lock-in and you should be utilizing that providers strengths.

Using Kubernetes is all about the patterns that it provides and how it removes a certain class of problems for you. Deployments, scaling, logging, etc are some of the patterns it provides and the consistency matters. How many of us have worked at companies where deploying two services have been completely different? One team runs the jenkins pipeline while another ftps the files over. Now multiply that by several services and several tasks (logging, scaling, etc).

The benefit is in the patterns.

1. Is instance management on ECS really annoying enough to justify the higher fargate price?

2. Does ECS have something similar to pods, i.e. colocated containers which can communicate over localhost, share filesystems, etc? A quick search didn't turn anything up.

I was hoping for something more concrete, like limitations or incidents and not just "Google has more Kubernetes experience".

What were your pain points with ECS? Did you use ECS with or without fargate? What about EKS, since that sounds like a closer equivalent to GKE.

That's fair. As I pointed out in another reply, most of my experience is with GKE so I may be spoiled in how painless it is. All I can say is that GKE is treating me well. Node upgrades are seemless, defaults are decent, it was very easy to create clusters through the console or terraform. I only run 5 clusters and that is not that huge compared to others.

I've used ECS more than fargate. My biggest problem comes from reliability and having to manage things. We still run things on ECS and we get about 30x as many maintenance things we need to do, like retiring instances or instances just dying on us and we have to move things off of it manually.

I have a little bit of experience in Fargate from a previous job but not enough to make a real conclusion about it.

I've never used EKS but I do have friends that would rather roll their own version of Kubernetes on EC2 instance instead of using EKS.

maybe they are confused between Google & GCP

Anecdotally we had great experience with GCP support.

GCP Support is not free though.

Neither is AWS Support. But they do have much lower priced offers though.

Some of the GCP stuff works really well, whereas the AWS equivalent feels like a janky afterthought. Looking at you, EKS.

I think this sorts of makes sense for free services like Search, Gmail and Youtube, where each "client" (user) only gives them a tiny amount of revenue.

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.

Wouldn't Google have a very long history of business to business from their advertising platform?

google's propensity for abruptly cancelling products seems like a substantial business risk, too. GCP revenue has been declining, so...

edit: revenue GROWTH is declining

That is not even remotely true. In the latest earnings, Google Cloud revenue grew by 46% year on year, and they said GCP specifically grew faster than Cloud as a whole.

sorry, meant to say revenue GROWTH has been declining.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact