Hacker News Reader

Comment by valuearb | Hacker News Reader

I like Firebase, but will never use it unless I absolutely have to. It's not anything they've done, it's what happened to Parse. I built a half dozen apps using Parse as the cloud backend because it was so easy.

My last project my CTO chose Parse to build a backend for a Website. Parse Cloud Code was fairly limited, we'd have to do a separate server for Stripe for example, but again it made the specific client project really easy to do (and he had been tasked on building it really cheap given our crazy CEO had given the client a fixed bid). I knew it was screwy but said "At least we can be confident that Parse isn't going away any time soon" since Facebook had bought them.

I finished the site on time, on budget, the web service demoed great at it's launch show, and the client signed up a ton of customers and was just waiting for our e-commerce implementation to launch their important new business.

Then Parse was canceled.

View on HN

Firebase engineer here. We recognize the anxiety that comes with a hosted solution. That being said, Firebase has seen enormous and growing investment from Google (see e.g. Fabric acquisition).

Firebase feeds directly into two huge businesses that Google cares deeply about: Cloud and Ads. I can't predict the distant future, but unless Google's core business shifts drastically Firebase isn't going anywhere.

>>Firebase isn't going anywhere.

If experience has taught us anything, it's that it's pretty naive to say this about anything owned by Google. I mean, things like Google Wave and Google Buzz were huge initiatives at one point too.

Is it possible things will change? Of course. I was just trying to illustrate that, unlike Parse and Facebook, Firebase has a clear relationship with core Google businesses.

We will never be able to fully dispell these worries, but I think there's pretty strong evidence in support of Firebase's prospects. Our developers will have to judge if the value we deliver is higher than the small-but-non-zero chance of it going away.

I certainly think it is, but I'm pretty biased. :)

So, I see this argument over and over again with re: to Google, but what I've never seen is Google closing shop on anything in their GCE offering. This certainly doesn't mean it's not possible, but I'm not sure comparing the discontinuation of one-off products to any of the GCE offerings is fair.

It's absolutely possible I'm being naive here - just one person's take on the situation.

Most of the canceled Google products have been free, consumer-facing, chat apps. Have they canceled any cloud products? App Engine's been around for like a decade now.

The two examples you have aren't really comparable.

In the case of Google Wave, this was an experimental new way of communicating. I remember it being cool and exciting at the time, but I definitely didn't get the impression it was a commercial product. And afterwards they ended up open-sourcing the whole thing as an Apache project.

Google Buzz was a little less experimental, but as another poster mentioned, it was a free consumer product and second it ended up being superseded by Google+.

> Firebase isn't going anywhere.

Yeah, I heard the same about Parse.

This looks really really bad. Take a look at this list:

https://en.wikipedia.org/wiki/List_of_Google_products#Discon...

Never say never. You just don't know when another team comes out with a slicker implementation and makes that part of the cloud offering. That being said, I find the firebase part of the current cloud offering to not be as slick as the other offerings. For example, for me to use push notifications, I have to use Firebase. It should be it's own standalone service like Amazon SNS.

FCM is a standalone service, it's just branded with Firebase instead of Google like before.

Could Google/Firebase commit to open sourcing the code, and making sure everyone (who wants to) can seamlessly transition off Firebase, if the product is to be euthanized? If there was a transition contingency for anyone who depends on Firebase, that'd make depending on Firebase less worrisome.

Those concerns would be greatly addressed by having an "on-premises Firebase" option, even if everything went sideways, I could slowly migrate my projects off of firebase slowly.

While I feel better when Google acquired FB, I still would like the ability to switch away from FireBase (costs, China firewall, etc). I couldn't find something like a 'database abstraction layer' I had with SQL. Thought about writing a store-FireBase interface, then I discovered GraphQL & GraphQL cloud dbs....

FireBase's analytics are very strong though, would be on top of list if I wanted to do something outside GraphQL again.

