Live data from Hacker News

Google is killing Fabric in mid-2019, pushes developers to Firebase

venturebeat.com

31–40 of 60 posts

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#34
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.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#35

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.

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?

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#36
post #32

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

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.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#37
post #21

Earlier quoted context omitted.

A Fire Upon the Deep

I think it's the prequel, A Deepness in the Sky. I thought A Fire Upon the Deep had even cooler concepts though.

Both are great reads. Fire Upon the Deep had some cooler concepts, but narrative-wise I prefer Deepness in the sky. The emotional response I had to the memory-control-slavery aspects made my blood boil.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#38

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.

That seems a little exaggerated. It looks like Google Cloud terms of service promise a year's notice for products in general availability. I don't think they've broken that promise?

Though of course, even with notice, migration can still be annoying.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#39
post #35

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.

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?

I guess the nuance of my statement would be, trivially replaceable doesn't mean build a better product.

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.

Re: Google is killing Fabric in mid-2019, pushes developers to Firebase

#40

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.

That seems a little exaggerated. It looks like Google Cloud terms of service promise a year's notice for products in general availability. I don't think they've broken that promise? Though of course, even with notice, migration can still be annoying.

In my opinion, a year is not a lot of time for any complex integration with a service. Compare that to AWS which still support effectively-retired products indefinitely.
Post reply on HN