Today we’re going to learn how to deploy your Django site using a swarm of AWS Lambda functions so that you can maintain your GraphQL microservice separate from your other 23 microservices. It’s going to help your 4 person development team a lot.
Yeah, with their resume buzzwords.
Today I want to talk about own-goal, shoot-yourself-in-the-foot complexity and how it’s a silent killer of productive apps and productive teams. And maybe how you can stave this off.
First, let’s get something out of the way. The technology we have available today, on the web or otherwise, is great. Some of it is even AMAZING and its fun to play with. The way web technologies or supporting tech has advanced in the last 10 years makes all kinds of problems go away. It also brings new problems, you know, tradeoffs. And the crux of the issue is that often these tradeoffs don’t play into your hands the way they do for the parties gabbing out their new tools.
I’m hardly the first person to point this out, but I’d like to address it concretely with regard to production Django apps used for real, actual business.
I read this the other day is a newsletter unrelated to software development:
…there’s that line from A. N. Whitehead. “civilization advances by extending the number of important operations which we can perform without thinking of them.” Making things boring is about locking in progress.
Emphasis added. The author also claims that making marketing interesting requires making the engineering boring, and vice versa. For developers marketing can be a dirty word, so let’s substitute “the way you actually grow a business and keep it alive” for “marketing”. It’s easy to think that’s the part we do, but even in a software driven business it’s only part of it.
What is looks like for marketing, er, the-way-you-actually-grow-a-business to be interesting is beyond the scope of this missive, but what it means is that an operation is giving a lot of attention and energy to it, and taking risks. Interesting entails exploration and it also entails [anticipated] failures. So the other parts of the operation should be dependable to allow for this. That’s difficult if each and every part of the operation is chasing what’s interesting.
Now what interesting looks like in a Django app is another story. It can mean new deployment strategies like taking advantage of “serverless”, building full SPAs (single page application) using RESTful backends, maybe using GraphQL, etc. There’s nothing wrong with any of these things! Okay, the full SPA is probably not a good idea, really. But even when they work well, by themselves they’re unlikely to advance the organization goals that are the raison d’être of your software.
The obvious example is microservices. Using microservices the “proper” way means using discrete, isolated deployments, database included. What problems does this resolve? It makes it easier to separate out developer responsibility for one, it decouples performance and resource needs of the various services, and it makes them “use case” agnostic, not to mention platform agnostic. If you write an HTTP accessible microservice in Python it’s available to client apps in Python, Ruby, Go, Java, PHP, etc.
But like the old saying with regular expressions, “now you have two problems”. Your deployment is now more complicated. If it’s a non-trivial service you need to ensure it’s available for development too - as opposed to being something that can be mocked out. You need to orchestrate all of the pieces. When it’s necessary, this will solve problems, but quite often this looks like an exercise is technical “me-too-ism” replicating an interesting looking architecture and expending organizational energy on this rather than actual problems.
The answer is to find and try every “old and dumb” solution first. Stuff like caching, async workers, performance profiling.
 The first volume of Venkatesh Rao’s newlsetter is here https://breakingsmart.com/en/season-1/
Learn from more articles like this how to make the most out of your existing Django site.