Beware of abstraction layers

You know what some architects like to do? Build abstraction layers. Because it makes for pretty pictures. And it solves business problems where they are thinking about ‘just in case’. Very often, It is better to think about it in terms of ‘just in time’ rather than ‘just in case’.

An example of this is a brain melting conversation I once had, where there was a proposal to build an abstraction layer to abstract away services from OUR CLOUD PROVIDER. ‘What if we decide to move to a different cloud provider? We will be screwed’ was the rationale.

This kind of thinking boggles the mind. As a CTO, you cannot afford to allow this kind of thinking. Abstraction layers are evil. In most cases.

I believe this because

1. You will spend the next X amount of time building an abstraction layer rather than solving a customer problem
2. The concern you have will (likely) never come to pass. Play the percentages
3. You will slow the entire team down
4. The performance of your product will be worse, thanks to another hop that needs to be made
5. You have to resolve problems in yet another layer
6. Worst of all — each time the underlying service changes, you are unable to take advantage of it because your abstraction layer needs to be upgraded ! So now you sit in a meeting with a PMO, a Product Manager, and 3 engineers, trying to plot a timeline rather than delivering value for customers.

Stop it. Just stop this madness. 9 times out of 10, I disagree with the value of abstraction layers. Irrespective of what highly respected architects say. Pay a penalty in the unlikely event of a change, not a cost up front that is perennial.

(An example of an abstraction layer that does make sense: An API Gateway)