I don't get it: why does moving to microservices mean ditching Django? Couldn't you take your Django monolith and break it into separate (still-Django) microservices? I get that Django is seen as "too heavyweight" to do such a thing, though there are literally books (http://shop.oreilly.com/product/0636920032502.do) written about how to slim down Django.
I get that monolith to microservice is all the rage these days, I just don't understand (and the article doesn't really say) why you have to "ditch Django" to do that.
I thought Django and "microservices" are orthogonal. Can't Django be used to create any service, even a micro service? I certainly used Django in the past just as a REST server, without any "web site" to speak of. It just reduces some boiler plate.
Using Django Rest Framework is practically the EASIEST tool for building microservices I've ever used. It's incredible how awesome it is for building APIs. We were recently looking at building out some new services in Flask or Express. We compared the advantages of each to DRF and quickly concluded that it wasn't worth it. DRF has so much commonly used stuff done for you and it sets up one of the best standards for REST API's I've ever seen.
Flask is too minimal. Using DRF is like having code written for you. Because, you know, the code was written (and battle-tested) for you. Why start from a log every time when you can get a wheel for free?
DRF includes all the serialization and loose object structure for you to build off of.
We've been using DRF pretty seriously for over a year and have yet to find a feature that we want that isn't already implemented or easy to implement on top of it.
Not sure what you're trying to do. But we've found the best part of DRF is that it creates a great structure to build off of and gets everyone writing APIs the same way.
We haven't separated many of our services out but we actually have extended a lot on top of DRF. We created a way to do internal requests, so now instead of passing querysets to HTML views we actually do an internal API call. In the future, that code can be moved into it's own service.
Abstracting things out like this allow us to plan for microservices in the future while not having to deal with tons of different codebases and deploy strategies right now.
In the past year as we've scaled from 3 to 20 developers, I would say that DRF is the single-most crucial element that helped us scale the team without any massive issues.
Perhaps the title was a tad flippant. You can use Django in a microservice architecture although if your services are small enough I would hazard to say that Django would be overkill for most implementations as it is not what it is designed for.
Saying that if it increases development speed and makes sense in the scenario then I wouldn't shy away from it.
I find the claim "if your services are small enough ... Django is an overkill" baffling. When you're writing a simple program / command-line tool, do you use a minimalistic programming language or do you just stick to your Python / C++ / whatever? If you have Django expertise, how does it make sense not to just use it, and worry about "an overkill" instead? Overkill in what sense? In the extra 500KB of memory Django uses? In the extra few MBs of disk space? I just don't get it.
My own reasons: because Django is awesome as long as you want to do everything the Django way. For example, as soon as you want to upgrade to SQLAlchemy because every other business unit is already using it, you're in for pain. You can unwire some of those low-level decisions and plug your own code it, but with all the difficulty that usually brings, what's the point of using Django in the first place?
Django was born as a CMS and it really excels there, but it's modeled as a complete end-to-end stack. That's great if you love every single component of that stack, but not so great if you'd prefer alternatives.
Sure, but the title says "ditching Django" ... presumably if they have a Django monolith, at least some of the devs might choose Django for some of the microservices?
Maybe they are still using Django in some capacity and the title is just slightly overstated ... not sure, but would appreciate an author comment in this regard.
Sure -- not looking to nitpick. I just wanted to understand if there was something about Django that you found incompatible w/ microservices, and it sounds like there isn't.
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).
I get that monolith to microservice is all the rage these days, I just don't understand (and the article doesn't really say) why you have to "ditch Django" to do that.