3 ms·
Things like these are taken as dogma or a religion -- and are applied to all things in an organization, for better or for worse. When there's a case for tighte
by lxe 5y ago
Things like these are taken as dogma or a religion -- and are applied to all things in an organization, for better or for worse.
When there's a case for tighter coupling and less services, (and yes, there are cases for it), this memo gets brought up and microservices win the argument.
- drewcoo 5y agoWhat is an organizational case for tighter coupling and fewer services? Downsizing with an intent to not grow in the same direction again?
- lumost 5y agoEach Service adds a marginal cost to maintenance, ops, infrastructure and debatably development speed (Easier to refactor in an IDE and semi-atomically deployed code than 50 independent services ). If you have a team of 5 people, launching 50 services is probably not as efficient as 10 services.
- ChrisMarshallNY 5y agoAs someone that tends to work this way, I can tell you that every API adds overhead. This is because they need to be documented, tested, and release-managed. Each of my APIs is a self-contained project, with its own lifecycle. That can, potentially, add a lot of overhead, and “concrete galosh”[0] to the project. And I am not a fan of dogma, in general. I like flexibility, and dogma is anathema to flexibility. [0] https://littlegreenviper.com/miscellany/concrete-galoshes/ https://littlegreenviper.com/miscellany/concrete-galoshes/
- jimbokun 5y ago> Downsizing with an intent to not grow in the same direction again? More like we're not really big enough yet to justify multiple services, since everything still runs on a single beefy machine and we don't have enough experience running the system yet to really know where to put the service boundaries.