Live data from Hacker News

Google Cloud vs. AWS Onboarding Comparison

kevinslin.com

361–370 of 394 posts

Re: Google Cloud vs. AWS Onboarding Comparison

#361

I still don't understand why startups go through the hassle of using cloud, trying to get customer support for unknown and half-baked cloud products and spending enormous money - rather than focusing on building the ACTUAL product? just go rent some VMs/bare-metal and focus on building your product, everything non-product related is just a waste of time, money, and effort. it looks almost as if engineers forgot how t…

Because startup credits are free money? Also, the basics on all major clouds are pretty baked at this point.

they are free like when a heroine dealer will give your first two needles for free.

cloud offerings are massively overpriced and their goal is to hook you up to their ecosystem and then eat into your margins once your startup lifts off

Re: Google Cloud vs. AWS Onboarding Comparison

#362

Earlier quoted context omitted.

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. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

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

Re: Google Cloud vs. AWS Onboarding Comparison

#363
I literally had the opposite experience - a couple of years ago I was leading a data team designing a cloud-based solution and migrating the company from bare metal.

*AWS* - Lots of sales calls, but eventually redirected us to a "partner", who came up with basically a lift-and-shift.

*GCP* - The Regional Business Head was in direct contact. We were provided almost limitless access to a very helpful and experienced Customer Engineer - who spent _weeks_ with us, designing architecture, doing presentations, giving us learning material and eventually was instrumental in my team's increased capability and skill level to do the new infra design. Both came to visit the office several times. Eventually more senior engineers got involved.

We were also repeatedly given generous credit extensions. And best of all - there was a GCP summit in the country, during which I literally had a sit-down with PMs from a lot of GCP's product offerings - including Spanner, BigTable. 1:1 video calls with PMs from FileStore, Dataflow and BigQuery as well as early access to some key features.

Worth noting that we were hardly a "big" customer, or a huge money spender. Perhaps it was the technical challenge that interested them, or perhaps the reputation of the company/founder in the region. Whatever it was, I've had great experience with GCP.

Re: Google Cloud vs. AWS Onboarding Comparison

#364
post #238
post #232

Earlier quoted context omitted.

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.

Re: Google Cloud vs. AWS Onboarding Comparison

#365
post #218

Earlier quoted context omitted.

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

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.

Re: Google Cloud vs. AWS Onboarding Comparison

#366
post #347

Earlier quoted context omitted.

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 succe…

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 survey…

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.

Re: Google Cloud vs. AWS Onboarding Comparison

#367
post #271

Earlier quoted context omitted.

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 star…

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.

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.

Re: Google Cloud vs. AWS Onboarding Comparison

#368

Earlier quoted context omitted.

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)

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

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.

Re: Google Cloud vs. AWS Onboarding Comparison

#369
post #294

Earlier quoted context omitted.

This feels like working really hard to solve a problem that isn't yours. Why not just get your services from a company that will support you? Why is GCP worth doing this for?

Because GCP has objectively better data services than AWS, and GKE. EKS sucks. AWS data offerings outside of RDS are not as good as Google's. AWS hierarchy also sucks. GCP projects/folder mechanism is vastly superior, also org policies.

I'll echo this reasoning as one for choosing GCP. Many of the offerings are fantastic on their own - BigQuery, Pub/Sub, Dataflow, Firestore, Cloud SQL, GKE - they're all (IMO) great products that my teams have used to work wonders. On top of that, they're all well integrated and more seamlessly work together in my experience vs AWS services.

I've also found integrating access controls via IAM to be really powerful and also pretty user friendly. In one experience, this helped us scale the sales process and allowed us to easily address sales push-back on data security and compliance.

Also, engineers really seem to enjoy using the cloud console, even at later stages when it was mostly just read-only and had a lot of access controls. The UX is just way better than AWS.

As mentioned, I've experienced issues with GCP and there are reasons to choose AWS instead. I can expand on these if anyone is curious, but wanted to list out the reasons to use GCP, as I feel like most of the posts you see about GCP on HN skew more negative than my own experiences.

Re: Google Cloud vs. AWS Onboarding Comparison

#370

Earlier quoted context omitted.

> 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 engi…

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.
Post reply on HN