One deployable unit that's simple but couples everything, vs many small services that scale teams but cost you a distributed system.
Plain English: a monolith is your whole app in one codebase you deploy as one thing, simple until it's huge. Microservices split it into many small services that deploy independently. That's flexible, but now you own a distributed system with all its pain (network calls, partial failures, hard debugging).
Two ends of an architectural spectrum. A monolith packages all functionality into a single deployable artifact sharing one process and (usually) one database. Microservices decompose the system into independently deployable services, each owning its data and communicating over the network (REST, gRPC, or async messaging).
The real problem isn't technical; it's organizational scaling. A monolith is the right default: one repo, one deploy, in-process calls, easy transactions. It only becomes painful when dozens of engineers contend over the same codebase and deploy pipeline, or when one component needs to scale independently. Microservices let teams own and ship pieces autonomously, at the cost of turning every in-process call into a network call.
Monolith: modules call each other as function calls; one ACID database; one CI/CD pipeline; scale by running more copies of the whole thing behind a load balancer. Microservices: each service has its own datastore and API; calls cross the network; you need service discovery, an API gateway, distributed tracing, and a strategy for cross-service consistency (sagas, eventual consistency). The migration path is usually 'modular monolith → extract the seams that hurt', not a big-bang rewrite.
The canonical microservices shop, with hundreds of services behind Zuul, each owned by a team and independently deployed
Starts as a near-monolith; only the read and write paths get split because they scale so differently
Dispatch, geo-index, trips, and payments are separate services so the matching tier can scale independently of billing