3 ms·

I always tell people that if they can't build a monolith with their team they shouldn't do microservices. Micro-Services are often used as a bandaid over lack o

I always tell people that if they can't build a monolith with their team they shouldn't do microservices. Micro-Services are often used as a bandaid over lack of coordination. This works for a little while but once you need a refactor over several services you are in deep trouble.

crdoconnor 8y ago
I've found that there are four main situations where separating functionality out in to a different service works: * That service would work well enough on its own as a startup - it's internally complicated but isolated and requires a very simple abstraction (e.g. doing a postcode lookup service). * As a facade to create a clean interface to something that is not clean (e.g. a nice REST API that talks to a crazy weird industrial control system over a parallel port which only runs on windows). * The operational requirements of the code are entirely different (e.g. moving data processing from the webserver to a task server and feeding it via a queue). * As a means of linking components in a large scale system run by a large organization that has multiple teams that often write code in different languages and have real trouble coordinating with one another but are nonetheless overseen by a crazy smart architect. The latter was basically where Martin Fowler thought microservices worked well, and it probably did, but he kind of forgot that A) the absence of a crazy smart architect is more common than the presence and B) this was a hack which involved a shit ton of extra operational overhead that was only worth it because it solved a gnarly people problem. When startups of 7 people run more than 3 services I start looking for the microservice kool aid.
user5994461 8y ago
They should work in a single repo. It makes everything easier, especially refactoring.

3 ms·

I always tell people that if they can't build a monolith with their team they shouldn't do microservices. Micro-Services are often used as a bandaid over lack o

by maxxxxx 8y ago

crdoconnor 8y ago
I've found that there are four main situations where separating functionality out in to a different service works: * That service would work well enough on its own as a startup - it's internally complicated but isolated and requires a very simple abstraction (e.g. doing a postcode lookup service). * As a facade to create a clean interface to something that is not clean (e.g. a nice REST API that talks to a crazy weird industrial control system over a parallel port which only runs on windows). * The operational requirements of the code are entirely different (e.g. moving data processing from the webserver to a task server and feeding it via a queue). * As a means of linking components in a large scale system run by a large organization that has multiple teams that often write code in different languages and have real trouble coordinating with one another but are nonetheless overseen by a crazy smart architect. The latter was basically where Martin Fowler thought microservices worked well, and it probably did, but he kind of forgot that A) the absence of a crazy smart architect is more common than the presence and B) this was a hack which involved a shit ton of extra operational overhead that was only worth it because it solved a gnarly people problem. When startups of 7 people run more than 3 services I start looking for the microservice kool aid.
user5994461 8y ago
They should work in a single repo. It makes everything easier, especially refactoring.