Interlocking technology stacks by using proprietary features
Using these features could become a problem though..
For each of the examples above and for all that I didn’t even mention you can find individual features that the alternatives don’t offer.
Each SQL database comes with their own brand of SQL for example. Surely you can replace a MySQL with a PostgreSQL easily if you use a database access layer like doctrine in PHP that provides an abstract interface to your application. But what if you started using triggers and procedures? Those special features that can prove really useful sometimes and could have been the reason you chose X over Y for?
Using these would interlock some layers of your stack. Replacing the database system would result in code changes to your application and probably sometimes in replacing specific PHP modules and extensions with others.
You see my point. Interlocking makes changes costly.
Now you can easily rely on those special features throughout your whole stack. By using libraries, special commands, relying on caching within your application.. you can easily interlock layers from bottom to top and the other way around and your carefully balanced stack will become inflexible and probably incredibly hard to chance.
And it can get worse.
You can interlock your stack with the projects you work on. Yes that’s a layer of your stack too mostly represented by the application.
The more of your projects use your stack the more will be potentially affected by changes to it, making it even more costly to change anything.
Now if you agree hat change is something that needs to be possible at all times you will also agree that interlocking stack layers as described above is pretty damn risky and not a good idea at all.
But when you work on a certain requirement and focus on the task at hand it can be so easy to accept a proprietary feature in a neighboring layer as a solution
That’s why you should always be aware of the whole picture.