When the American television sitcom Home Improvement came out it quickly became one of my favorite TV shows (please cut me some slack, I was 9).
If you’re unfamiliar with the show, it centers on a character named Tim Taylor who stars in a home improvement centric TV show - a show within the show - called “Tool Time”. In the show he ends up demonstrating some of the sponsoring company’s power tools, often to comically disastrous results as he screamed “MORE POWER” and used just that, excessive power, to destroy what he was working on, the tool, or both.
Tim had a few things going against him, but mainly Tim didn’t really understand his tools or their purpose. At a base level, of course, he knew his tools enough to know where they should be used and to know that they should have lots and lots of power, but he didn’t understand how to apply the right amount of power with the right tool. And he didn’t understand what his tools could already do before he caused hundreds of dollars in comical destruction.
It’s an imperfect analogy, but it illustrates one of the fallacies I see developers fall for when working through problems with a given tool, whether that’s a new framework or a long time database. Maybe it’s a performance problem (“let’s use a document database instead, it’s a webscale!”) or challenges with code coupling as a project gets bigger (“let’s use microservices instead, there’s a cool post on Medium about them!”). It’s not that these solutions aren’t ever valid, but that they’re often unnecessary and developers reach for them because they don’t know what they can solve right in front of them.
Using a framework is extremely helpful in developing non-trivial application, especially business web applications, freeing you and your team to focus on the business problem rather than all the “other stuff”. The downside is that frameworks make a lot of default decisions for you, default decisions designed to be sane defaults and to work for most cases, but not necessarily the right decisions for you.
Structural framework examples include how database tables and relations are structure, how ORM queries are built, what’s included in the requests, and how templates are rendered. These are all areas where Django gives you excellent defaults so that you don’t have to decide what to do, but they also mean that its easy to assume that’s the only way it’s going to be. A big template is slow to render? Maybe using Jinja would actually speed things up. Inherited model queries are slow? It could be that you let Django let you use multi-table inheritance when a little more thought and proxy models would have been a better idea.
It’s true that microservices can solve coupling by forcing hard delineation between concerns - there’s no harder delineation than using separate application servers. But this comes with a lot of tradeoffs. Aside from asking specific questions about shared services and load types, one of the questions I want to ask people looking this way with Django apps is whether they’ve first made “vendored” stand alone Django apps in their projects. If you can’t adequately separate and maintain functionality into it’s own Django app, it’s not going to be any easier moving it into it’s own project. Not only are Django apps are good - I’d say necessary - step to breaking out functionality for microservices, it’s a step that often obviates the need for separating out services[0].
The problem with picking a new tool to solve a problem you didn’t realize your existing tool could solve is that it means you’re blindly taking on the problems of the new tool and, without understanding the core problem to start with, likely not even solving it at all.
Empoweredly yours,
Ben
[0] What are some good reasons for finally breaking something out as a microservice? A very different load profile is one (i.e. it allows you to optimize resources), shared usage across multiple deployed applications, tertiary functionality (e.g. image/file manipulation, messaging), or an obvious cleavage point between support teams.
Learn from more articles like this how to make the most out of your existing Django site.