BrainBlog for vFunction by Jason Bloomberg
In March 2023, Amazon.com published an article on how it rearchitected its Prime Video offering from a distributed microservices architecture to a ‘monolithic’ architecture running within a single Amazon Elastic Container Service (ECS) stack.
Despite a reduction in infrastructure cost of over 90%, the seemingly counterintuitive move generated consternation across the cloud architecture community. Monoliths are ‘bad,’ laden with technical debt, while microservices are ‘good,’ free from such debt, they trumpeted. How could Amazon make such a contrarian move?
This controversy centers on what people mean by ‘monolith,’ and why its connotation is so negative. In general parlance, a monolith is a pattern saddled with architectural debt – debt that the organization must pay back sooner or later. Based on this definition, an organization would be crazy to move from an architecture with less debt to one with more.
But as the Amazon story shows, there is more to this story – not only a clearer idea of the true nature of architectural monoliths, but also the fundamental concept of architectural debt.
Architectural Debt: A Particular Kind of Technical Debt
As I explained in an earlier article, technical debt represents some kind of technology mess that someone has to clean up. In many cases, technical debt results from poorly written code, but more often than not, is more a result of evolving requirements that existing technology simply cannot keep up with.
Architectural debt is a special kind of technical debt that indicates expedient, poorly constructed, or obsolete architecture.
Even more so than the more familiar source code-related technical debt, architectural debt is often a necessary and desirable characteristic of the software architecture. The reason: too much software architecture in the early phases of a software project can cause systemic problems for the initiative that lead to increased costs and a greater chance of project failure.
In fact, the problem of architecture that is too much and too early, aka ‘overdesign,’ is one of the primary weaknesses of the waterfall methodology.
Instead, modern software principles call for ‘just enough’ or ‘just in time’ architecture, expecting architects to spend the minimum time on the task necessary to guide the software effort. If a future iteration calls for more or different architecture, then the architect should perform the additional work at that time.
Read the entire BrainBlog here.
