4 ms·
One way in which I've often thought about it is that whenever you build something on a foundation over which you have no (or little) say or control, then at lea
by ls65536 6y ago
One way in which I've often thought about it is that whenever you build something on a foundation over which you have no (or little) say or control, then at least work to make it possible to be able to substitute that foundation for an alternative in the future. Or at the very least, be aware of the risks that come with such an arrangement and mitigate them appropriately.
Even beyond software or cloud-based tech, this can be useful to think about and apply even more broadly in life, for example when consideing any variety of real or virtual tools, platforms or services that you may depend on.
- MaxBarraclough 6y agoThat all sounds sensible. As you say, deliberately committing to lock-in isn't necessarily a mistake. The Amazon Aurora managed database solution looks very impressive, for instance, and I imagine it could make good sense to use it despite the lock-in. In that instance, the service is compatible with MySQL/Postgres, but I imagine it could still be a considerable challenge to move away from it (moving from one high-availability Postgres-based database solution to another). The upsides may outweigh the downsides of lock-in, but the upside needs to be substantial.
- WrtCdEvrydy 6y agoThe real lock-in is the IAM on Cloud. Aurora to anything else is fine since you can take a snapshot and move it to another engine easily.
- MaxBarraclough 6y agoI was thinking the worst case would be something like Google Cloud Datastore, a proprietary 'managed-only' database that isn't compatible with any existing product. I think there was an attempt to make a Free and Open Source drop-in replacement, but I don't think it got far.