Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we ditched Django for Microservices

blog.hubblehq.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Why we ditched Django for Microservices

#51

Post by karuth »

bsdpython wrote: post #32

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 can see a case for microservices as a way to break down complexity. But introducing languages willy-nilly could have maintenance nightmares along the road.

Re: Why we ditched Django for Microservices

#52

Post by tmwatson100 »

statictype wrote: post #40

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?

It depends on what you're building. For us, we haven't noticed any issues with latency just yet and there are plenty of steps you can take to optimise this down the line.

As for monitoring there are plenty of tools to do that. You have bigger problems if you expect your services to go down often.

Re: Why we ditched Django for Microservices

#53

Post by karuth »

adambratt wrote: post #37
eliben wrote: 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…

Flask is so minimal. Curious what were the disadvantages that weighed against chosing Flask.

Re: Why we ditched Django for Microservices

#54

Post by adambratt »

tmwatson100 wrote: post #43
adambratt wrote: post #37

Earlier quoted context omitted.

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.

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.

Re: Why we ditched Django for Microservices

#55

Post by bsdpython »

tmwatson100 wrote: post #42
bsdpython wrote: post #32

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

As a business if you want to encourage your developers to improve by exposing them to more different types of languages and technologies then I am all for it. You can fund a weekly Haskell class. You can implement a 20% time initiative and let developers work on prototypes using whatever tech they want. For your production systems, however, you need to have some boundaries to serve the business even if you are a tech company run by engineers.

Re: Why we ditched Django for Microservices

#56

Post by rattray »

karuth wrote: post #53
adambratt wrote: post #37

Earlier quoted context omitted.

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…

Flask is so minimal. Curious what were the disadvantages that weighed against chosing Flask.

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?

Re: Why we ditched Django for Microservices

#57

Post by chhantyal »

crdoconnor wrote: post #33

Can I be the first to say that this is a terrible idea? >We have a multitude of parts that each could easily be self contained as their own service. For example: Messaging, Search, Authentication, etc. These all have different requirements and focuses and therefore lend themselves better to different languages. Yeah, not really. Python is not inherently less suitable for authentication than, say, Java. Both languages…

This is exact my thought as well.

If OP is more worried about maintenance of project, Django gives foundation to build upon with sane conventions.

Anyone who reads few pages of Django Docs should be able to pick up quickly.

PS. I happen to currently maintain project written by other people with no docs.

Re: Why we ditched Django for Microservices

#58

Post by mpdehaan2 »

adambratt wrote: post #37
eliben wrote: 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…

Love DRF. Really easy, super flexible to modify (we did a lot of stuff with RBAC), the API browser is an amazing feature.

Re: Why we ditched Django for Microservices

#59

Post by santacluster »

bsdpython wrote: post #32

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…

That just means you haven't properly aligned your developers' interests with your business interest.

Limiting developers in which languages and technologies they can use is not going to solve that problem, it merely addresses the symptom. Developers make hundreds of little less obvious and visible decisions that have a long term impact on your business. Picking the tools should always remain a developer decision.

If you a) hire the right people and b) make sure your goals are aligned, your developers limit themselves to a few core technologies. If not, you're screwed anyway.

(And yes, that does mean mutually accepting and respecting the fact that your developers' interests in exploring new things and your business interests in may not be aligned indefinitely.)

Post reply on HN