"There are two ways to make money, bundling and unbundling." - Jim Barksdale
The quote is mostly provided in jest, but at the same time there are many customers who want something totally bundled that solves 90% of their problems in 20 minutes but literally can't solve the last 10%, and there are other customers that want generic building blocks that can solve 100% of their problems, even if it takes years to do.
I think it makes sense that Google offers customers both.
> But even Firebase isn't strong enough to resist the gravitational pull of the GCP behemoth.
Part of the reason we got acquired is because of the above: we knew that we had a number of limitations (e.g. infra scalability) that could be solved, and we knew that GCP had DX problems offering a bundled mobile offering (App Engine wasn't "mobile" focused).
And that acquisition really paid dividends: we were able to build a _ton_ of "bundled" services for Firebase by 2016, and continue deeper integrations with GCP (Storage, Functions, Firestore, Auth, etc.). There are definitely UX differences (some of them intentional, due to different audiences), some not (e.g. it seems like not having an integrated log viewer is a DX miss, though my assumption is that staffing on the Firebase side is down so the decision was made to just send folks to the GCP console :/).
Easy things should be easy, and complicated things should be possible.
The problem with GCP is that a bog-standard setup is considerably more complicated than it was before. Maybe the config files are roughly the same, but there isn't a single dashboard where you can see everything from storage to instance usage to queue delays anymore. Instead there are a bunch of dashboards, each with way too much detail for getting a broad overview of your metrics.
> Easy things should be easy, and complicated things should be possible.
Was he being serious when he said that? I'd hardly call regex a technology where easy things are easy and complicated things are possible (there are plenty of impossible things in regex implementations e.g. backtracking in RE2).
https://www.quora.com/What-is-the-story-behind-Alan-Kay-s-ad...
Never trust google.
If folks want to build proprietary APIs, and people choose to use them because they are faster/better/cheaper/more suited to a particular use case, I'm not sure why that's a bad thing.
Engineering is tradeoffs, proprietary API surface is one of many things people consider.
For things like push- and email notifications, it makes more sense that a provider is involved (although APIs should probably still be open). New innovations can always start out proprietary, and the inventors can always offer support and managed infra for OSS projects.
Why? I believe the health and future innovations within the tech sector relies on healthy competition, and imo, that means that the majority of standard services have multiple providers to choose from. The only way to migrate from one provider to another is through standardized, or open, APIs. VPCs is a pretty good example of this: I can get the premium option from GCP or AWS, and have uptime, bandwidth, and choose a DC from all over the world. OTOH, I can get a cheaper, local one, depending on my needs.
Cloud computing was a term at least as far back as 1999. We didn't have the technology quite right that soon, but we had the idea and the term:
https://en.wikipedia.org/wiki/Opsware
https://www.wired.com/2000/08/loudcloud/
Archived version of Wired article: https://archive.ph/TeLPQ
I went digging and found an earlier WIRED article on General Magic, using the word a few times [2].
And back in the 2000s, CERN was having a go at their own cloud infrastructure, with the name of Grid Computing.
The reason people liked it is, imo, because it was a single product with multiple features. GCP OTOH, has been about decoupling (or loosely coupling) the product suite, and users are supposed to pick and choose from a giant array of half-products. Simply being aware of all products, their interoperability and predicting the cost is a full time job, easily (it's mostly large enterprise who can absorb that cost). There's nothing wrong with the pick-and-choose model, if your products are simple, low level, and interoperable. But the product suite has grown organically, seemingly without coherence, so there's very little in terms of paved paths to walk – it's so confusing. When a shining star like Firebase comes along (2014) Google clearly knows not to mess with it too much. But even Firebase isn't strong enough to resist the gravitational pull of the GCP behemoth.