My intuition, and some experience sitting in meetings with GCP folks, is that their engineering teams don't dogfood their own products end-to-end sufficiently (e.g. including billing) on a daily basis, like their customers have to.
The amount of blank stares and "Oh..."s that happened when asked about relatively simple, everyone-would-need-it use cases for management, visibility, etc was mind boggling.
GCP feels like Google rediscovering being Microsoft of the 1990s. If you have strong product teams, but no strong overarching experience teams, your resulting system is going to be a hash of well-polished but distinct products, with an extremely ugly unification layer.
Hardly a surprise. From what i have heard, it sounds like Google's internal use of GCP is mostly automated, using internal apis. I.e. it sounds like are not clicking through the screens, or even using the external version of the APIs. I question if the externally available screens are even capable of handling some of the special permissions that google internal workloads can be given.
This is in contrast to say Azure, where plenty of Microsoft employees are using the same resource manager APIs and even using the portal. I think even the billing related features get used as part of internal budgeting (they want teams to try to keep resource utilization reasonable). While teams developing parts of azure itself may be utilizing internal APIs (for example Microsoft Graph is basically just a giant wrapper around a variety of internal APIs), most of the rest of the company sees and interacts with azure in the same way we do. (Except that they also have access to dogfood/PPE environments that we don't, such that endpoints for say integration tests don't need to run on production azure).
It's true enough, but it never really felt like teams solicited feedback on their APIs or portal UX. Azure really only made this jump to using all public products internally recently; even the CI systems used by internal teams were proprietary until recent pushes to move to an ADO-centric model.
I'm also not certain that Azure really has the right internal pressures to produce great UX results. In my experience Azure's culture internally is very lackadaisical with only a few teams really pushing the platform forward.
As a power GCP user, I see them running UX studies all the time. Having been using GCP for the last decade, the UX updates feel like day and night changes. Frankly I find the AWS console a lot creekier.
> This is in contrast to say Azure, where plenty of Microsoft employees are using the same resource manager APIs and even using the portal. [...]
And still they don't have this incredible complicated and not understandable IAM. Most user I know just give everyone root because it's not possible to just allow some specific API operations for a specific set of credentials. Or maybe I am to AWS.
I really do think this dogfooding is why AWS is successful. Amazon's businesses run a lot of their workloads on AWS. Amazon is AWS's largest customer. So AWS has the benefit of having thousands of heavy use customers internally to discover bugs and edge cases and provide feedback.
For example, I contributed a fix to AWS documentation as a SDE in the Kindle org. This is the kind of improvements you get with dogfooding.
Billing is terrible, although it has gotten a bit better. Cognito is probably one of the worst services on AWS, and it's only getting worse (there are now two SDKs with different APIs for no reason at all). While things like EC2 and Lambda work pretty well.
Same for Google. Everything that's in use by Googlers is pretty dope - calendar, video conferencing, docs, search obviously, maps, etc. Everything that's not - less so.
You can tell which parts Amazon dogfoods! Billing is terrible, although it has gotten a bit better.
I don't have much detail on Amazon's policy, but there was an AWS devrel on Twitter a while back saying they had to run and pay for their own AWS account as if they were any regular user for their own playing around/research/etc.
I was reminded of IBM trying to get them to show up and actually sell things. It is _bizarre_ that you have to hound sales people to actually make an effort — it really seemed like they assumed the Google brand was enough to guarantee buyers and were surprised that anyone would question whether their products were the best.
(This was also the first time I heard Reader mentioned at the C level as in “what will we do when you cancel it?”)
Well, not everyone but it tended towards influential groups — they burned so many tech journalists that it really seemed to usher in an era where goodwill was no longer assumed.
It reflects the company culture. Unlike Amazon, where customers experience is their top value, at BigG they seem to build stuff for the sole gratification and ultimately promotions of engineers and managers. They don't seem to care much for their customers.
It's easy to dogpile on BigCo, but this is selling the employees and teams short.
They definitely care about their customers, and many things were made better through subsequent fixes.
But the larger point is that the processes and mid-high+ level management structure at Google don't seem to prioritize cohesive, customer-centric experience. Which means teams will always miss things... because the process doesn't ensure they're caught.
The amount of blank stares and "Oh..."s that happened when asked about relatively simple, everyone-would-need-it use cases for management, visibility, etc was mind boggling.
GCP feels like Google rediscovering being Microsoft of the 1990s. If you have strong product teams, but no strong overarching experience teams, your resulting system is going to be a hash of well-polished but distinct products, with an extremely ugly unification layer.