Hacker News Reader

Comment by bsdpython | Hacker News Reader

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 reason for introducing a new language or technology to your stack and think carefully before diving in. Just create separate Django apps and only switch to a different tech if Django is particularly ill suited for the task.

View on HN

My thoughts as well. It seems like the problem here wasn't "monolithic Django codebase". The author mentions that he had a lot of trouble getting new developers up to speed because of package requirements.

That should be the simplest problem ever to solve. Use a requirements.txt, use vagrant, and maybe even Salt or Chef if you require more specific tools.

Microservices are great in theory, but every app ends up requiring a lot more interconnectedness as you grow. I'm all for splitting services off, but it's usually something to consider once you're a few iterations in.

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.

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.

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.

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.

There is absolutely no need to use different languages and technologies within a microservices architecture if it is not necessary for your business. But to simply dismiss the business perspective from your perspective seems a little naive.

Some reasons why decoupling your architecture can make sense from a business perspective:

- You have a complicated product, and wish to break it up into more digestible chunks, with allocated teams working on each abstract business concept (Amazon and Spotify do this).

- You want to avoid having a single point of failure- if one service fails, the rest of the system might well keep on working. (Ever noticed how sometimes a panel on Amazon doesn't load?). If you're running a continuous development process, stuff breaks, a lot. It's good if that's locked down.

- You have a business requirement to build something with a different technology (from experience- rendering javascript in a node service was much, much easier and more maintainable than with an existing Django app- we tried both.)

- You want to experiment with new technologies without changing your whole stack.

I'm pretty sure that the author wasn't talking about moving to microservices so they can blindly start building every aspect of the application in a different stack- but more that if they need to use a new technology for their business requirements, or want to give something a trial without committing, they can. And with the uncertainty and rate things change in modern software, and in a startup, that flexibility is invaluable.

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.

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

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.)

Reply on news.ycombinator.com