Hi Tom! We really like how easy it is to get started with Firebase or Parse, but like you mentioned, we're convinced that GraphQL is the future of APIs. That's why we're building Graphcool (https://www.graph.cool/) which is a Serverless GraphQL Backend. Here is a short tutorial on how to get started: https://www.youtube.com/watch?v=SooujCyMHe4

Regarding the ability to "switch away": https://www.graph.cool/docs/faq/graphcool-moving-projects-aw...

I also used Parse on a project. They pulled the plug on Parse half-way through our development. I recommended to client that we switch to Firebase. Client asked "couldn't Firebase go away some time?" I answered that I was sure that Firebase would go away some time. But in the mean time, we are using Firebase and are very happy.

I think that a bigger risk than Firebase going away is Firebase deciding to fire you as a customer.

> I think that a bigger risk than Firebase going away is Firebase deciding to fire you as a customer.

This is what it felt like at one point a little over a year ago. I host a SaaS on Firebase with some paying customers. They started having infrastructure problems and I was down for a whole week. Despite me sending them specific curl commands that reproduce the issue (30-second latencies followed by 500 replies), they really didn't have the same sense of urgency that I had. At first, they didn't even seem to believe me that there was a real problem happening.

After several days they finally fessed up to the problem, and then like a day or two later, my app started working again. The incident left a really bad taste in customers' mouths, and who can blame them... I was lucky not to lose them all!

So for a week, Firebase effectively fired me as a customer. My impression is that the outage didn't affect a large portion of their users. When that's the case, you end up needing Firebase a whole lot more than Firebase needs you.

For me, the Parse story, albeit I never knew it in depth, or intimately or even directly as a user, is the best summary I can find, is where OSS fails: the huge blind spot of freedom when it comes to hosted solutions, where the OSS licenses fail to apply. In extremis, this has created the precise opposite of a rich commons, for giants such as Google would not likely exist, if they were required to release their code if providing a service was considered strictly to be "publishing" the OSS licensed software in a modified form.

It has allowed, for instance, a strong supporting argument to use Azure, where we have desired cloud delivery, certainly over a number of smaller cloud service providers that could have contended. In any event, wherever we have found need for supporting tools or deployment tools, or any instrumenting facility, our decisions have gone against any small independent or startup supplier who value add atop OSS, at least in any critical code paths.

I should add, in my Dictator For A Day fantasy, I would also write into copyright law, a requirement that all defunct companies incapable of discharging in full their tax obligations, become required to deposit their source repositories as public domain articles. I don't know what the US equivalent is, but in the UK, defunct company works become copyright the Treasury Solicitor, i.e. Crown property, which the Treasury Solicitor may then express no interest in, subsequently letting the copyright ostensibly (bar pre-existing, prior, claim) to pass into public domain. So, in a obscure and narrow sense, my wish does actually exist, in one jurisdiction, for some rare cases, including one I pursued.

I fear, as intrasight notes, very much indeed fear that there are dangerous factors in the way dependencies are introduced, how users, nay whole startups are enticed (if not lured) into relying upon "ZeroSLA" circumstances, which are the antithesis of the objectives espoused by the open source founding progenitors and movement generally. The ominous prospect of being "fired" as a client and customer, ultimately at the pure fiat of "benevolent giants" possessed of fathomless resources from which mere mortals pray for beneficence, seems to be not a science fiction future, but the dystopia of the present. As recent stories, including that about GitLab, but also comment abroad about FB's code practice, and a apparent generational disconnect from past established (and even vilified) "enterprise values" increasingly reveal, it is insufficient to simply blame even severe mistakes, on young highly intelligent management, for there appears to have swept across the programming world, a cultural lack in oversight, that is becoming a measurable, real, present, risk. It isn't a subject I like to contemplate much, because it is so hard to suggest positive, immediately actionable, clear insight or values that apply, except by applying such in immediate practice, wherever one can, and even so "enterprise culture" is also values, and in a cultural mismatch, such things are incredibly hard to argue effectively, when a complicated balance has to be struck. Certainly, this is far harder, than it was twenty years ago, when one felt it possible to align with one or another of the fresh, youthful, enervating movements that have since swept consciousness and created so much economic activity, even amid general recession. Only, the net effect, and net economy, is a vision far far removed from one I think anybody ever hoped to see. Who, for instance, following the anti trust trial against Microsoft (which riveted me, and I ended up reading the bulk of transcripts and depositions, which I am not sure one can even find online any more, but were a education themselves) ever imagined four - letter oligopoly was the next, potentially final, stage? Certainly, it is no longer as simple as "pick a license" ....

