Back in the days, it was not that crazy to pack a whole LAMP stack in a single box. If your website made it big maybe you’d split your database onto a separate rig.

Then scale was all the craze, both technologically and organizationally. It was not good enough to replicate your monolith; the cool kids also split theirs into microservices. We’ve been in this era for more than a decade, but the pendulum is starting to swing back the other way…

In large web companies, a request hitting a front-end can then touch hundreds or more mid-tier, back-end, cache and database servers. This is the epitome of the microservices architecture, but also where the edifice starts crumbling under its own weight. By compartmentalizing, we built a Conway-esque symmetry of the sprawling org chart. Unfortunately, it is impossible to make this many servers work flawlessly, quickly, all the time. Tail latency degrades the more moving parts are involved.

Microservices are becoming bulkier again, because their owners don’t want to pay the latency and reliability costs of RPCs. Services which heavily query databases can be refactored to eagerly cache the entire dataset.

Can a stateful service really be called "micro"? Or is it more of a macroservice? Or perhaps a microlith? Minilith. Multiliths?

It’s a brave new world out there.