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.[0]

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.

• Before moving something to a microservice, make sure it’s adequately represented as a standalone or standalone-ready app. You may find this solves many problems in and of itself.
• Single page applications are almost never the answer. However client side rendering for snippets or even on a page-by-page basis (a subtle but non-trivial difference from SPA) can help with rich UI and even performance issues in Django apps.
• Look at what you can do not only with features of Django you’re not using, but features of your backing services, like your databases, from PostgreSQL to Redis.
• Look at what you can do with the OS! It’s okay to use cron to schedule tasks with management commands. Then when you exhaust these options, take bites of the interesting technology, rather than trying for a wholesale adoption. It’s more productive for a profitable team to scale out an app to satisfy 10x growth than it is for a team of any size  to try to meet the needs of customers with technology designed for imaginary futures.

Monolithically yours,
Ben

[0] The first volume of Venkatesh Rao’s newlsetter is here https://breakingsmart.com/en/season-1/

More like this

• Django Isn't Good Enough (This Old Pony #73)
• A short side journey on Git workflows and Django projects (This Old Pony #71)