Introduction

Let me know if this sounds familiar. You work at a software company that uses a 3/3.5 tier architecture. There are frontend servers, backend servers, some batch work servers, and a database or two. Even with all the microservice/devops/container/serverless hype no one has managed to change that 3/3.5 tier architecture. There is always a frontend, there is always a backend, there is always a database if you look closely enough. The differences are in the domain logic and implementation details like which language is used for the backend components and which database is used to hold the data.

Let’s now get into slightly more concrete details because I promise there is point at the end of this.

Burning Cash

Let’s say you have 10 frontend servers and 10 backend servers (we’ll ignore the database and any other details for the time being). Let’s also suppose the traffic/workload patterns are periodic so those 20 servers are really for handling peak load instead of average load and the average load across those servers is 50%. This means every other server is essentially idling so the average number of servers is actually 5 for the frontend and 5 for the backend. In this imaginary but really non-imaginary configuration we are paying for 10 extra servers 24 hours a day 7 days a week. That’s a concrete number that any CTO and engineer should be able to understand. That’s literally real money being wasted every day because for whatever reason the architecture precludes automatically scaling things up and down.

Not Burning Cash

The sensible engineering solution in the above scenario is to figure out the blockers for reducing the server count and work on removing those obstructions but the reality is that most engineering organizations will not bother with changing the status quo. They won’t bother with removing those obstructions because changing the status quo is painful. It isn’t painful in terms of engineering hours. It is painful in terms of retooling and rethinking required to re-imagine the architecture so most engineering organizations will just continuously eat the cost of those 10 extra servers.

My perspective is not unique but there doesn’t seem to be much critical analysis on this issue. The only thing I could find was “Why bad software architecture is easy to monetize” that uses housing as an analogy and outlines why there is inherent interest from one side of the market to make bad software and why the other side keeps falling for it. If you know of more such articles then let me know.

$ ./keygen.sh 6428f5771007cf005037d47c9aeac9bfcc8925f9  -