Highlighted by Richard Keele

See more

There are a number of problems with the monolithic architecture. First, as features and services are added to the application, the code base will grow substantially more complex. This can be daunting and intimidating to new developers. Modern IDEs may even have problems loading the entire application code, and compile and build times are long. Because all the application code runs in the same process on the server, it is difficult (if not impossible) to scale individual portions of the application. If one service is memory intensive and another CPU intensive, the server must be provisioned with enough memory and CPU to handle the baseline load for each service. This can get expensive if each server needs high amount of CPU and RAM, and is exacerbated if load balancing is used to scale the application horizontally. Finally, and more subtlety, the engineering team structure will often start to mirror the application architecture over time. UX engineers will be tasked with building the UI components, middle-tier developers will build the service endpoints, and database engineers and DBAs will handle the data access components and database. If a UX engineer wants to add some data to a screen, this will involve coordination with the middle-tier and database engineers. Like water, humans tend to take the path of least resistance, and this means that each engineering group will try to embed as much logic into the portion of the application they control. This is a formula that guarantees unmaintainable code over time.