3 ms·

> split along domain lines with minimum inter-service dependencies. Exactly, and done right that quite often means big 'microservices'. All too often I see t

> split along domain lines with minimum inter-service dependencies. Exactly, and done right that quite often means big 'microservices'. All too often I see the 'functional programming disease' where the aim is to deconstruct to the smallest possible reusable functions ( 'micro' services right? ), often prematurely, creating high levels of compositional complexity and with zero tools to help you understand how the actual 'app' - say payment system works if it's distributed across 20 services. Yep each single microservice is simple - but the payment system might not be and that's what you need to understand - better if your payment system is one thing - with maybe one or two things separated out if you need to scale that part.

capableweb 7y ago
"Yep each single microservice is simple - ..." but the whole is not. I always find it more interesting what's _not_ in the single microservices, the stuff you do see. When you make a diagram with boxes and arrows, the interesting stuff would be the arrows, not the boxes themselves.
- crdrost 7y ago
  Indeed my loudest prescription to people doing service-oriented architectures of any kind is to simplify these arrows. The common mistakes that I see are for two services to share read access to a common database, or to discover each other and send RPCs to each other. Both really dangerous for exactly this reason! The common database obscures how the two communicate with each other, and invariably everything connected to a database becomes one service -- call it a "mini-lith" if the overlapping sets created by databases do not cover the whole architecture. The problem is the preponderance of implicit arrows; when I reason about what it means to make this datetime nullable so that I can store such-and-so, I need to consider whether everybody who can read that datetime will be prepared for its nullability. RPCs and APIs are the same way. I add a contract about what I am outputting and then everybody needs to know about my contracts and I must commit to them or else modify all of my consumers. So because the arrows are bi-directional everything just becomes one monolith again. Instead, I recommend message brokers -- all that pubsub stuff. A given service tells all the other services simultaneously "this happened," and it is their responsibility in their codebase to listen for that event and then say "okay, then this must happen." Publishing a new version of the event is done by just emitting both the old and the new version of the event and perhaps having a shared standard for deprecation across the codebase so that you get deprecation warnings in your prod logs. Every service has its own database and they generally only communicate to each other through these broadcasts, makes the arrows into the "stuff you do see".
ajsharp 7y ago
Completely agree. The micro thing is rooted in a desire for simplicity, which is laudable from a theoretical perspective. Small is simple and simple is nice to work with. But in any production software it's usually a pipe dream. Kind of the whole point of software is to take a bunch of complexity and make it simpler for the end user. The fact that the software visually looks like shit or is difficult to work with because it's difficult to reason about is a rather unfortunate side-effect, but usually has no bearing on actual business success. There are lots of things we should try to do to reduce software complexity and make it easier and safer to work with and change. But trying to force simplicity by way of size usually has the opposite effect.
tabtab 7y ago
It's sometimes said that in software, there hasn't been anything truly new under the sun since the 1970's, just incremental refinements or repacking under a different name. And Lisp has been around since about 1960. So if any fad/trend comes along promising the sun and stars of simplicity or productivity, search IT history and find the downsides and trade-offs. I wish there were more KISS pundits than fad pundits.

capableweb 7y ago

"Yep each single microservice is simple - ..." but the whole is not. I always find it more interesting what's _not_ in the single microservices, the stuff you do see. When you make a diagram with boxes and arrows, the interesting stuff would be the arrows, not the boxes themselves.

crdrost 7y ago
Indeed my loudest prescription to people doing service-oriented architectures of any kind is to simplify these arrows. The common mistakes that I see are for two services to share read access to a common database, or to discover each other and send RPCs to each other. Both really dangerous for exactly this reason! The common database obscures how the two communicate with each other, and invariably everything connected to a database becomes one service -- call it a "mini-lith" if the overlapping sets created by databases do not cover the whole architecture. The problem is the preponderance of implicit arrows; when I reason about what it means to make this datetime nullable so that I can store such-and-so, I need to consider whether everybody who can read that datetime will be prepared for its nullability. RPCs and APIs are the same way. I add a contract about what I am outputting and then everybody needs to know about my contracts and I must commit to them or else modify all of my consumers. So because the arrows are bi-directional everything just becomes one monolith again. Instead, I recommend message brokers -- all that pubsub stuff. A given service tells all the other services simultaneously "this happened," and it is their responsibility in their codebase to listen for that event and then say "okay, then this must happen." Publishing a new version of the event is done by just emitting both the old and the new version of the event and perhaps having a shared standard for deprecation across the codebase so that you get deprecation warnings in your prod logs. Every service has its own database and they generally only communicate to each other through these broadcasts, makes the arrows into the "stuff you do see".

ajsharp 7y ago

Completely agree. The micro thing is rooted in a desire for simplicity, which is laudable from a theoretical perspective. Small is simple and simple is nice to work with. But in any production software it's usually a pipe dream. Kind of the whole point of software is to take a bunch of complexity and make it simpler for the end user. The fact that the software visually looks like shit or is difficult to work with because it's difficult to reason about is a rather unfortunate side-effect, but usually has no bearing on actual business success. There are lots of things we should try to do to reduce software complexity and make it easier and safer to work with and change. But trying to force simplicity by way of size usually has the opposite effect.

tabtab 7y ago

It's sometimes said that in software, there hasn't been anything truly new under the sun since the 1970's, just incremental refinements or repacking under a different name. And Lisp has been around since about 1960. So if any fad/trend comes along promising the sun and stars of simplicity or productivity, search IT history and find the downsides and trade-offs. I wish there were more KISS pundits than fad pundits.