Over the last several emails we looked at how Django projects can become subject to lock-in of one kind or another, from third-party APIs, to Python libraries, down to the databases your application uses.
Before archiving this topic I wanted to leave you with something of a framework for assessing both the depth of lock-in (alternatives and transition costs) and the benefit-risk balance.
The first facet to look at is uniqueness, the extent to which the product (which could be a third-party web API, a Python library, database, etc.) differs from the available alternatives.
If you’re dealing with databases and find that a new database offers some really nice features but sports a backwards compatible API, then it’s uniqueness value, for the purpose of assessing lock-in at least, is pretty low.
Examples include MariaDB/MySQL and may even extend to a database like CockroachDB which supports the Postgres wire protocol.
You can reduce the uniqueness risk by using an abstraction layer, e.g using a geocoding library that supports multiple geocoding services as backends.
This is one is trickier because its much more subjective. A good example for third-party APIs is the comparison between Facebook and Stripe.
If you use Stripe’s API chances are pretty good you’re a paying customer, whereas for Facebook’s API that’s not necessarily the case. Ad buying and API use aren’t one and the same there.
Aside from that, my own wishy-washy perception is that Stripe is a more trustworthy organization which reduces my own fears about potentially getting locked into their product.
Not sure you can say that about Oracle…
When you’re looking at Python libraries like Django apps, it helps to see that the project has a minimum level of support for version changes in Django and a tractable issue backlog.
There are two aspects to this facet: (a) if this component fails or degrades, will your app do the same and (b) is this component fails or degrades, will your _business _do the same.
Or, the degree to which it is technically critical and then separately business critical.
If your billing system goes down, this is very bad for business. But depending on how it is integrated your application may still be able to deliver value to customers.
If a geocoding library or API is used to add some geographic flair for users, then it’s probably the case the technical and business coupling are both low.
Whereas if that geocoding is necessary to provide accurate and up to date legislative district information, then the business coupling is probably quite high even if the technical coupling is lower.
I’m excited to come back to this in more depth later, but in short: what’s your risk tolerance vs. your need for immediate payoff?
Even in the face of better alternatives, the immediate solution may be quicker and easier to adopt. This is bad, right? It’s lazy, right?
Not necessarily.
If it affords you the time to make changes later because it allows your business to stay solvent, then the immediate solution sounds a lot better.
This exact situation is not one that most people will find themselves in but it illustrates the point.
We’re going to switch gears from strategy to implementation next week. It should be very 1337.
Abstractly yours,
Ben
Learn from more articles like this how to make the most out of your existing Django site.