4 ms·

Great blog article! Good discussion, but there was one element I would like to see discussed more about these 'store your data as a service' is the hidden vend

Great blog article! Good discussion, but there was one element I would like to see discussed more about these 'store your data as a service' is the hidden vendor lock-in! I can understand that when you are pushing for a solution, you make the decision with what's at hand. But this can lock you in to long term decisions, for example people who decided to use Google's app engine. The pricing switcharoo is doubly painful because there is literally no option except rewriting everything! For this reason, I strongly believe that iaas/paas needs to be fully open source. Don't like your provider? Outgrew a provider? Company perished? Fine, run your own. We have somehow switched from open source and the freedom that entails, to open API, and a complete lack of freedom.

jenlankford 13y ago
Hey Ryan, thanks for the comment. So, Orchestrate actually has an on-demand export tool so there is no lock-in. We backup your data into S3 and send you all your data in JSON format. We take zero lock-in very seriously :) http://orchestrate.io/blog/2014/03/12/new-feature-data-export-for-zero-lock-in/ http://orchestrate.io/blog/2014/03/12/new-feature-data-expor...
- alexnewman 13y ago
  But I can't actually run orchestrate.io in my own datacenter? So I don't have data lockin (in the same way that i can select * out of oracle), but I am locked-in to your service?
- ryanobjc 13y ago
  Thanks for the reply! I feel bad even pointing this stuff out, because I know that startups have to do what they have to do to make the bread as it were. I am very glad there is a data export tool, I'm sure that will alleviate some people's concern. But the issue is that now someone has a bunch of code written to an API they have no implementation for. That is the nature of the lock in! Vendors discovered in the 90s that open APIs were very amenable to lock in - for example CORBA, SQL and more. It was really hard to port from CORBA implementation to another one, since non-functional requirements dominated at that point, even if at the API/code level it was compatible. Good luck with your business!
  - h1karu 13y ago
    This is why I'm happy with Couchdb.. I can always replicate the dataset into my own BigCouch cluster if Cloudant one day becomes prohibitively expensive. The thing I'd miss most if I moved from couchdb to orchestrate is the ability to query the key/value store with map/reduce functions. I have to admit orchestrate's graph stuff is cool. For me the only way orchestrate would be a win is if it turns out to be an order of magnitude cheaper than a couchdb based solution for the use cases I care about. The pricing model is intriguing I must admit.. more so for write-heavy apps. I love the concept, good luck orchestrate
  - dizzyd-oio 13y ago
    Disclosure - I’m one of the engineering team at OiO. Now, that aside… :) With the definition of “lock-in” that you’re using, it’s very difficult to find any service that doesn’t cause the user to be “locked in”. There is always a cost to migration from one service to another. That cost might be code changes to support a new API or it might be capital expenditures to spin up a cluster of a bunch of different databases to provide the same functionality, or it might be the cost of hiring a specialized team of ops engineers to run said cluster..or all of the above. :) So, yes, there is a significant tradeoff if you choose to use OiO - you are trading off the cost of building and maintaining a large system of databases for the convenience and speed of development. Even if we open sourced all the code to run the IaaS portion of our system, you’d still have to find the hardware and manpower to run it...and keep it running over the long term. Once you’ve built up your own expertise, you would pay AGAIN if you chose to migrate to something else. There is no free lunch. Every action entails choice and consequence, but Orchestrate is committed to ensuring data portability and freedom to our users as much as possible, with the hope that they will love it enough to stay and use for a long time to come.
  - jenlankford 13y ago
    This topic runs deep, and we could explore for a while. But I thought this blog post might also be helpful in understanding Orchestrate's position on lock-in: http://blog.ilovacha.com/2014/03/17/using-orchestrate-io/ http://blog.ilovacha.com/2014/03/17/using-orchestrate-io/. A user asked us the same question, and was happy enough with the response from our CEO that he wrote a post about it. Hopefully it helps clear some lingering questions. Thanks all for the feedback and keep the questions coming.

jenlankford 13y ago

Hey Ryan, thanks for the comment. So, Orchestrate actually has an on-demand export tool so there is no lock-in. We backup your data into S3 and send you all your data in JSON format. We take zero lock-in very seriously :) http://orchestrate.io/blog/2014/03/12/new-feature-data-export-for-zero-lock-in/ http://orchestrate.io/blog/2014/03/12/new-feature-data-expor...

alexnewman 13y ago
But I can't actually run orchestrate.io in my own datacenter? So I don't have data lockin (in the same way that i can select * out of oracle), but I am locked-in to your service?
ryanobjc 13y ago
Thanks for the reply! I feel bad even pointing this stuff out, because I know that startups have to do what they have to do to make the bread as it were. I am very glad there is a data export tool, I'm sure that will alleviate some people's concern. But the issue is that now someone has a bunch of code written to an API they have no implementation for. That is the nature of the lock in! Vendors discovered in the 90s that open APIs were very amenable to lock in - for example CORBA, SQL and more. It was really hard to port from CORBA implementation to another one, since non-functional requirements dominated at that point, even if at the API/code level it was compatible. Good luck with your business!
- h1karu 13y ago
  This is why I'm happy with Couchdb.. I can always replicate the dataset into my own BigCouch cluster if Cloudant one day becomes prohibitively expensive. The thing I'd miss most if I moved from couchdb to orchestrate is the ability to query the key/value store with map/reduce functions. I have to admit orchestrate's graph stuff is cool. For me the only way orchestrate would be a win is if it turns out to be an order of magnitude cheaper than a couchdb based solution for the use cases I care about. The pricing model is intriguing I must admit.. more so for write-heavy apps. I love the concept, good luck orchestrate
- dizzyd-oio 13y ago
  Disclosure - I’m one of the engineering team at OiO. Now, that aside… :) With the definition of “lock-in” that you’re using, it’s very difficult to find any service that doesn’t cause the user to be “locked in”. There is always a cost to migration from one service to another. That cost might be code changes to support a new API or it might be capital expenditures to spin up a cluster of a bunch of different databases to provide the same functionality, or it might be the cost of hiring a specialized team of ops engineers to run said cluster..or all of the above. :) So, yes, there is a significant tradeoff if you choose to use OiO - you are trading off the cost of building and maintaining a large system of databases for the convenience and speed of development. Even if we open sourced all the code to run the IaaS portion of our system, you’d still have to find the hardware and manpower to run it...and keep it running over the long term. Once you’ve built up your own expertise, you would pay AGAIN if you chose to migrate to something else. There is no free lunch. Every action entails choice and consequence, but Orchestrate is committed to ensuring data portability and freedom to our users as much as possible, with the hope that they will love it enough to stay and use for a long time to come.
- jenlankford 13y ago
  This topic runs deep, and we could explore for a while. But I thought this blog post might also be helpful in understanding Orchestrate's position on lock-in: http://blog.ilovacha.com/2014/03/17/using-orchestrate-io/ http://blog.ilovacha.com/2014/03/17/using-orchestrate-io/. A user asked us the same question, and was happy enough with the response from our CEO that he wrote a post about it. Hopefully it helps clear some lingering questions. Thanks all for the feedback and keep the questions coming.