Google is killing Fabric in mid-2019, pushes developers to Firebase
venturebeat.com
venturebeat.com
Even so, every time I sign up for some SaaS component I am very much aware that I'm giving up something precious in terms of control, and every time I read an announcement like this one (or the Inbox one the other day), I'm happy that we do our best to use as little services by outsiders as possible.
* It's a SaaS with monthly fees.
* now itself doesn't support self-hosting (i.e. the `now` binary will always use the now.sh backend)
* Consequently, if now.sh closes down you can't continue to use it.
* When it comes to hosting the code you upload, it appears to require you to use a cloud hosting provider (Aws, Azure, etc). You can't point it to a box of your choosing.
Flutter, Dart, Fuchsia these are some great technologies but they might end up in bin some day.
In the end, I tell myself, I'm just a user. Imagine what must be the state of developers who spent years working on these products but then this happens in entire industry. It's just I expected better from Google.
And is it really wrong to spend a couple of years becoming an expert Plan 9 user just because it doesn't take over the world? I still think it's all (mostly) time well spent.
I doubt Rob Pike and Ken Thompson would give up the experience of writing Plan 9; its lessons persist in Go and other systems they've designed. Google's tech stack was pioneered by systems programmers who built their career writing for supercomputers, forced to target commodity hardware.
Patterns have a much longer shelf-life than their originating products.
It might be hard but it's also necessary. That's true for many other things that are hard.
What would the opposite be?
Have people adopting any new technology and losing several years of their lives studying a doomed fad because without evaluating its long term potential and opportunity cost because it's "hard" and "architectures fade in and out of popularity"?
Instead, we should encourage people to do the hard thing, and evaluate things that they intend to study and their opportunity cost before they devote any substantial time with them.
Some will still get it wrong and invest in the wrong tech, but overall doing due diligence before jumping in will be better than just blindly going for whatever catches their fancy or is hyped.
>I doubt Rob Pike and Ken Thompson would give up the experience of writing Plan 9; its lessons persist in Go and other systems they've designed.
That was their job and they were paid for it. And Plan9 was also their own creation and original research.
That's not the same as some third party devoting themselves to a new technology just because it looks cool, it's hyped at the moment, etc.
This is smart by Google. AWS AppSync provides much of the same functionality but gives you the benefit (if you already know Graphql) of Graphql. Or, it forces you to learn about graphql, which is also the downside. Forcing Fabric customers into the firebase ecosystem makes it look like this was a cheap acquisition from Twitter after all.
The huge win with either platform commitment is you simply focus on your data and forget about the challenging problem of syncing that data across all the platforms. That's (multi client sync) a big, big, big challenge and no one does it well on their own.
I use the analytics heavily though, the built in network reliability and performance analytics you get for 1 line have literally saved my company millions of dollars. Mentally it was hard to ditch direct GA but it’s really so great.
Not saying concern over Google's commitment to various tools is unfounded, but it seems that generally things that are tied into their core goals are pretty safe.
GCP is very important to Google, Inbox was an interesting UI built on top of Gmail.
Especially important when it's a Google service given their historical speed of deprecation and abruptness in announcement.
Good examples of what I consider trivially replaceable would be services like Pingdom, DNS, S3, Cloud SQL since you can either easily build a "good enough" version, switch to another provider, or deploy your own from source.
Good examples of services that are very hard to switch off of are things like Cloud Firestore or AWS Lamba.
I think OP means you should write your interfaces with SaaS such that changing to a different provider is relatively easy (just rewrite a little client code or something to fit the new provider to your abstractions).
Though of course, even with notice, migration can still be annoying.
In 3030: we're still using Firebase 2030 edition.
https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...
Recently read A Fire Upon the Deep personally, and don't recall much/any mention of it there. :)
"What specialty do we need the most?" "You mean that can bring us the most income? Obviously: Programmer-Archeologist."
And the name even has half the word "database" in it, which is much more descriptive than most tech names.
I was a customer of Divshot, a "static web hosting service" that was merged into the Firebase team at Google, so it's not quite as clear as made out.