I’ve hear a lot about the amazing internal tools at Google but why on earth is GCP such a mess outside Firebase? You’d think they would lead in developer experience from the way people talk about their internal tools but it’s just as bad as AWS: opaque, not enough examples and hard to figure out what services actually do
Am I the only one who’s sitting here like, GCP is ok? Not great, just ok. It’s the ham sandwich of cloud services.
A ham sandwich with a million buttons that each do different things, sure, but it’s not impossible to learn the ones you need, and they rarely break. How many times have we seen apps fail one of those criteria?
It also has the distinction of printing a massive amount of money and being a huge competitive advantage over other ML institutions — like, say, Facebook. So it seems obvious why developer experience wasn’t prioritized, just “ok.”
The GCP web console and CLI tool(s) are... Fine. Better than AWS in my estimation, but YMMV.
But using it, I feel deeply in my gut that there has to be a better way. But I've not seen anything across any of the major clouds that is much better.
It's in a weird situation in that GCP and internal tools aren't really unified, unlike people's (reasonable) expectation. GCP and internal stuffs shares a fair amount of underlying technical infrastructures but their developer facing endpoints are separated so chance for dogfooding GCP is fairly limited. To my knowledge there has been lots of attempts to solve this situation but you know migrating infrastructures of Google Search is not something trivial...
1) GCP/AWS/Azure etc all do a lot of things. Hundreds of services each? It's tricky to build out a good UX that exposes everything they do; and different customers all have very different workflows.
2) For awhile Google wanted to move more new development onto GCP (an effort called "Google on Google"), but it had limited traction and has been abandoned AFAIK, because internal tooling, infrastructure, and devex was just so much better than what GCP had to offer.
Google on Google basically died as a result of a specific attack. A group of malicious actors over the holiday season attempted to compromise all of Tor by running a truly massive number of GCP nodes to succeed in a majority-control attack. Site reliability discovered how positively primitive the tooling was to mitigate such an attack... Not only was the GCP tooling not ready for prime time on an attack of that scale, but they were not able to use the regular tooling that they were accustomed to because GCP instances were encrypted for user privacy reasons. And one of the things that sets Google apart in terms of its corporate design is that site reliability has the leadership authority to tell management all the way up the chain "no."
1) is a platform problem though and honestly I don’t think it’s that complex to be able to explain in plan English what your services do and who on a high level should use them. It’s Byzantine on purpose I feel like.
Google's internal tooling is too tightly coupled to Google's infrastructure, so GCP had to start from scratch on a lot of it.
Rather than force the teams who developed the original tooling inside Google to develop a similar public facing commercial product, they had GCP developers write parallel tools, or they bought third party tools and tried to integrate them. Both solutions proved not as easy as management had hoped.
Working with google's APIs tends to be a nightmare too- varying authentication methods, documentation of various ages, etc. If you're not using their libraries it's a huge pain to my experience. (And their libraries aren't the easy sort of wrappers where you can just pluck logic out easily either a lot of the time)
