Why we ditched Django for Microservices

Being myself - just a few years ago - a long time strong proponent of tightly coupled monoliths, I can't believe how blind and foolish I was in my fundamentalist rejection of loosely coupled architectures.

Monoliths do just fine up to a certain level of structural complexity. Above that, asynchronous service-like architectures are the only viable way to go.

Microservices is an attempt to see if the services patterns work below that waterline, down to the function level. That's why I find microservices at least interesting.

At any rate, it's a cost/benefit balance game, not an ideology.

Edit: clarity.

A benefit of this is that people get a unified view of the system. You can pull parts as needed. You can survive partial outages better than a monolithic app.

Of course you can still call each of the services independently. The ESB is just another tool in your box.

Unix's tools and good microservices have the following things in common:

1. They are small 2. They are loosely coupled 3. Shared-nothing state 4. They enforce standards for consuming and emitting data 5. They enforce a single standard for piping data from one process to another.

That said, I strongly believe that this won't work for every class of problem. And while I may be putting words into Tom Watson's mouth here, I believe he would say the same. But hey, guess what? This WOULD work for quite a few problems!

Some of the sentiment in the comments here feel defensive and knee-jerk. And I don't understand why. Tom Watson isn't telling you that you should use microservices. He's only explaining why he's using it at Hubble. I'm pretty sure how it turns out is going to have no impact on anyone else here, except (obviously) his customers.

But I hope it succeeds. I think there's a lot we can learn by applying the lessons Unix taught us to web-scale utilities.

An overstated headline isn't the worst crime on the planet (though, I would say that Google has already carried the headline far and wide already ... sigh).

Isn't it way more confusing to have a bunch of different code repos that only a single person owns? Sounds to me like you'll be locking up too much code in a single individual's head. Not to mention if they're using different frameworks and libraries you're only going to add to the headache.

For smaller teams, it usually is best to stick with one or two codebases/languages for your backend. Sure there are often "better" tools for specific applications but at the end of the day there's usually a way to handle them with your existing codebase that will let you scale for now.

As an example, we needed a robust messaging framework to support our chatrooms and private messaging features. We originally built it out in Tornado, then switched to NodeJS with a rabbitMQ backend, and finally realized it was easier for us to just use PubNub and fire off the pushes from our main Django app. It'll scale with us for probably 10x our current size and by that time we'd have a team of 4-5 people dedicated just to this feature anyways.