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

61–70 of 85 posts

Re: Why we ditched Django for Microservices

#61

Post by mike_ivanov »

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…

My gut feeling is that microservices will lead to language unification within a team in the long run. Yes, initially, as you drop artificially imposed language restrictions, you will get a zoo of systems, but after a while (as the team experience grows) it will converge to a few or even a single language with DSL capabilities, it's just natural. In my experience, the driver for language heterogeneity is not languages themselves, it's craving for DSLs.

Re: Why we ditched Django for Microservices

#63

Post by remmelt »

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…

There are two sides to this.

Technically, one way of solving this is to make sure that the acceptance criteria for any single micro service are clear. For example, you have to expose these REST endpoints; given data set A, respond in this way to these requests, etc. To me, a micro services architecture implies that the development team is responsible for the entire life span of the service, from conception to replacement. This includes maintenance. Insert the devops buzz here as well. When the given solution can no longer be maintained because of failing knowledge (or even interest?) by other devs, it should be replaced. This should be no harder than refactoring a large method, except on the scale of an entire service.

Non-technical benefits include expanded responsibility and shiny architecture can possibly attract better developers/engineers. I know this has worked for us.

I think it would be reasonable to somewhat limit the available choices, especially at the start of a project.

Re: Why we ditched Django for Microservices

#64

Post by joevandyk »

davidw wrote: post #46
Revell wrote: post #10

Earlier quoted context omitted.

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.

Pair programming comes in handy here.

Re: Why we ditched Django for Microservices

#65

Post by Mc_Big_G »

One of my previous employers had let each new incoming VP of engineering use whatever he wanted to build out new parts of the app. With the high turnover rate they had, the app turned into the worst Frankenapp piece of crap imaginable. Significant portions of the app were built in php, java, python, javascript, perl, ruby, ruby on rails, mysql, sybase, and a few more I'm forgetting.

The result was that changing the title on the homepage took two weeks of manual regression testing and it took a new developer a minimum of two weeks to get a development instance up and running. I felt so sorry for the Ops guys, I can't even imagine how terrible it was for them. There was no one, ops or dev, that knew even 25% of how the whole system worked. It always felt like the leaning tower of pisa made toothpicks and popsicle sticks held together with bubble gum and boogers.

The cost to run that Rube Goldberg machine monstrosity ruined what could have been an amazingly profitable business and great place to work. I don't recommend it.

Re: Why we ditched Django for Microservices

#66

Post by indymike »

tmwatson100 wrote: post #20
[deleted] wrote: post #16

Earlier quoted context omitted.

[deleted]

Correct, writing code does not make money. However this change is a little bit like starting a blog... You don't see the immediate benefits straight out but you'll realise them over time. You can put it off and put it off but the longer you do the harder it gets, especially in this scenario. This architecture doesn't make sense for everyone and we could have continued with Django. But making these changes now mean th…

Finding architecture that makes sense to everyone is a tall order.

Re: Why we ditched Django for Microservices

#67

Post by dominotw »

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…

Its not really hard to learn a language/software stack these days.

Re: Why we ditched Django for Microservices

#68

Post by merb »

We had similar issue's. Our Designers couldn't design with that big Django app, so we split it up. Everything talks ReST to a cached AngularJS Client. We still have Authentication in Django and two of our Microservices are running with Django aswell. Some things were reimplemented in Golang, as we tried some new things out.

What people here are talking is mostly dumb, since Microservices are better in a lot of ways especially when it comes to multiple Developers. Currently my company struggled a lot with Code that got changed by two guys at the same time, which was hard to fix.

We had less unit tests than now, since they were too complicated at a certain time.

Re: Why we ditched Django for Microservices

#69

Post by kyllo »

Every time I see microservices, I think of Martin Fowler's First Law of Distributed Object Design: "Don't distribute your objects." http://martinfowler.com/bliki/FirstLaw.html

Splitting your app into multiple apps that send each other HTTP requests or MQ messages seems likely to just make your app slower.

Re: Why we ditched Django for Microservices

#70

Post by sandGorgon »

raverbashing wrote: post #9
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…

And of course, ignoring the problem of duct-taping all the services together. "Oh we'll just RabbitMQ everything together", sure, great, until you discovered certain services needed a smaller latency, more bandwidth, etc And RabbitMQ libraries are a pain and are not smart

actually this is a question that I have - how do you render the final output ?

I mean lets say I request a web page which depends on 5 microservices. What happens ? does rails or whatver block till all five have returned the output - or do you use something like ESI ... how are the microservices composed finally ?

Post reply on HN