Firebase expands to become a unified app platform

Re:Firebase expands to become a unified app platform by mybigsword on Wednesday May 18, 2016 @03:04PM (#11724790)

You should never use products like this where you are completely vendor-locked and will be unable to switch easily to another provider. I did this mistake before and we used SQL Azure Federations (cool & cheap autosharding for SQL Server), then Microsoft decided to discontinue it and provide only very expensive up-scale version of SQL Server instead. We spend months to migrate our product to PostgreSQL... and this is just an example, Google also love to discontinue products, probably even more than Microsoft.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by pritambarhate on Wednesday May 18, 2016 @03:18PM (#11724918)

I did this mistake with Parse. The open source version released doesn't have full features and we have run into a few bugs which created a lot of issues.

It's better to stick with open source stack. I like what Amazon is doing with AWS with services like RDS and ElastiCache. If one carefully selects the services on AWS, there is almost zero vendor lock in.

Google also had hiked the AppEngine price in Sept. 2011 which caused a lot of problems to early adopters.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by toomuchtodo on Wednesday May 18, 2016 @03:20PM (#11724939)

> It's better to stick with open source stack.

This is a hard lesson each person learns on their own.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by TeMPOraL on Wednesday May 18, 2016 @04:35PM (#11725687)

The difference is actually between a product and a service. A service is something that another party provides, and that may - actually, they most definitely will - at some point stop providing, for various reasons. You want to minimize your dependence on any services - especially ones that are not trivially replaceable or that don't come with contractual agreements to cover your costs in case of the service being shut down.

That's why I hate the whole SaaS idea - it turns products into services; something that should be permanent (as long as you can maintain the hardware it runs) into something that is ephemeral and ever changing. It's great for the service provider, but it totally sucks for the customers. SaaS drives entropy in the computing universe.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by csears on Wednesday May 18, 2016 @09:35PM (#11727326)

I totally respect your perspective, but SaaS is gaining popularity because software customers are making an informed decision about the tradeoffs of product vs service as a delivery model, not because service providers are forcing the SaaS model on them. Many customers see value in shifting the operations and support burden to the software vendor. I think it's ultimately good that users have more choice in how they consume software. Diversity is positive for the computing universe.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by dbb01 on Thursday May 19, 2016 @01:48AM (#11728278)

The key though is that you want to use open source software that some company has provided as a service so you get all the benefits of SaaS without the lockin. Heroku Postgres for example. If Heroku shuts down or is no longer an option, you just spin up with a different PostgreSQL service provider, or run it yourself with no code changes.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by ceratopisan on Thursday May 19, 2016 @06:21PM (#11734332)

Software customers are sometimes making informed decisions, and sometimes basing their decision on building a platform that has a time horizon of "until we get a lot of funding" or "when we get bought by a larger company". In both cases, that is long enough to not worry about whether the SaaS that forms an integral part of the product will last.

I'm not making a value judgement; I'm pointing out that SaaS is often picked for only its short-term benefits.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by igravious on Wednesday May 18, 2016 @10:18PM (#11727491)

That's why we need SaaSaaS. That'll fix it.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by inlined on Wednesday May 18, 2016 @03:57PM (#11725333)

Check out my upcoming talk "Migrate to Firebase", today at 3. I specifically cover how to use new Firebase features to add all the missing Parse product lines back to ParseServer

Link: https://events.google.com/io2016/schedule?sid=b4641ff7-0bef-...

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by kuschku on Wednesday May 18, 2016 @05:49PM (#11726270)

And when will Firebase become a product we can self-host? Because until that is the case – or unless people do an SLA regarding Firebase – it has to be considered as reliable as a 2$ VPS.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by dragonwriter on Wednesday May 18, 2016 @05:56PM (#11726313)

> or unless people do an SLA regarding Firebase

https://www.firebase.com/terms/service-level-agreement.html

Though I think what you are looking for is Firebase being covered by a Deprecation Policy.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by dandelany on Wednesday May 18, 2016 @04:30PM (#11725630)

> We spend months to migrate our product to PostgreSQL

Which means you presumably saved months initially by using Azure, and got your product to market sooner. Everyone should be aware of the dangers of lock-in, and should carefully consider the value of it vs. the liability they're taking on. But I wouldn't say never use products like this. The value-add can be significant, even taking into account the fact that you may have to migrate off of it someday.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by CobrastanJorji on Wednesday May 18, 2016 @04:46PM (#11725798)

That MIGHT be true, but it's not apparent from their statement. Just because it costs N to build a product on technology X and costs M to migrate an existing product to technology Y does not mean that it would have cost N + M to implement the product on technology Y in the first place.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by carolus4 on Thursday May 19, 2016 @04:48AM (#11728866)

I think the point made above is that it's enough for implementation(X) < implementation(Y) in order to sway some people to technology X. Rapid prototyping is an example of this, since the time-value of feedback is higher before the product is well defined.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by dandelany on Thursday May 19, 2016 @01:52PM (#11732132)

You are correct of course, my point is that even if cost(implementing Y originally) < cost(implementing X and later migrating to Y) it may still be worth it, because the cost has been deferred. Time is often a lot more valuable in early stages of a startup.

[ Parent | on HN ]

Re:Firebase expands to become a unified app platform by vacri on Thursday May 19, 2016 @02:21AM (#11728391)

From experience, changing databases on a product in flight is not trivial. Even moving our production database from an external vendor to an in-house location (exact same database engine and version) was a decent-size task, and would have been much, much easier with greenfields or a chunk of downtime.

[ Parent | on HN ]