On the topic of monolithic Django apps it’s hard not to think about monolithic web apps. There are some common architectural challenges, especially with regard to piecing them apart, but they’re not the same thing.
Let’s take a look at each, how they differ, what they have in common, and when it makes sense to break up a monolithic Django project.
A little review here. Monolithic Django apps are individual Django app modules which tend to contain significantly more functionality than is warranted in one Django app module.
This usually looks like lots of models mixed together which serve very different business purposes.
Monolithic Django apps are common because absent hindsight this kind of accretion is natural. They’re also problems for ongoing development, because they make it harder to make changes, to identify and fix bugs, and to just plain think about everything works.
They demand a fix based on some measure of of breaking up into small modules.
Even having broken up a monolithic Django app, chances are you’ll still be left with a monolithic Django project. That is, the monolithic web app.
And for most scenarios, that’s _ not _ a bad thing.
A monolithic application - in the sense of the full application, rather than the limited scope of the Django app module - is one in which a single application has responsibility for all tasks. It works as and is deployed as a single unit. It might include some public facing web pages, a user facing interface, an admin facing interface, user notifications - this probably sounds familiar to you.
Here’s the rub: despite what you might’ve picked up from reading Hacker News, they’re not necessarily bad.
The foil to the monolith, microservices, have been all the rage for several years now as a solution for the problems of application monoliths. More specifically, as a solution for the problems that monolith web apps pose for very large applications[0] with large engineering team headcount and significant scaling needs. Which is to say, not most web apps.
Not most web apps because like all choices in life there are tradeoffs, and like the old saw about regex[1], the management problem simple grows with the number of microservices and deployment environments.
When we looked at monolithic Django app _modules _and how to break them up, we looked at drawing boundaries around model groupings and clear[ish] lines of business organization[2].
The same goes for breaking up monolithic web apps, but at a higher level.
First, you should consider breaking up a web application into at least some component microservices when the pain makes it obvious that its the right thing to do.
The ideal candidate for a first microservice is a utility, ideally that is “easily” replaceable (e.g. in a dev environment), and even better if it would serve multiple platforms.
The strongest and most sufficient reason is that there’s a significant tradeoff for communication and deployment complexity.
Even if you use a monorepo[3] to manage your codebase, you need to manage a fleet of services operating in concert.
Can it be worthwhile? Yes, it certainly can, but for _most _web apps it’s an unnecessary step, and more is lost chasing the mythical web scale chalice[4] than is gained by fanning out application components.
But you know what? If you have strong opinions about this I’d love to hear them (you can reply directly to this email).
In service oriented architecture we trust,
Ben
[0] What’s a very large application? Without saying this is subjective. Smaller web apps with heavy traffic and obvious logical cleavages and also apps large enough for each component to have a developer or team responsible for it.
[1] An old Usenet quote about regex: Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. xkcd version
[2] From the This Old Pony archive, Drawing Boundaries for Django Monoliths
[3] A monorepo is a large repository in which the entire source code of a project or even multiple projects are all maintained. Facebook famously used a single Mercurial repository to manage their entire codebase, web app, mobile apps and all. There are pros and obvious cons to this which have little to do with the crux of the issue around monolithic apps and microservices.
[4] To quote the Grail guardian: “He chose… poorly.”
Learn from more articles like this how to make the most out of your existing Django site.