Today I want to take you on a brief diversion from our series on logging to talk about something relevant to everyone running a production application, especially if you ever want to make changes to your application: the point of no return.
The point of no return is the point after which you cannot reasonably reverse a change made to your application.
Obvious examples include picking a language or framework. But it can also mean architectural choices within a language and framework, too. These are decisions that can be reversed, but the cost of reversal is non-trivial.
Yes, it’s a form of lock-in as discussed before, but that’s not where we’re going with this. Because as costly as lock-in decisions can be, most of them are still on the near side of the point of no return.
We use the term “web site” and “web application” so interchangeably that we presume the simplicity of that 1990’s “web site” for the 2010’s application. Let’s face it, the average web application today is more sophisticated than the average desktop business application of the 1990’s (I know, I was there).
So let’s be clear, we’re talking about web applications as significant programs. And for many if not most of us, the most sophisticated applications we work with are either web based or mobile based.
The other week I updated the Dropbox app on my phone, and after reloading I was presented with a status screen and instructed to wait because Dropbox was, “Performing some housekeeping”. Presumably, as with other apps, they made some changes to the internal data structure that need to be accounted for.
Now think of the gnarliest database change you ever had to make for your app. You only had to make that change once on a system you controlled and it was immediately available to everyone… no pending screens required.
The N-1 ratio of users to deployment works in the extreme favor here of the web application purveyor.
That ratio works because you control the app, how its deployed, etc. The _ edge of the distribution layer _ is your host name. Whatever happens between that edge and you, as long as your users see what they expect to see and it works how they expect it to work, it doesn’t matter. You control that. And for reaching an audience or customer base that’s kind of amazing. It’s not like shipping software on CD’s, where once it’s stamped it’s done. You want to make a bug fix? It’s on every customers’ computer.
Now the flip side to illustrate the point.
We’ve consulted for an NGO client that works in global health. A big part of how their [Djagno] app works is by providing health information, tactical advice that frontline health workers can use to implement and save lives.
While it’s mainly of use to other NGO staff for providing education materials, ultimately the end users are in target countries like Pakistan, Nigeria, and Brazil. In some cases, partner countries would strongly prefer to control their own instance of the data, rather than rely on a third-party resource.
The upshot is that the application will be made available - as an application - for each Ministry of Health which desires to run its own copy of the site. And since not every ministry has a stable of Django developers, it must be provided in a ready made format which they can easily set up and run themselves.
So far, so good, right?
Great, except that the application will still need to be supported, and both fix and feature updates in the main application will need to be moved to the downstream copies. And the application will probably be distributed using a virtualization system to minimize the setup needs downstream.
Now the upshot is that any significant change made to the application has to be made successfully by one or more secondary applications.
I don’t want to suggest that changing backing services is simple, but if you want to upgrade the version Solr that your site uses for search, you can test it out in dev, run some practice scenarios to ensure the index is updated properly, execute, and be done with it.
Even if this is scripted in a situation with discrete deployments under someone else’s ownership, this becomes _just slightly _out of your hands.
So why are we talking about how a Ministry of Health in western Africa is going to upgrade Solr? To illustrate the edge of distribution.
Once the aforementioned Django application moves beyond the original instance and into other owners’ hands, the edge of distribution moves with it. Changes made to the application upstream have to account for the deployments downstream.
Even if the changes you face in your own application look significant, you probably own the edge of distribution.
And what this _means is that the point of no return for many of the choices you have to make is not as near as you may think it is. Because as long as you control that distribution layer edge, you have _considerable control over how to make changes to your app. They may not be easy! But they are feasible.
No matter what kind of changes you think you need to make to your app, chances are pretty good you have not reached the point of no return. If you still think you have, reply back about your situation and I’d be happy to help.
Cheers,
Ben
P.s. the release of Django 2.0 feels just around the corner… which means what little life Python 2 has left is being quickly depleted. It’s EOL in 2020, although I wouldn’t be surprised to see production apps running Python 2.7 for a long time after that.
Learn from more articles like this how to make the most out of your existing Django site.