This is Part 3 of the humor-inspired saga on the journey from monoliths to microservices, to serverless, and now incorporating AI agents. If you haven’t read Part 1: Mono’s Journey from Monolith to Microservices and Part 2: Mikro’s Serverless Saga, please do so first.
Remember when we used to think of security like a medieval castle? High walls, a moat, and guards at the gate. Once you were inside, you were trusted. In the Tech world, that model worked great when our entire tech stack lived in a data center down the hall. Unfortunately, that castle doesn’t exist anymore.
According to IBM, the average cost of a data breach reached $4.9 million, with compromised credentials being the most common initial attack vector. Organizations that still trust their internal networks face a harsh reality: once an attacker gains authenticated access, they often have free rein to move laterally through systems. The philosophical shift from perimeter-based to Zero Trust security isn’t just about technology; it’s about survival in the modern threat landscape.
The question arises frequently in engineering discussions: “Should we break up our monolith into microservices?” The answer is often surprising: “Probably not” or “It depends”. This isn’t because microservices are bad—they’re not. It’s because the industry has finally moved past the religious wars where you were either team microservices or team monolith, with no middle ground. The reality in 2025 is far more nuanced.
This is part 2 of a humor-inspired take on Monoliths to microservices that I wrote a few years back: https://blogs.justenougharchitecture.com/monos-journey-from-monolith-to-microservices/. If you did not read that, please do so first.
Mikro was serving his consumers as always. He consistently met his promises (SLAs), and his life was good. Suddenly, he felt a stab and excruciating pain. “Damnit, what was that?” he said. To Mikro’s horror, he found himself being sliced and diced into smaller and smaller pieces. “But I thought I was already micro enough!” he wailed as functions were extracted from his very being.
In the age of Serverless & Container architectures, there is once again chatter about Java being too fat (and dying). While I can understand the “too fat” observation, I will not put my money on the “java is dying/dead” chatter. That obituary has been written multiple times and the language lives on. It is true that Java was not born in the Container/Cloud era. Yes, it was born in a different age and time, but the language and framework ecosystem has evolved. In the Microservices cloud-native app world where horizontal scaling and fast startup times are expected, Java may (at times depending on the architecture) not be the fastest horse in town.
Once upon a time there lived a monolith application named Mono (creative ah!).