How one engineering team is modularising a massive 10-year-old Go monolith

A principal software engineer who set out to modularise a 500,000-line code base has learned some valuable lessons: That modularisation chiefly benefits the developers, not just the servers it runs upon. But it only works if there is buy-in across the team. 

“Modularization isn't really about modules, it's about respecting the limits of human attention,” said Victor Lyuboslavsky, a principal software engineer at Fleet Device Management, during a presentation at FOSDEM. 

Modular architecture defines for the dev what they need to understand, what they can safely ignore, and what they can change. 

“When that interface is unclear, every change feels risky,” he told audiences gathered at the conference. 

Cracks in the monolith

Lyuboslavsky set out to solve a minor issue of the build process for his company’s core service code. Every change would take 30 seconds or longer for the service to recompile. 

The program, a monolith written in Go over a decade ago, was a blob of interdependent packages. If one package was changed, the whole mess needed to be recompiled. 

Long code compile times were a minor issue. The main problem is that monoliths are often too large to be managed effectively. 

In a Fleet engineering meeting, Lyuboslavsky proposed breaking the service code into more manageable portions. Modularization would allow the dev teams to work independently, and more quickly.