ninja edit: typos, minor clarity

Azure due to the on-premise Stack option?

If so, and in the unlikely event MS pulled the plug on Azure, would the premise components still operate?

Azure Stack is currently limited to a single box IIRC, which would also not present a full fallback option: https://docs.microsoft.com/en-us/azure/azure-stack/azure-sta...

Hi bsg75 !,

i simply can get no version <1800 word, that gives the barely cursory depth i think adequate to answer you other than trivially, and hence without much value. Three takes, three emphases. But it is a important question to answer, and indivisible from my own judgement as of now, and historically.

So my attempts - 3 each clean typed in a flow, i always write the same way - will end up combined, at my repo, https://github.com/amygdyl in a hour i guess from now, after dinner:

But in short,

yes, Stack is for one box. The "retail" on prem, is 4, IIRC, bit worried April was the last "unofficial" promise from HPE... The datacenter nodes are 800+ servers a piece.

I'm not writing atop Azure, per se. Azure Functions can call COM+ wrappers.... My relevant history starts early 90s, when I remember being gobsmacked Microsoft Transaction Server was bundled with NT 3.5.1. CICS interop. That excited a young me. This was BigTime facility. MTS is still one of the few external dependencies of SQLServer. It was cross platform, hence SQLServer / Linux.

www.clear.bank is the first UK clearing bank, so fully patched into the economy, this is who fintech might use, or smaller thrifts... and runs "on Azure".

Hmm "runs on Azure"?

My money is going on a core runtime... to me Azure is a delivery mechanism... CICS is a great conceptual model for Azure, if Azure delivers on prem properly... the network design and architecture related CICS to Azure far better than all the mainframe hegemony which was okay for text and book buying, but misapplied... I do not care for much the way cloud is done, but i do care for cloud as a idea, because it is tome, not as Larry Ellison mocked, dialing into servers, but more intelligent distribute computing. Functions, which are almost uunresticted, use many more languages, compared with AWS Lambda, are the means to enable a far more distributed (not mega CD to mega DC, but truly disperse) computing future.

So I think Azure ha real legs as a design.

And, well I joked when Azure was more PR than real, that it was Don Box's revenge. Well, Azure really is DCOM and AD retaking the world. Or Zombie CORBAclypse... Not without reason is David Cutler another Azure lead... take the encumbrance of Win32 emu, hardware compatibility off of NT, this past 2 years. That is what Azure is. So it is VMS, basically! Well, a better remake.

Now, if I told you this new bank connected into the UK economy, had chosen OpenVMS, to be safe when starting processing ppayroll and fintech demand... would you be worried?

If I said, this is OpenVMS v 10, Core Super Legere, Could Version?

Well, once you checked out VMS a moment, you probably would not be much troubled by the news, in any event.

Same news.

