Modular Monoliths and Other Facepalms

If trends are to be believed, modular monoliths are the new kid on the architecture block. They're sold as an antidote to the complexity associated with overdosing on microservices.

All good... except for one small thing: modular monoliths aren't a new idea or architectural style, just a new turn of phrase. The current trend is the pendulum swinging back with the benefit of some rebranding. At best it's "Monoliths, but we're going to do them right this time, we promise!" At worst it's "Oh no, here we go again."

Many teams adopted microservices not for their runtime or deployment benefits, but because they sought refuge from the tangled mess of their monolithic codebases. They wanted microservices because they reinforced partitioning. But, as Simon Brown notes, "If you can't build a well-structured monolith, what makes you think microservices are the answer?" In practice, what many teams discovered is that what gets reinforced is poor partitioning.

There's a generation of developers who have only worked with microservices over their careers, for whom modularity in other forms is a new-to-them discovery. In this talk, we will look at the history of modularity in programming languages and software architecture from the 1960s to the present, taking in the sights and sounds of information hiding, data abstraction, component-based development, process-based architectures and more.