LFS158 Knowledge Check 2.1

mgrd

The monolith vs. microservices presentation feels quite misleading because it conflates monolithic architecture with legacy/poorly designed applications. A monolith can be modern, modular, containerized, horizontally scalable, and deployed with rolling/blue-green deployments with little or no downtime. It also does not necessarily require a single expensive server: multiple instances can run behind a load balancer or Kubernetes Service.

Conversely, microservices are not inherently cheaper, easier to operate, or faster to develop. They introduce distributed-systems complexity: network calls instead of function calls, timeouts, retries, partial failures, service discovery, API/version coordination, observability, etc. Using smaller machines can sometimes improve resource utilization, but it can also add infrastructure and operational overhead. Likewise, using different “modern” programming languages is not a property or inherent benefit of microservices.

The strongest argument for microservices is independent deployment, scaling, and team ownership when those properties are actually needed. For example, if image processing needs 50 instances while payments only needs 2, independently scaling those services is a real advantage. But this does not mean that a monolith is inherently a 1000-ton boulder, nor that microservices are inherently easier to handle. A well-designed modular monolith can often provide most of the architectural simplicity while remaining a very scalable and modern system.