Hacker News Reader

Comment by dantiberian | Hacker News Reader

The truly interesting thing to me about this product is the pricing. Competitors in this space sell software starting at ~$5,000 all the way up into 5, and I presume 6 figures.

AWS is giving away their software and only charging for the hardware to run this migration software on. The catch is that you need to be migrating to AWS resources which you are paying for. I'm sure this tool will have less features than the more established competitors, but for customers that fit the sweet spot, it will be very attractive.

Disclosure: I know some of the people at http://www.dbvisit.com/, a database migration company, and competitor to this.

View on HN

You can migrate in our out of AWS, but one or both of your endpoints needs to be on AWS.

I wonder if you could realistically do a two stage migration, X -> Amazon -> Y

Amazon probably wouldn't care if you did. They still get paid to shuffle the bits.

What they really want is keep you on RDS, not just get paid for the migration bandwidth.

Sure. But by forcing you to go through RDS even if you migrate X->RDS->Y, they are halfway there.

In the process you need to set up an AWS account, create a RDS database, import your data into it... and perhaps you stop there despite the initial plans. Or use RDS for your next project, since you are already more familiar with it.

Well it's in Amazon's best interest to get people to use and migrate to their infrastructure at the end of the day, so it's no surprise that a service that helps you move to AWS is competitively priced.

The lock-in is where the catch is right.

There's not a whole lot of lock-in using an rds instance. It's MySQL.

... with automatically managed updates, backups, monitoring, auto-scaling, auto-replication ...

The managed services are a huge part of the lock-in with AWS services, because even though they generally cost more than the competitors, they can often come out equal after accounting for those aggregate hours lost to doing those things.

That's what you call "paying for a service." Lock-In is an entirely different matter.

Lock-in happens when migrating would be expensive, too. And leaving a managed service like this could introduce substantial cost.

When the vendor lets you export your data in a form that you can easily import into your own copy of the exact same software, I fail to see how that is "lock-in". If the vendor increase the cost of the service or changes other terms in a way that's unfavorable to you, you can easily leave, that's the opposite of lock-in.

You can't really accuse a vendor of lock in just because his product is priced lower than it would cost you to do it yourself.

I think that's a very rigid definition of "lock-in" that implies it must be done with some anti-competitive malice. That's not how I've encountered the term in my past, so I'm welcome to other interpretations.

Per (not authoritative, obviously) wiki:

"In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs."

I agree with this. It shouldn't require that the service is purposefully preventing you from changing; lock-in can occur because a service offers advantages that prevent changing by virtue of some other cost.

"lock-in" implies some sort of lock. "I don't won't to leave because the service saves me so much money" is not a lock, you can leave, you just choose not to because it's better for you to stay. And if the vendor increases his price you can just take your data and go - your same application will run on another vendor's hosted MySQL instance.

If I say I'll pay you $1 if you sit in my office for an hour, you can't say that you were "locked in" by me, if Mary offers you $2 to sit in her office, you can walk over to her office and get more money.

That definition makes it very clear why people are disagreeing with you. Switching costs are those incurred by the difficulty of switching, and not the marginal cost of one provider or another. If internet provider A is $80 / month, and provider B is $60 / month, the switching cost has nothing to do with the $20 monthly discrepancy, or any speed differences, and rather represents how easy it is to cancel my subscription by being on hold for hours or cancellation fees.

Operational costs != switching costs.

You can backup/restore and run your database on basically any hosted service so switching costs are trivial here.

It's not lock-in if you don't want to leave – that's just being competitive. Real lock-in would be something like removing an export function or introducing a proprietary storage backend with incompatible semantics so anyone leaving would need to rewrite application logic.

If you want to talk lock-in, look at services like Lambda where there isn't a direct counterpart (although the model there is so simple that most users could port relatively quickly).

Is it really "lock-in" if you use it because it's cheaper and better for you and migrating somewhere else is as simple as a database export?

I can see something like DynamoDB being vendor lock-in since you can't just download your data into your own self-hosted DynamoDB instance, but if you're using a standard off-the-shelf RDS database (MySql, PostgreSQL, Sql/Server, etc), I don't think you can call it lock in when you're staying only because it's easier than running it yourself.

Lock-in refers to the effect of being unable to change vendors due to switching costs. This can be things like a large amount of effort/money required that a company just cant afford or sometimes the lack of any other vendor who can even offer the same product or service.

In this case, there is basically 0 switching cost since relational databases are everywhere and you can always take your data/schema with you. This new migration service actually makes it even easier than before.

There is no lock-in.

The whole idea of a migration service which lets you migrate to or from an AWS resource means there is no lock-in.

Reply on news.ycombinator.com