11 comments

  • jacquesm 60 days ago

    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 60 days ago

      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 60 days ago

        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 60 days ago

          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 60 days ago

      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 60 days ago

        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.

        • chaostheory 60 days ago

          The risk is less when the technology is open source. With open source, at the very least you or someone else can help steward the technology if it's that important to your company.

          • bluehazed 60 days ago

            It is never a waste of time to become a Plan 9 user!

            • coldtea 60 days ago

              >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

              • sterlind 60 days ago

                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 59 days ago

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

            • dingdingdang 60 days ago

              This is why we need truly distributed webapps rather than monolithic tied-to-domain apps. Doing this right is a hard problem and many of current solutions are still essentially centralized despite their reliance on certain aspects of P2P.

              • toomuchtodo 60 days ago

                Open standards are superior to the complexity of distributed webapps. I can port my Gmail account to Fastmail with a few clicks. There's no lock in with my email data. I can put my mail anywhere! That should be the goal of all hosted data; portability, so you're never beholden to a SaaS provider.

                • omnimus 60 days ago

                  But this is also starting to not be true. Gmail is very slowly adding features not in smtp/imap and one day they might just break away and have their closed email. This happened on multiple occasions with xmpp. At one point you could write from icq to hangouts to facebook messanger. After companies gathered critical mass of users they turned off federation. This is one of the main reasons people use facebook messanger (almost everyone has it) and this might happen to gmail quite easily. Almost everyone had gmail at some point so this idea is pretty possible. Many people would then keep gmail account just to comunicate with people who dont have email.

                  • toomuchtodo 60 days ago

                    I hate to beat the dead horse as I often do on HN, but the support of open standards requires constant vigilance. If Gmail begins to "wall the garden off", you must move to a more open provider (such as Fastmail, but any provider providing standards compliant email works).

              • h1d 60 days ago

                These days, I dig for self hosted version for all my needs. It's an interesting task to find there are many interesting projects. I would build one if something is completely missing.

              • Uhhrrr 60 days ago

                Phew, I was worried they were somehow killing http://www.fabfile.org/.

                • jihadjihad 60 days ago

                  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 60 days ago

                  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 60 days ago

                    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.

                    • argo12 60 days ago

                      We follow this exact same architectural approach at hasura.io as well. We are an opensource realtime GraphQL engine on Postgres and just last week we announced event-triggers on Postgres that allows you to call webhooks/serverless functions anytime there is a change in your database. (I work at Hasura)

                      • nslog 60 days ago

                        Have you seen the AWS Amplify CLI along with the new GraphQL transform and codegen features? It largely eliminates the "forces you to learn about graphql" downside that you mention. Here is more info: https://aws-amplify.github.io/amplify-js/media/api_guide#usi...

                        • dabit3 59 days ago

                          One additional feature of AppSync is that you're not tied to any particular database implementation, you can use any database (or data source for that matter, including existing REST APIs & Lambda functions).

                        • wolco 60 days ago

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

                          • pythonaut_16 60 days ago

                            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 60 days ago

                              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 60 days ago

                            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.

                            • skybrian 60 days ago

                              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.

                              • kenhwang 60 days ago

                                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.

                                • skybrian 60 days ago

                                  I agree, but it's not "overnight" either.

                                  • kenhwang 60 days ago

                                    At a speed that's faster than the expected sunset speed of the product without significant impact to your business is a bit of a mouthful.

                              • WA 60 days ago

                                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 60 days ago

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

                                  • kenhwang 60 days ago

                                    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.

                                • segmondy 60 days ago

                                  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.

                                  • 60 days ago
                                    [deleted]
                                    • tobltobs 60 days ago

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

                                      • tango24 60 days ago

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

                                      • vinceguidry 60 days ago

                                        In 2030: app developers band together and refuse all new technology.

                                        In 3030: we're still using Firebase 2030 edition.

                                        • hinkley 60 days ago

                                          Vernor Vinge has a character who comes out of cryo and discovers that code he wrote 500 years ago is still in production. It’s just under layers and layers of abstraction. He proceeds to pwn a bunch of hardware to aid a counter-conspiracy.

                                          • small_fish 60 days ago

                                            Great book.

                                            "What specialty do we need the most?" "You mean that can bring us the most income? Obviously: Programmer-Archeologist."

                                            • ourmandave 60 days ago

                                              I assume his editor is still vi.

                                              • tty7 60 days ago

                                                What book?? That sounds like an awesome read

                                                • danibx 60 days ago

                                                  A Fire Upon the Deep

                                                  • notsofastbuddy 60 days ago

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

                                                    • justinclift 60 days ago

                                                      Yeah, seems to be A Deepness in the Sky:

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

                                                      • mrdoops 60 days ago

                                                        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.

                                                    • avinium 60 days ago

                                                      I was thinking exactly the same thing!

                                                      • 60 days ago
                                                        [deleted]
                                                  • 60 days ago
                                                    [deleted]
                                                    • sahin-boydas 60 days ago

                                                      so true.

                                                    • sahin-boydas 60 days ago

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

                                                      • amaccuish 60 days ago

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

                                                        • jazoom 60 days ago

                                                          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 60 days ago

                                                            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 60 days ago

                                                              My point was Google didn't name the product.