Live data from Hacker News

Why we ditched Django for Microservices

blog.hubblehq.com

41–50 of 85 posts

Re: Why we ditched Django for Microservices

#41

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 day…

He listed one of the benefits of microservices as freedom to use whichever languages/frameworks developers prefer.

I could see that freedom becoming technical debt if the project is big enough and poorly documented.

I keep picturing the legendary missing Novell server that was buried behind drywall at the University of North Carolina:

http://arstechnica.com/civis/viewtopic.php?f=2&t=1824

Re: Why we ditched Django for Microservices

#42

This makes no sense from a business perspective. Letting developers work using any languages and technologies sounds like a good idea to individual developers maybe but how do you intend to maintain it? If you stick to a few core languages and technologies and hire / train for those tech then you reduce your risk if one or more developers leave and reduce the total complexity of your stack. You should have a good rea…

I perhaps should have explained that a bit more. Technology choices have to make sense before implemented but giving developers the flexibility opens a lot of doors for creativity and exploration.

I strongly believe that learning new languages help people become better coders overall as it increases their knowledge of different problems and solutions which can be applied across most stacks.

Also no one developer should ever be solely responsible for a particular service. But that should also be the case for apps within a Django project.

Re: Why we ditched Django for Microservices

#43
post #28

Earlier quoted context omitted.

Seconding this. Could someone clarify? 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 R…

We actually use DRF. Although I actually find it overcomplicated for what it does.

Re: Why we ditched Django for Microservices

#44
post #28

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 day…

Seconding this. Could someone clarify? 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.

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.

Re: Why we ditched Django for Microservices

#45

What about the headache of monitoring 10s of microservices, making sure they stay up and running and healthy? I assume that REST or Thrift (or something similar) is the way most microservices talk to each other. What if the latency isn't acceptable? I've thought about switching our architecture to microservices but these two potential issues are making me hesitate. How important are these issues in practice?

In my experience with microservices, the vast majority of bugs were in services not talking to each other properly, or in some variation of that interface. There are some security complications that means services aren't very free to talk to each other (which introduces complexity), but, overall, I think I prefer the monolithic model. Our Django app isn't too hard to set up, requirements.txt contains everything and the rest is in an Ansible playbook.

Re: Why we ditched Django for Microservices

#46
post #10
post #6

Earlier quoted context omitted.

what happens when those devs who chose some new language leave? Who gets stuck with all that code?

That's a good reason to have shared responsibility of code. There is no one owner of a codebase, an entire team should own the code. An entire team leaving at once seems highly unlikely.

Yeah, but that's harder when everyone knows Erlang, and one guy goes off and writes something with, say, Django for fun.

Re: Why we ditched Django for Microservices

#47
post #28

Earlier quoted context omitted.

Seconding this. Could someone clarify? 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.

Of course Django can be used for microservices I don't recommend it, but you can use it I would prefer to use Django mainly for CMS kind of things

Why?

Re: Why we ditched Django for Microservices

#48

Earlier quoted context omitted.

He listed one of the benefits of microservices as freedom to use whichever languages/frameworks developers prefer.

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.

Yes you're right it is slightly overstated. We still use our Django monolith to compensate for not re-writing every single part of our codebase.

However overtime I would imagine we would move away from Django as with small enough services it would be overkill as a solution.

Saying that, if it makes sense at the time then why not. With this architecture you have the flexibility to do that.

Re: Why we ditched Django for Microservices

#49
post #28

Earlier quoted context omitted.

Seconding this. Could someone clarify? 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.

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.

Re: Why we ditched Django for Microservices

#50
post #28

Earlier quoted context omitted.

Seconding this. Could someone clarify? 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 R…

Gah, it's perfectly possible to use Django without DRF for simple REST services. If you need simple things, it's not a big deal.
Post reply on HN