We’re talking about lock-in again this week. To rehash in case you missed the intro:
Software lock-in is, in simplest terms, what happens when you pick a piece of software and are stuck with that decision, locked-in. What usually comes to mind is proprietary software - vendor lock-in by method of proprietary data formats, that ensure customers use the vendor’s software for eternity. Working with open source software like Django we’re immune to this issue though, right?
For a few weeks over one winter break in college I sold Cutco knives[0]. I think I can recite much of the sales demo to this day. One of the selling points is that those knives are supposed to stay sharper much longer than regular knives (“because of the Double-D edge, which isn’t actually serrated, as you can see… do you have a tomato I can cut?”)[1].
However like any sharp edge, those Cutco knives are still prone to dulling. And when they _do _dull, you can’t sharpen them yourself because of that unique blade style. You need to send them back with a shipping and handling fee and wait a few weeks _or _have a sales rep come with a special sharpener and then try to sell you more.
Hopefully you see the tradeoff, and that when you buy the product you’re also buying a whole bunch of future decisions.
If software is eating the world then APIs are the feed bag that make it possible to gobble hands-free. So many services expose an API that makes it easy to do things that were hard and easier to do things that required schlep work. They make it possible to access an entire world of information in you application that wouldn’t otherwise be possible, and to perform minor miracles without more than a few lines of code.
Miracles might be a stretch, but when you think of how much faster they let you deliver, it can seem that way.
The flip side of these wonderful APIs is that they create a dependent relationship over which you have little control, and a potential liability when the tail starts to wag the dog.
For the purpose of our discussion today, let’s group third party APIs into two categories:
The thing these services all have in common is that they have an analog that you can run locally, competitive third-party alternatives, or both. You can run your own ElasticSearch cluster and you can find another payment processor (although it might suck).
The second category is a bit different, and smaller. The typical dependence here is on a specific site for your users to interact with, Facebook being the most obvious. You can turn a service from the first category into a second category service too if you start depending on truly unique features offered.
Here there is no analog you can run locally or competitive analog. You can’t just switch to Myspace if you’ve depended on Facebook and decide that was a bad idea (sorry, Tom).
Being locked in to a third party service is fine as long as everything is going well and they don’t make breaking changes.
Oh boy.
Hedging against the liabilities of third party APIs isn’t easy but it is fairly simple: wherever you can ensure that your Django application code doesn’t touch anything specifically related to the third party service. Like I said, simple but not easy.
The quickest example is email. It’s common practice to use a transactional email service, whether that’s because your host won’t send email, you don’t want to deal with the hassle, to improve deliverability, or some combination thereof. Many of these services provide both SMTP and HTTP API interfaces for sending email. This step is easy if you choose SMTP, but if you choose to use the HTTP API, ensure that you’re using an email backend that encapsulates this rather than interacting directly with the API in application code.
Your code that sends email shouldn’t need to know who is handling it or about any special features (and if so, these should be handled in a way that degrades gracefully). Now if you want to test locally or find you need to switch providers, you can swap backends rather than fix code embedded everywhere in your project.
Extrapolating this to other types of services follows this pattern, and is left as an exercise for the reader. (If you have specific questions about this hit Reply and fire away.)
Here’s the deal: if you’re going to rely on a unique service like Facebook, your lock-in costs are locked in. To avoid the liabilities associated with a hard change in service, there are two things you need to do: (1) careful service selection and (2) keep your application continually up to date.
If you’re assessing a new or current third-party service provider, two dimensions of analysis stand out:
Next week we’re going to address Django library lock-in - it should be exciting!
HTTP 418,
Ben
[0] For those unfamiliar, Cutco is a brand of knife sold by direct marketing methods, using mostly college students to call up friends and family (initially) and then go their home and perform a demo of the knives in an attempt to sell an $800 set, or at least a knife or two.
[1] If you look closely you can see that the edge is made up of geometrically aligned straight edges
Learn from more articles like this how to make the most out of your existing Django site.
