Overview:
This article is a humorous look at the evolution of software architecture over the past few decades, from giant monoliths to sprawling microservices and AI-generated code.
keywords: AI assistants, large language models, LLMs, software engineering, monoliths, microservices, The Book of Microservices
1. The Monolith
In the beginning, there was a monolith.
And the monolith was large.
Very large.
It had been carefully curated over many years by shaggy, neckbearded nerds rooted firmly in the bland technoculture of the 20th century. They wrote code in languages that required semicolons, deployed software on actual servers, and believed that documentation was something you produced after the system was finished.
The monolith contained everything.
Authentication was there.
Billing was there.
Reporting was there.
There was a module called CustomerManager, which appeared to manage customers, except nobody knew exactly which customers or why. There was also CustomerManager2, which had been created during a particularly difficult quarter and was never spoken of again.
There were stored procedures.
There were batch jobs.
There were cron entries nobody remembered creating.
There was one function called processOrder() that was 4,873 lines long.
And somehow, against all known laws of software engineering, it worked.
The neckbearded-ones understood the monolith.
Not completely, perhaps. No one completely understood the monolith. But they understood enough.
They knew that if the billing system suddenly started charging customers twice, you restarted the server named BUBBA03.
They knew that if you changed the customer address, you waited eleven minutes before checking whether the change had propagated.
They knew never to delete the table called TEMP_CUSTOMER_BACKUP_FINAL_FINAL.
Most importantly, they knew why.
Or at least, some of them did.
2. The Microservices
Then came the newcomers with their neatly-trimmed chinbeards.
They had no nostalgia for physical servers like BUBBA03.
They had never heard the phrase "we'll just FTP it over from the mainframe."
They spoke fluently about containers, event-driven architectures, vector databases, observability, and whatever new thing had appeared on Hacker News that morning.
"We need to decompose."
The neckbeards were confused.
"Into what?" they asked.
"Microservices."
The word was spoken in conference rooms with great confidence.
PowerPoint slides appeared.
Boxes were drawn.
Arrows connected the boxes.
Someone put the word SCALABILITY in enormous letters across a slide.
And so they decomposed.
And decompose they did.
The monolith was broken into numerous microservices, scattered to the winds of Google, AWS, and Azure.
There was a Customer Service.
There was an Order Service.
There was an Order Customer Service.
There was a Customer Order Service.
There was a Customer Order Notification Service.
There was a Customer Order Notification Service Adapter.
Nobody was entirely sure what the adapter adapted, but it had its own Kubernetes deployment, so everyone agreed it was important.
The architecture diagrams became magnificent.
The diagrams were so magnificent that people stopped asking whether the system was actually simpler.
The old monolith had one application.
Now there were 147 repositories.
The old system had one deployment.
Now there were 38 pipelines, 19 Helm charts, 11 Terraform modules, and a Slack channel called #platform-escalations.
The old system had one log file.
Now the logs were distributed.
Very distributed.
So distributed, in fact, that nobody could find them.
But this was progress.
Everyone agreed that this was progress.
And for a while, it was.
3. Artificial Intelligence
Then came the clean-faced ones.
They had no neckbeards.
In fact, they had no beards at all.
This was more progress.
The clean-faced newcomers optimized the microservice code with AI.
The AI explained the code.
The AI refactored the code.
The AI generated tests for the code.
The AI generated documentation explaining the tests.
Someone asked whether the AI-generated documentation was accurate.
The AI confidently replied that it was.
And so everyone believed it was.
Then, as had become customary in modern technology companies, the first wave of clean-faced newcomers promptly sought employment elsewhere.
They went to startups.
They went to FAANG companies.
They became "founding engineers."
They became "AI transformation architects."
They updated their LinkedIn profiles.
And they left.
Behind them remained the code.
And the code was good.
Probably.
No one really knew.
New baby-faces were hired to comprehend the legacy of the earlier ones.
They arrived with fresh laptops, fresh credentials, and absolutely no idea what the system did.
Their first ticket was simple:
"Make a small change to the customer notification flow."
They opened the repository.
The repository then opened 17 linked repositories.
They followed a dependency.
The dependency led to yet another repository.
That repository depended on a service owned by a team that had been dissolved two years earlier.
The service depended on an API.
The API depended on an event.
The event depended on a Kafka topic.
The Kafka topic had no producer; or rather, it had a producer (but nobody knew where).
The baby-face opened the AI assistant.
"Can you explain what this service does?"
The machine considered the question.
It returned 3,000 words.
The baby-face read them carefully.
"So... does it send emails?"
"Yes," said the machine.
"Only emails?"
"Primarily."
"What does 'primarily' mean?"
The machine generated another 3,000 words.
The baby-face closed the window.
And so they asked the machines what all of those little piles of code did.
The machines answered.
Sometimes correctly.
Sometimes incorrectly.
Sometimes with such confidence that the difference was impossible to detect.
4. The Archaeologists
Eventually someone found an old architecture document.
It was dated 2018.
It contained a diagram of the original monolith.
Someone printed it.
They gathered around it like archaeologists discovering a map of a lost civilization.
"This is the billing system?"
"Yes."
"And this is the customer database?"
"Yes."
"And this service replaced that module?"
"I think so."
"Why?"
Silence.
Someone checked Git history.
The commit message read: refactor stuff
Another read: final changes
Another: final changes 2
Another: temporary fix
It had been modified seven years ago.
It had never been made temporary.
5. The Organization Understands
At last, the organization understood what it had done.
It had not destroyed the monolith.
It had merely distributed it.
The complexity had survived.
In fact, it had multiplied.
It had acquired YAML.
But it was too late.
The monolith was gone, but its spirit lived on in hundreds of repositories, thousands of configuration files, forgotten cloud resources, undocumented APIs, and dashboards nobody opened unless there was an incident.
And there were no longer any bearded elders who understood the system.
There were only teams.
And tickets.
And on-call rotations.
And AI assistants patiently explaining code that nobody remembered writing.
6. The Incident
One Friday afternoon, a junior engineer opened a pull request.
The change was tiny.
The tests passed.
The deployment succeeded.
Everything looked fine.
Then, somewhere in a cloud region no one could remember choosing, a customer received two invoices.
The engineer stared at the monitoring dashboard.
The dashboard turned red.
Slack exploded.
Someone typed: "Who owns this?"
Someone else replied: "I think Payments."
Payments replied: "Not us. Customer Platform."
Customer Platform replied: "We only own the API."
Someone asked the AI.
The AI suggested restarting a pod.
Someone restarted a pod.
Three more pods died.
And thus, as it had been in the beginning, the organization once again gathered around the system.
Except now there was no monolith.
There were only microservices.
Many, many microservices.
And nobody knew why.
7. The Great Achievement
The organization had achieved something remarkable.
It had successfully transformed one giant pile of code that nobody fully understood into several hundred smaller piles of code that nobody fully understood.
And somewhere, in an old repository scheduled for archival, a comment remained:
// TODO: clean this up when we understand how it works.
It had been written twelve years ago.
It was still there.
And it was still waiting.
Top comments (0)