In Rational Tech Adoption, I discussed how to decide about whether or not to adopt new technologies. But that decision is not context-free. There is always a switching cost. If the switching cost is too high, you might forgo potentially beneficial upgrades whose benefits are less than the switching cost.
In order to benefit from new technologies, you need to build agility right into your stack. Can you easily switch your relational database from MySQL to PostgreSQL? How about from MySQL to MongoDB? Can you move from Python 2 to Python 3? How about from Python to Go? Are you running your servers on AWS? Can you move them to the Google cloud platform? How about switching to a bare metal virtual service provider? Those are not theoretical questions. If you build successful systems that accumulate a lot of users who stay around for many years, those questions will come up.
Traditionally, the answer was always, “Nope. Can’t switch,” and you got stuck with your initial choices or, alternatively, a super complicated project was launched to upgrade some aspect of the system. The good news is that similar to testability, performance and security, if you follow best practices such as modularity, information hiding, interaction via interfaces and build loosely coupled systems, then it will be relatively simple to replace any particular component or technology.
The stumbling block may often be your DevOps infrastructure and not the code itself. The whole notion of DevOps is still new to many organizations and there isn’t much awareness regarding the need to quickly switch fundamental parts of your DevOps infrastructure. If you consider these aspects when you build your system, you’ll have the chance to reap enormous benefits as your system scales and evolves.
