Throughout the development stages of Orchestrate, we spent a lot of time talking to developers about what THEY would want to see in a service like this. We conducted developer focus groups, took surveys, and had a lot of one-on-one conversations to make sure we were addressing as many concerns from the developer community as possible.

It was no surprise to us that data portability and vendor lock-in came up time and time again. Our CTO, Ian Plosker, took a moment to address lock-in head on.

orchestrate-ian-plosker

What do people mean by “lock-in” when talking about databases, mobile backends (MBaaS), and infrastructure-as-a-service (IaaS)?

Lock-in is, essentially, the inability to move your data from one service to another should you choose to. And users worry about this for good reason. With no easy way to get your data out, you might get stuck using (and paying for) a service that you’re unhappy with.

Many service providers use lock in as a strategy for retaining users – but the tactic can resemble a hostage situation rather than reflect true user sentiment and loyalty.

Even with an easy way to free your data, there is still “data gravity” to consider. The more massive your data set, the stronger a hold your provider has on it. Simply put, more data means there is more data to move. And finally, vendor-specific features can also yield a sort of lock-in. If you rely on a feature specific to one provider, moving to another can prove difficult.

Is this a legitimate concern?

Data lock-in is a very legitimate concern. Here are a number of scenarios to consider:

  • The provider removes a feature that your application data requires to function properly
  • A promised feature critical to the next iteration of your application is never added to the service, leaving your project incomplete and lacking important functionality
  • Prices get hiked up without your knowledge or consent
  • The service cannot, or will not, comply with specific security or privacy regulations required for you to do business
  • The provider loses control of customer data, either by being hacked or by order of a regulatory authority
  • The service is shut down and ceases to exist, taking your data with it

Without the ability to extract your data at any time, any number of scenarios could put your entire business or project at risk.

What is Orchestrate doing differently to ensure users don’t have to worry about lock-in?

First, Orchestrate wants its users to have complete control of backups. Today, we make daily backups of your data, allowing us to restore user data should disaster strike. Soon, we’ll be enabling daily dumps to a specified S3 bucket of your choice. With Orchestrate, you own your data, and you can take it at any time.

In the future, we’d like to offer ways to stream updates to our users in real-time. What this means is that users could maintain an independent copy of their dataset in a solution of their choice, so that moving to an alternative would be as simple as flipping a bit in a configuration file.

From the perspective of features and pricing, we’re doing everything we can to engender trust. Trust is hard to earn and easy to lose. It’s not a commodity, it’s not a currency, and it can’t be traded. Honesty is the only way to build trust. We strive to be honest in our communication and transparent with our customers and community. We will let users know where features are in the development pipeline, and when they can expect changes to our service.

If I were a user, could I leave tomorrow?

Assuming you had a “Plan B” ready that allowed you to take your backup and transfer it to an alternative solution, yes.

Orchestrate recommends, as a best practice, that consumers of any and all cloud services have a “Plan B” in place should any aforementioned scenario arise.

How would I move my data?

Take your backup and import it into the service, database, or databases of your choice. It’s that easy.

Could I just use another database like ElasticSearch or MongoDB?

That’s a possibility. Orchestrate is not a database. It’s a service that amalgamates the features of multiple database into a single API. Assuming you only use a subset of Orchestrate’s features that map well to a specific database or class of database, you could easily move to that. If you rely on a broad spectrum of our features, you will need to replicate those features, either in your code or by using multiple databases.