4 ms·
The optimal lifecycle is to start with the same language you'll finish with. You can rewrite and refactor as much as you want, but you never need to rewrite the
by twblalock 8y ago
The optimal lifecycle is to start with the same language you'll finish with. You can rewrite and refactor as much as you want, but you never need to rewrite the entire thing from scratch in one shot and get it right.
The funny thing is, with microservices it shouldn't really matter what language each service is written in as long as the services can talk to each other, but most companies end up using the same language for everything because it's easier to hire people who know the same language and can work on multiple projects.
- aylmao 8y agoAlso because if you use the same language it's easier to re-use code and interface definitions.
- Slartie 8y agoYeah, going down this path usually leads to a tightly coupled, monolithic-in-practice system of "microservices" which are effectively developed and operated like the previous, monolithic system was, but with added overhead (both runtime and dev-time) on top for a layer that fakes loose coupling, with the sole actual reason for existence of this layer being that it allows people to call this abomination of an architecture "microservice-based".
- frou_dh 8y agoThe software architecture equivalent of Security Theater... Decoupling Theater
- wsy 8y agoWe started with two languages on our microservice backend. It is definitely an up-front investment. But it pays off in several ways: - our service infrastructure is really language-agnostic. - our design discussions are on an abstraction level above the language level. (of course there are language-specific implementation strategy discussions, too.) - while it is a bit harder to find suitable developers, I think we attract a very valuable subset: people who are not tied to their favourite language, and don't shy away from learning new things.