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

21–30 of 85 posts

Re: Why we ditched Django for Microservices

#21

Post by jexus2 »

tmwatson100 wrote: post #17
jexus2 wrote: post #8

> We don't worry too much about code quality as I believe that that is fixed at the recruitment level. Good people write good code and, more importantly, ship good products. Good people make mistakes too. Having good tools to ensure code quality doesn't make it impossible to ship bad products, but it's definitely important.

Not worrying too much doesn't mean not worrying at all! We still have tools in place to ensure silly mistakes aren't made or are at least rectified quickly. Just we don't expect 100% test coverage on every single feature or fix we ship. This approach will probably change as we get larger but being a small development team means that it is fine for now.

Thanks for the clarification! This sounds quite a bit more reasonable. :)

Re: Why we ditched Django for Microservices

#22

Post by lmm »

iends wrote: post #15
_pmf_ wrote: post #13

> Having been a dev team of 1 for a long time I'd never experienced the headache of installing all the dependencies required by our Django system. It never really occurred to me that as I installed more packages, it was becoming incrementally larger and more complicated for new team members. Because of this, the monolithic Django system was already proving a headache to get quickly set up, running and understood by o…

I don't believe he's talking about code dependencies but rather things like LDAP, mySQL, MongoDB, etc which Java dependency management tools don't solve either. Managing code dependencies is solved in Python (as it is in most dynamic languages) using pip and virtual environments.

IME, encouraging people to only run part of the system results in a more fragile environment, and devs who can't fix problems in the wrong part of the system or change boundaries that were put in the wrong place. Everyone should be encouraged to be full-stack; specializing on one part or the other is ok, but you should be able to chase things into other components where necessary.

From the talk of "packages" I think the original was talking about code dependencies. But it's worth saying that you can manage external dependencies the same way, with something like puppet.

Re: Why we ditched Django for Microservices

#23

Post by drbryanadams »

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.

Re: Why we ditched Django for Microservices

#24

Post by falcolas »

> it was becoming incrementally larger and more complicated for new team members. Because of this, the monolithic Django system was already proving a headache to get quickly set up, running and understood by our new hires.

So, now you have thirty smaller services for each new hire to install and link together? I can all but guarantee that this particular problem is better solved with Vagrant and some orchestration scripts. Takes your install from a list of packages to a single "vagrant up" command.

Re: Why we ditched Django for Microservices

#25

Post by kyllo »

collyw wrote: post #12
speg wrote: post #11

Doesn't Django already encourage this type of design? Each Django project is composed of several installed 'apps'. Each app should be portable enough that it could be the only app in any project.

I have a large app in Django at my work. The thing is it doesn't make sense to split this into smaller apps (except for the shopping cart equivalent). It tracks the workflow of our organization, so all queries need to be related from the very start to the very end of the process. (Ok, not all queries, but a lot of them).

Yeah, you wouldn't really want to split a Django app across foreign key relationships unless you want to be doing your joins on the client side with REST API calls, which is more work than letting the ORM do it.

Re: Why we ditched Django for Microservices

#26

Post by artursapek »

drbryanadams wrote: post #23

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.

Re: Why we ditched Django for Microservices

#27

Post by endemic »

davidw wrote: post #2

> A microservices architecture is (fairly) new and it doesn't tie you to a particular language. If you want to build a service in Lisp, Go, Elixir, etc then you can (assuming it makes sense). Good devs love to learn, experiment and hate being bored. A microservices approach encourages all of that The developer in me kind of likes that - fun new toys! But from a business point of view, I'm not sure it sounds like such…

Yeah, from my experiences with my current company, standard language/framework == good, one-off apps that now need to be maintained in production == bad.

Re: Why we ditched Django for Microservices

#28

Post by eliben »

drbryanadams wrote: post #23

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.

Re: Why we ditched Django for Microservices

#29

Post by drbryanadams »

artursapek wrote: post #26
drbryanadams wrote: post #23

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.

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.

Re: Why we ditched Django for Microservices

#30

Post by programminggeek »

I think the biggest reason people are switching to microservices is that it enforces protocols and documentation between components that would otherwise never be created.

Microservices create a boundary and that forces you to create a request/response protocol to enforce that boundary. You also have to create documentation for it to be useful.

There is nothing stopping you from creating your app as a bunch of small services without the added complexity of microservices/SOA. Each slice of your system could be an isolated library with a stronger enforced protocol and documentation and you'd get largely the same benefits without having to deal with the deployment headache.

The reason people don't do that is if they build isolated components in the same monolitic system, nobody takes the time to create a proper protocol and documentation.

The only way people seem to be willing to give separate services the appropriate design respect is to physically separate them and solve them as an isolated problem. The physical separation forces better behavior for microservices to even be useful.

It doesn't help that most languages have really weak capabilities to enforce strong protocols/boundaries beyond a simple type checker via complier. A language like JS, Python, PHP, Ruby, etc. don't even have a compiler so the ability/desire to create strong protocols in most code is almost nonexistent to most developers.

Post reply on HN