Earlier quoted context omitted.
Wow, that sounds like an utter nightmare.
I can imagine why you think that, but actually it works really well. I could write a blog post about it if there is some interest.
I'm definitely interested!
Why our team cancelled our move to microservices
241–243 of 243 posts
Re: Why our team cancelled our move to microservices
#242Earlier quoted context omitted.
That's what makes the whole idea of microservices seems weird to me. If a functionality has merit on its own (e.g. an authentication service), then it will naturally fall outside of the main application. If a service is tightly coupled to other parts of the app, then microservices seems like intentionally hindering yourself: the coupling remains (as evident by the need for backward compatibility), but now we it's har…
I agree that tightly coupled modules should live inside the same deployment, but: >it's harder to keep everything aligned due to the extra separation (e.g. different code bases, multiple databases, no static validation of remote interfaces etc.) It's solvable with appropriate tooling. I.e. you can store API definitions in a separate repository and make the services or CI/CD check API usage is valid at build time. >ti…
> It's solvable with appropriate tooling. I.e. you can store API definitions in a separate repository and make the services or CI/CD check API usage is valid at build time.
Makes sense, though it feels somewhat like re-inventing the wheel (same-codebase tooling are generally easier and faster to use).
> What do you mean by that? Data and workflow have to be unified across the company's products to provide the user with a seamless experience. As above, to me this seems may contradict some components of microservices like splitting the database, since one ends up with the same constraints (synchronization, shared schema) while complicating the orchestration (since now cross-system integration is needed).
Sure, something like Reddit or HN can break the unified experience, but any important or productivity system will greatly suffer from such fragmentation. I assume it can be achieved with micro-services, but it seems somewhat harder.
Re: Why our team cancelled our move to microservices
#243Practically every technology decision has pros and cons. I think that if you can't think of a good reason not to use some technology, then you don't understand the technology well enough yet and you shouldn't try to use it in production yet. It may be what you need, but thinking that "everything must switch to this" is usually a huge warning signal that cargo cult engineering is happening instead of real engineering.
This point is reminiscent of the Chesterton’s Fence concept discussed on HN recently
I completely agree, good point! Historically Chesterton's Fence is that you shouldn't remove something until you understand why it's there, but we should probably broaden the lesson to cover change of any kind. Something like, "Don't remove anything until you understand why it's there, and don't use something new until you understand under what conditions that new thing is better (vs. when it isn't)." I'm not against change, but I do hate the endless cargo cults.