Hacker News Reader

Comment by dijit | Hacker News Reader

One of the things I love most about google cloud is that "projects" are easy to create and easy to link to other projects.

Roles and service accounts can even reference across projects, though I'm not sure I'd recommend doing that.

No more faffing about with special accounts, passwords and difficult to configure shared VPCs, it all becomes so easy.

Even managing the different accounts is difficult without browser extensions such as this one: https://chrome.google.com/webstore/detail/aws-extend-switch-...

View on HN

I really dislike the Google Cloud way of doing things, for example Projects, Folders and Orgs. There's a dozen different weird paradigms that you have to consider to securely and reliably manage a large number of different projects, accounts, tenants, business units, etc in Google Cloud; if you don't do things "The Google Cloud Way" you are screwed.

AWS is much simpler and more straightforward. You don't have to think about anything to segregate infrastructure, networks, applications, users, data, etc. Just put it in a different account. If someone needs access, you need to explicitly add extra connections/grant that access. You can't just accidentally create one user that implicitly has access to hundreds of accounts.

Honestly the entire security model of Google Cloud is frightening. It's like they wanted to make it easy to expose everything.

AWS is decidely _not_ simpler here. You've got Stockholm syndrome. What's complicated about making two projects and picking between them? What's complicated about grouping projects under a single organization? What's complicated about grouping projects under a folder? What's complicated about adding someone to a project through IAM? The only way you can fuck that last part up is by granting overly broad permissions (which they warn you when you've done right there in the console).

You can safely ignore the existence of Organizations and folders completely if you are so inclined. At least there's a sensible way to set default policies for your organization baked into the platform. Even so, literally 3 hours, tops, and you know everything about these abstractions you could ever care about. I cannot emphasize enough how much easier GCP is to learn and use than AWS.

I think it's the other way around :-)

In Google Cloud, you have to learn all these concepts and use them as Google intends. Oh, you should create a new Project. But to do that you need an Organization. But to do that you need an Identity Source. But you'll need to choose from x or y and have a domain. But... (all this before creating a billing account, or enabling an API, or... ?!)

In AWS, you just have an account. That's it. You can later add-on AWS Organizations if you need to manage a big organization.

AWS is simple and composeable, and GCP is advanced and opinionated. Pick your poison.

You can still work like that. You just don't have to bother changing your project id, and switch accounts to jump to other projects. I do this for some things I work on where there are account level controls and the accounts cant be shared across projects.

AWS SSO has made it incredibly easy for us to secure and manage access to (and switch between) all our AWS accounts in the org.

I'm a huge fan and recommend it.

They recently rebranded it to the super-catchy "AWS IAM Identity Center (successor to AWS SSO)". Gotta love Seattle-based tech marketing people, presumably trained at Microsoft. :)

I guess it will soon be the default user management system, and 'proper' IAM will be the low-level one. I see this as a reaction towards GCP's IMHO superior UX/system design in this aspect. I don't think they can entirely catch up because of early and bad architectural decisions regarding projects/accounts.

Also a fan, so far.

I was originally skeptical when we implemented it because for safety reasons I wanted it to be painfully obvious when I was switching contexts.

It's definitely grown on me, but I frequently emphasize to my teammates that I'd much rather they specify their AWS_PROFILE for each command they run, instead of exporting it into their environment. Especially using Windows and setx seems like an open invitation for disaster.

Author of the article here: I agree. GCP projects are a better abstraction. I still think AWS is, on balance, a better cloud.

I'd love to hear more about why you think that's the case!

Maybe the next blog post?

The killer feature of AWS is that they've broken almost nothing since first launching over 15 years ago. Their commitment to keeping old stuff working is truly amazing.

No other cloud hosting service comes close, because no other cloud service has had 15 years to prove themselves in the same way!

SimpleDB is still running!

I don't know. I've found it to be pretty difficult to answer the question "which of these 1000 gcp projects are running a production workload and which are random one offs created by a dev messing around or by a google sheet script?"

So the problem is the abstraction is so easy to use to get a project going that people just litter them everywhere... how is that a problem with the platform? At least they are actually in one searchable location. How do you find your production workloads if you have 1000 AWS accounts?

In AWS we divide things up into child accounts that roughly match our org tree. Each team or service gets dev, staging, and prod child accounts. Teams have access to their child accounts and its fairly obvious what they all do, or at least, who to talk to to find out.

I think my main complaint with GCP is that it is often tied directly to an org's gsuite account. And doing things in gsuite (used to?) automatically create GCP projects behind the scenes. So you could easily get thousands of projects that the users themselves didn't even know that they had created.

If I were starting from scratch with GCP I'd use a third party IdP and not let users access it via their gsuite accounts. I suspect that would avoid most of the issues I've run into.

We haven't seen that gsuite project problem, but we also don't do really color outside the lines with gsuite. Email, chat, docs, AD, etc.

I solve that by using folders. But when you have many of anything it will become hard to reason with.

It’s not worse than your filesystem, in theory, but speaking for myself: my filesystem is a mess, so…

One reason to have your roles and service accounts reference cross-project is to give your CI builder access to your artifacts project; Have your prod and dev environments use containers from a third account that serves only as an archive of your build artifacts.

Reply on news.ycombinator.com