/Monolith

Should We Decompose Our Monolith?

- Will Larson tl;dr: “Even as popular sentiment has generally turned away from microservices, many engineering organizations have a bit of both, often the reminents of one or more earlier but incomplete migration efforts. This strategy looks at a theoretical organization stuck with a bit of both approaches, let’s call it Theoretical Compliance Company, which is looking to determine its path forward.”

featured in #550


How We Organise Our Very Large Python Monolith

tl;dr: "I work on Kraken: a Python application which has, at last count, 27,637 modules. Yes, you read that right: nearly 28k separate Python files - not including tests. I do this along with 400 other developers worldwide, constantly merging in code. And all anyone needs to make a change - and kick start a deployment of the software that runs 17 different energy and utility companies, with many millions of customers - is one single approval from a colleague on Github." The author shares how this is an effective way of working and the monolith’s structure. 

featured in #466


Monoliths Are Not Dinosaurs

- Werner Vogels tl;dr: "I always urge builders to consider the evolution of their systems over time and make sure the foundation is such that you can change and expand them with the minimum number of dependencies." Werner discusses being less dogmatic about architecture allowing it to evolve with its needs. 

featured in #413


Real-world Engineering Challenges #8: Breaking Up A Monolith

- Gergely Orosz tl;dr: "We’re diving into a massive migration project by Khan Academy, involving moving one million lines of Python code and splitting them across more than 40 services, mostly in Go, as part of a migration that took 3.5 years and involved around 100 software engineers."

featured in #388


Give Me Back My Monolith

- Craig Kerstiens tl;dr: Much has been made about micro-services, but downsides include more time onboarding new devs & increased complexity debugging.

featured in #133