In the earlier days, we used to create software that was single-tiered. The frontend and backend code was combined, and often the database was also running on the same machine. At the time, this was the best method for delivering new services to users. When user demand was high, it was necessary to scale the entire application and not just the parts that were being used the most. If this is sounding similar to the evolution of compute, you're right on the mark. The ability to distribute and independently scale our compute providers has directly influenced how software is architected, developed, and tested.

Let's dig into some of the challenges with building a solely-monolithic application:

• Picture a team of 100 developers who all have the code checked out to their local dev environments. The team has multiple managers, ranging from change and release managers to human wellness and business owners. 
• There may also be another team responsible for testing the application once a major release becomes ready.
• There's another team for operating the application once the features go live in production. All of these groups of people must coordinate and agree, often through a ticket management system, on a whole host of issues and decisions.
• The time that's spent by developers organizing environments, lining up testers, and dealing with management noise greatly encroaches on the time that's available for writing actual business logic in code.
• Adding to that, once the code is in production, it's very hard to make changes or add features.
• The application has to be fully built again by passing multiple testing environment stages that may or may not be fully integrated. Then, they need to be scheduled for release during the next version.

If a monolith is kept relatively small, there is no issue with scaling that. However, if you increase the complexity, you're in for a whole set of challenges. This usually leads to an n-tier model, where we can scale individual components of the application.