7 ms·

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 befor

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.

deleted 10y ago
[deleted]
pritambarhate 10y ago
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.
- toomuchtodo 10y ago
  > It's better to stick with open source stack. This is a hard lesson each person learns on their own.
  - TeMPOraL 10y ago
    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.
    - csears 10y ago
      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.
      - dbb01 10y ago
        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.
      - ceratopisan 10y ago
        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.
    - igravious 10y ago
      That's why we need SaaSaaS. That'll fix it.
- inlined 10y ago
  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-e511-a517-00155d5066d7#day1/b4641ff7-0bef-e511-a517-00155d5066d7 https://events.google.com/io2016/schedule?sid=b4641ff7-0bef-...
  - kuschku 10y ago
    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.
    - dragonwriter 10y ago
      > or unless people do an SLA regarding Firebase https://www.firebase.com/terms/service-level-agreement.html 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.
dandelany 10y ago
> 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.
- CobrastanJorji 10y ago
  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.
  - carolus4 10y ago
    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.
  - dandelany 10y ago
    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.
- vacri 10y ago
  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.

deleted 10y ago

[deleted]

pritambarhate 10y ago

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.

toomuchtodo 10y ago
> It's better to stick with open source stack. This is a hard lesson each person learns on their own.
- TeMPOraL 10y ago
  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.
  - csears 10y ago
    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.
    - dbb01 10y ago
      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.
    - ceratopisan 10y ago
      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.
  - igravious 10y ago
    That's why we need SaaSaaS. That'll fix it.
inlined 10y ago
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-e511-a517-00155d5066d7#day1/b4641ff7-0bef-e511-a517-00155d5066d7 https://events.google.com/io2016/schedule?sid=b4641ff7-0bef-...
- kuschku 10y ago
  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.
  - dragonwriter 10y ago
    > or unless people do an SLA regarding Firebase https://www.firebase.com/terms/service-level-agreement.html 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.

dandelany 10y ago

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

CobrastanJorji 10y ago
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.
- carolus4 10y ago
  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.
- dandelany 10y ago
  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.
vacri 10y ago
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.