(Incidentally, another thousand words later, I finished writing my appreciation of the tremendous and significant things I have managed to learn, since engaging on this site, only days ago. Those, too, i'll add to the repo. I was really, truly, surprised. An I am absolutely .. it is good, i think if you read my piece on what affected me, the fact it is good transpires self evidently. I hope if nothing else, you'll take a look at that. You asked the best question, re Azure. Almost half my reply, responds to a second question: why should Azure survive, c.p. regardless whether it can do so economically, i.e. what real reason should it not cease to be one day, and the world be no poorer. This as a cool writing excercise, I got to question myself more than I everr imagined, right down to why my take on the GitLab / Ceph debacle do distorted my own insights, throwing actual insight right away. One part, beginning that, was how hard it is to gain exposure to "enterprise" type engineering, how really hard it is to "go buy a Hitachi array" (ten years in business, IME!) and how only by accident could our then growing company, even get a salesman to quote us SUN servers...But I missed the value, and was - am - quite deeply affected, all result of here.

I really should have added a little, about the interesting bits of Azure, far more on what I hint at, about Azure being NT and AD unleashed, and i go on., about how i think Azure means we'll deliver "windows desktop shrink wrap" to linux clients, sooner than later, despite AWOL dot net core graphics libraries. I think Azure is inherently more open, thn "crude mainframe" deals, and meanwhile Apple will enter eventually, with some means to leverage their amazing silicon. And integrate so iOS native apps you write, automatically integrate with Office 365, so you deliver native first, desktop speed, on iOS, and they can have my whole wallet, checkbook and cards already if they do that, and i believe they will. There is something fishy, about how only mature industry races to the bottom on price, yet cloud services are so new... so numbers or other data are not right. Azure does on prem, some front end disty, maybe full f/e even, but the hybrid strength make them the IBM of a future middle scale business world. Apple i think must ... iOS is .. if they host the "missing" bits, the things we cannot port from OSX, if we even only can run thoes eon their cloud, but Apple make compiling to get that peak perf out of their silicon? Heaven. IBM Bluemix / Softlayer, might be the bare metal kings. Plus very targeted competition for SQLServer, and DB/2, you have to wade thru many brochures, but the tech pushed down relentlessly to even free licenses, is remarkable. DB/2 explains SQLServer feature/pricing moves. (When IBM let a puny little business, writeCOBOL and validate their CICS runtime against megacorpmainframe EDS/EDI, but they will not, you feel the brick wall of "CICS is the same, even totally erroneously "DB/2 is the same" as a mantra, a force field, long before, that pushes product halo down to small systems). AWS - gotta be forever startupville. AWS's breahthrough wil lbe when they realize just how valuable their support backing is, if they can provide the service contracts a real Tier 1 likeIBM (theoretically) can, tostartups, because so many startups build product to deliver what a big customer needs. AWS could transform SV here. Also imagine if AWS, keen to land a big nines SLA contract if a GitLab type customer is acquired, fielded real impartial advice? Right now, Hitachi HDS data protection suites will use S3.... there need be no loss of face, or data sales, for Amazon. The could provision and lend some HDS kit., arrange via their own channels, a most prominent customer to resoundingly endorse their "insurance grade DR solution Gitlab Engineered, and are making available across their customers from today, until a full review establishes root causes and solutions are in place"... Who else are there... But i can see differentiation, I forgot Google, somehow I think Google will not get the love they want. Google are the Emperor's clothes... the public has felt the missing .. they feel something is missing, with Google. I think FB ought to stopadvertising on their pages, and become the world's biuggest advertisign broker. That way they totally invert everyone's concerns. Adverts cost at most 40% what people pay. That is trillions in dollars of waste solved, enough to kickstart the entire global; economy. Hundreds of billions each and every year. FB profits can triple, quadruple, still vast shot to the arm. People will communicate freely, then send their brand / business / even personal ad messages, through massively invigorated, diverse, media, print included. That not only should happen, it could happen. This is the one thing I would ever trade my proverbial right arm to get chance top speak with MZ about anything. That guy could change the global; economy, in one fell swoop. S'long as I get the print trade magazines... Nope, nah, no way, no i would be a terrible tycoon, a worse accidental undeserving one. I don't even want to have my on business, I just want a better advertising business, and better publishing business, and a new actually real market where there never was one... in this millennium no real market for the most vital industry maybe of all...? I am certain this is why MZ look and sounds not quite right, because that industry goes against everything he ever thought was right, bet you my last breath I am correct on that. Unproveable, but if true very unproveable.

for bsg75 - i only hope one can in future host other's Azure apps, with your local cloud kit... that may take a awful lot of things to get done right, by who has Azure on prem... but if they can do this, if my ... if I can have a rack or two, and it is just a hop away, i used to be line of sight to customers long ago... so optical beat our leased line.. if i could be local proxy / edge... then this entire distributed cloud idea begins to really work.

Agreed, it makes no business sense to store all your core business data in a cloud that you have so little control over and which pretty much any Google or Firebase employee can browse at will. You're putting yourself completely at the mercy of the service provider (fully exposed) without any leverage when it comes to bargaining.

It's like renting office space from a landlord who owns all the office buildings in town - You're completely at their mercy because you have no alternatives. Eventually, they will squeeze all the profits out of you because they can.

Anyone who understands human nature can see what's going to happen in 10 years or so.

Ok, but Parse was opensourced, so you could basically just run your app on that, or am I missing something? If you wanted to use cloud offering, I'm sure you could pay someone to take care of it for you. Are you worried about future development?

Other than that, there really are no guarantees. Project leads move on, companies close and get acquired, projects get replaced... I had to develop for 3 different google cloud messaging platforms for the same app, and I don't even consider myself Android developer. Such is life.

What parse open sourced is not what they were running on their backend. It also now doesn't come with devops, new features, etc.

Wasn't it? I didn't use them, but their shutdown notice [0] reads like they opensourced whatever is needed to keep client apps running.

I agree it sucks though. The code gives you more time, but since it's not maintained and actively developed anymore you still need to migrate to another platform eventually.

[0] http://blog.parse.com/announcements/moving-on/

They gave you something equivalent to a single server solution. So for simple apps it's fine, but if you have a complicated app that needs a lot of distributed networking to handle the load then good luck.

Don't forget you also need to migrate all your code, host your own servers, handle downtime, etc.

"There is no cloud, only someone else's computers." Building on an external platform is fine for expediency, as long as you have a backup plan.

I completely agree. Parse at least was not too different from a vanilla Mongo setup. Firebase on the otherhand looks brutal to move/switch away from.

Given that Firebase hasn't shut down yet, and they just announced Firebase Cloud Functions and stuff, I think that is a pretty strong sign of healthy growth.

Firebase (and Rethink) are some of the bests out there, and like Slava said about license concerns, why worry about what might happen... when using these systems let you avoid worrying about a bunch of painful things NOW?

I'm still the type though that prefers to use Open Source tools and not have vendor lock in, though. That is why we're building https://github.com/amark/gun which I often describe as an Open Source Firebase. The goal is that it is self-healing (P2P architecture) so you don't have to worry about DevOps either. Recently we ran load tests on low end hardware doing 2K table inserts a second across a federated system - and we hope to get this up to 10K table inserts a second on a free Heroku instance (if this is physically possible).

That said, use tools that make your life easier NOW, be that Firebase or not - the future is always going to have its own challenges.

One thing you can do is look at how much the company has invested in the product. There may be a reasonable risk they may shut it down if it doesn't tie into other products that the company offers and they don't try to integrate it with other products (Parse). On the other hand Google has invested heavily in Firebase and it offers far more features than when they bought it, and it integrates with many other Google products.

(Disclosure: I work at Google, though I'm not connected with Firebase.)

This is a sentiment we struggle with a lot at https://www.graph.cool

Being based on GraphQL (an open standard) and AWS lambda (a service that most certainly isn't going away) helps, but it is tough.

What would it take for a hosted backend to make you comfortable using it?

Complaining about change in tech world?

Change is fine. But it also impresses upon me the value of open source technologies.

But Parse was opensourced, before it was turned off.. And opensourcing doesn't help with offloading operational complexity anyway. So I fail to see how these are connected.

> But Parse was opensourced, before it was turned off.. And opensourcing doesn't help with offloading operational complexity anyway.

In theory, it means you can pay someone other than the original owner to handle the operational complexity for you (so long as the whole stack, including any necessary backend pieces, is open-sourced); it doesn't guarantee availability, especially at a price you are willing to pay, but it does mean that it's legally possible.

Reply on news.ycombinator.com