3 ms·
> 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 prod
by asciimike 4y ago
> 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.
"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 :/).
- snovv_crash 4y agoI believe it was the inventor of Regex who said: 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.
- asciimike 4y ago> I believe it was the inventor of Regex who said: > 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).
- js2 4y agoI think (as applied to technology) it is originally an adage from Alan Kay and he worded it as “Simple things should be simple, complex things should be possible.” It wasn’t about any specific technology but rather for what they were building at PARC. https://www.quora.com/What-is-the-story-behind-Alan-Kay-s-adage-Simple-things-should-be-simple-complex-things-should-be-possible https://www.quora.com/What-is-the-story-behind-Alan-Kay-s-ad... Larry Wall adopted (adapted?) it for Perl: “In a nutshell, Perl is designed to make the easy jobs easy, without making the hard jobs impossible.” https://www.quora.com/What-is-the-origin-of-the-phrase-make-the-easy-things-easy-and-the-hard-things-possible https://www.quora.com/What-is-the-origin-of-the-phrase-make-...
- andirk 4y agoHow about: easy + common things should have tools built for them out-of-the-box, and complicated things should be offered a path to the bare metal.
- snovv_crash 4y agoThis is an engineering choice by RE2 to not support backtracking or lookahead in exchange for runtime guarantees. PCRE2, which is not much more complex, supports both of these, but doesn't give the same runtime guarantees as RE2. For someone who is operating on vast quantities of unknown, unsanitized data, eg. Google, RE2s limitations are a reasonable tradeoff to make to avoid DOS situations from malformed or malicious inputs.