
Google is killing Fabric in mid-2019, pushes developers to Firebase - sahin-boydas
https://venturebeat.com/2018/09/14/google-is-killing-fabric-in-mid-2019-pushes-developers-to-firebase/
======
jacquesm
This is one area where self hosted solidly wins over anything service
oriented: you are in control to the point that _you_ , and not some company
somewhere can make the call on when a product is no longer viable. The
decoupling that we had with licensed software that you run on infrastructure
that you control is pretty close to ideal for the customer. You give the
provider of the software a one time payment and after that it literally is
your problem. At the same time that is what enabled SaaS, companies do not
like it when they have one-shot income over something that might generate
recurring revenues, and end-users do not want to have to deal with the hassle
of installing, maintaining, backing up, keeping secure and updating all this
software.

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.

~~~
aikah
Saas can get a product out fast. But yes, unless one has some kind of special
contract with a Saas company ensuring the continuity of the service as long as
one needs it, never rely on Saas for too long, unless the solution is open
source. For all we know Firebase could be gone in 2/3 years...

~~~
crooked-v
This is why I really like now.sh. They've put a ton of effort into fitting the
patterns already in use for self deployments, with only a tiny bit of overhead
on that for env vars and domain configuration (~10 short lines of configs for
one of my current projects).

~~~
acoard
Your post made me checkout now.sh which does look really cool, but it really
is a poor example here.

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

------
rohan1024
Dammit not inbox. I've been using it since the beginning. You know this is the
kind of stuff that prevents me from diving too deep into there tech and
products. I love flutter but I'm scared about its fate.

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.

~~~
rch
These things come and go. One could have been just as wrong to focus on
Silverlight, OpenSolaris, SmallTalk, etc, etc, etc, or even your own company's
ABI....

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.

~~~
coldtea
> _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._

[https://en.wikipedia.org/wiki/Opportunity_cost](https://en.wikipedia.org/wiki/Opportunity_cost)

~~~
sterlind
it's hard to gauge opportunity cost, since architectures fade in and out of
popularity and patterns succeed where the frameworks that introduced them
fail.

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.

~~~
coldtea
> _it 's hard to gauge opportunity cost, since architectures fade in and out
> of popularity and patterns succeed where the frameworks that introduced them
> fail._

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.

------
Uhhrrr
Phew, I was worried they were somehow killing
[http://www.fabfile.org/](http://www.fabfile.org/).

~~~
jihadjihad
Wow, it looks like they finally added support for Python 3.4+. I had kind of
abandoned Fabric due to the lack of support past 2.7...this is fantastic news!

------
xrd
Firebase is revolutionary. If you haven't used it, it means you can remove
your reliance on all the server side logic you currently maintain. It is a
huge philosophical change but is the perfect complement to serverless
architectures.

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.

~~~
aplummer
I’ve found it’s only good vs your own stack for small prototypes and MVPs, and
that the debt builds up faster than anything else I’ve ever used (the cost
too!) but YMMV.

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.

------
wolco
Why move to firebase when it will be shutdown when it becomes useful?

~~~
pythonaut_16
Firebase seems to be pretty integrated with Google's GCP strategy, as well as
Android push notifications with FCM.

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.

~~~
kuschku
FCM is only the third in a row of push notification solutions for Android
(preceded by C2DM and GCM), and it'll be replaced someday, too.

------
kenhwang
Just a reminder that, if you critically depend on a IaaS/PaaS/SaaS, you should
be able to trivially replace it, sometimes as quickly as overnight. Having the
service be completely open source so you can self-host generally helps, as
does open protocols and standards.

Especially important when it's a Google service given their historical speed
of deprecation and abruptness in announcement.

~~~
WA
If you can trivially replace it with something else overnight, the SaaS might
be a bit too simplistic to use in the first place, no?

~~~
henryfjordan
Or there is healthy competition in the space.

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

------
segmondy
The first step to using Google is to seek an alternative or to accept the
reality that at some point the good times must come to an end.

------
tobltobs
In 2020: Google is killing Firebase in mid-2021, pushes developers to
[NextGreatToolWhatever]

~~~
tango24
In 2025: Google decides to focus only on Search, Maps, and Mail; shuts down or
divests all 243 other "side projects".

~~~
hinkley
Including Angular 57.

------
sahin-boydas
In 2019: Google decides to focus on Google Analytics and shuts down Firebase

------
amaccuish
Firebase is the worst name ever. Literally it describes absolutely nothing. I
really wish Google would take a look at naming.

~~~
jazoom
Google acquired that company.

And the name even has half the word "database" in it, which is much more
descriptive than most tech names.

~~~
FireBeyond
You know what else happened around Firebase?

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.

~~~
jazoom
My point was Google didn't name the product.

