3 ms·
My biggest complaint with Google Cloud's UX, which applies to their new Cloud Source Repositories opt-in UI: They shard out so many of their user experiences in
by 013a 8y ago
My biggest complaint with Google Cloud's UX, which applies to their new Cloud Source Repositories opt-in UI: They shard out so many of their user experiences into different websites and domains.
Under the umbrella of Google Cloud you've got Google Cloud Console, Firebase, Stackdriver, Source Repositories, Dialog Flow, probably a couple others I'm forgetting. Almost all of these have entries on the Google Cloud Console which open a new tab and link you to a new website.
It makes keeping track of where things actually are extremely difficult. For example: Firebase functions on the Firebase UI are also Google Cloud Console functions. The old Google Cloud Datastore product, which lived on the Console, is now Cloud Firestore on the Firebase console. Stackdriver logging used to be on the Stackdriver UI, now its on the Cloud Console, but there are still references to Stackdriver all over that product, and they continue to invest to Stackdriver (Istio service maps).
AWS does this a little bit, in four or five of their hundreds of products. Lightsail is one example. Azure does this a little bit as well (DevOps is a separate page even though its essentially an Azure product).
GCP is the worst offender. I want to see a better unifying vision for what being a Google Cloud customer actually means, instead of all these confusing and isolated experiences.
- derefr 8y ago> I want to see a better unifying vision for what being a Google Cloud customer actually means The thing you've got to understand is that none of these products are "Google Cloud" products. They're Google services (or, even moreso, services of random third parties which Google has acquired) that you happen to be able to hook into from your GCP project and access through the GCP CLI. The closest comparison I can think of is Heroku's "Elements", which are third-party offerings (usually of their own services, with their own service dashboards and everything!) that happen to be subscribe-to-able and high-level-configurable through Heroku's dashboard/CLI. Except, in this case, many of the third party "elements" that are subscribe-to-able and high-level-configurable in GCP, happen to be created by other departments/sub-companies of Google. Still nothing to do with GCP, though, any more than a random Heroku Element has to do with Heroku.
- skj 8y agoI can tell you that your view does not match that of the engineers working on these products. If something is namespaced under a project and you use the cloud console or CLI to manage it, it is very much a GCP product. (I am one such engineer, and have worked on the CLI, cloud build, and container services)
- derefr 8y agoYou’re speaking of design intent, I think. I’m speaking of point-in-time experience from a user perspective. It’s clear what GCP wants to transition toward—but: 1. that’s not where many GCP-aegis’ed services are right now, and 2. newly-absorbed Google properties will always start out looking like this, so there’ll never be a time when GCP won’t look at least somewhat like this (unless the post-acquisition integration process is changed drastically.)
- jchw 8y agoIt is true that a lot of GCP services were once external, like Firebase and Stackdriver, and it is true that there are numerous different domains and UIs that you manage GCP products under, but I believe the future direction is definitely towards unifying things, and the split right now is probably mostly technical. This isn't an official statement by any means, though.
- manigandham 8y agoThat's not quite right. Google Cloud is basically everything, including the Google Cloud Platform (cloud computing), G-Suite, Maps, Chrome, Android, etc. Firebase and Stackdriver are underneath GCP.