Why We're Moving on from Firebase

Re:Why We're Moving on from Firebase by asciimike on Saturday October 15, 2022 @03:57PM (#33218074)

> 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 :/).

[ Parent | on HN ]

Re:Why We're Moving on from Firebase by snovv_crash on Saturday October 15, 2022 @04:35PM (#33218360)

I 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.

[ Parent | on HN ]

Re:Why We're Moving on from Firebase by asciimike on Saturday October 15, 2022 @05:19PM (#33218774)

> 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).

[ Parent | on HN ]

Re:Why We're Moving on from Firebase by js2 on Saturday October 15, 2022 @05:40PM (#33218914)

It was Alan Kay and the quote is “Simple things should be simple, complex things should be possible” and it wasn’t about any specific technology, it was a slogan for what they were building at PARC.

https://www.quora.com/What-is-the-story-behind-Alan-Kay-s-ad...

[ Parent | on HN ]

Re:Why We're Moving on from Firebase by andirk on Saturday October 15, 2022 @05:52PM (#33219003)

How 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.

[ Parent | on HN ]

Re:Why We're Moving on from Firebase by snovv_crash on Sunday October 16, 2022 @04:34AM (#33222099)

This 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.

[ Parent | on HN ]