4 ms·

This is happening to me, its driving me nuts. Any advice on how to get out of it?

abakker 5y ago
My advice would be to carefully construct an explanations of the scenarios when microservices do apply, and then explain why you are not currently in that situation. the best microservice examples I've ever found were for the addition of features to legacy systems, the ability to write minor additional things in alternate languages, and most critically, when the original code base couldn't be changed or was lost, and yet more functionality was required. There are valid reasons to add a microservice there are probably not good reasons to take a normal code base made by a modern company and completely shift to only microservices.
- throwaway6532 5y ago
  >My advice would be to carefully construct an explanations of the scenarios when microservices do apply, and then explain why you are not currently in that situation. I tried that once. Didn't work. End result was just pure pain.
bob1029 5y ago
One thing that has periodically worked for me is the application of some fun infographic-tier latency figures to really drive home the argument for why distributed anything generally sucks ass. I.e. Would you rather that customer transaction either be: 1) A direct method invocation resolved within the same L1 cache contents. or 2) One quick network hop just 5 milliseconds away? Assuming worst case processing semantics (global total order), you would be able to process ~10 million times more customer transactions per unit time with option 1 vs option 2. This is seven orders of magnitude. In my experience, not a whole lot is truly worst case, but most complicated & important business systems (banking/finance/inventory/logistics/crm/etc.) are pretty close if you don't want to be chasing temporal rabbits around all day.
- willcipriano 5y ago
  I worked at a place that had a microservice for validations. You made a request with the item (singular) to be validated and the rule to validate it by. The most common validations were things like "is this value greater than 15" or "are these values equal". Nobody else saw the problem here. Establishing a http connection, serializing a JSON document, deseralizing it on the other side, then doing "14 == 15" anyway before going back the way it came. Lighting up a hundred thousand lines of code vs one. This was done as it iterated over large files, millions of items, millions of requests. They were genuinely confused why it was slow.
  - bob1029 5y ago
    I am sure "ValidationService" made perfect sense to everyone the first day it was dreamed up. IIRC we had one named that too for a while back when we were lost in the dark forest.
  - lstamour 5y ago
    This is actually why I think we need more cloud and not less. The problem is poorly designed code, not monolith or microservice. For example, ValidationService as described above could be replaced with OpenPolicyAgent and would scale much better. That said, I could see someone pointing at OpenPolicyAgent and asking why they didn’t separate distributed updates from the policy spec as two distinct projects, this way you could re-use parts of OPA to distribute config files or feature flags. You can now too, but it requires the extra hop of compiling a function to answer. Come to think of it, distributed state updating is roughly the same general problem that Kubernetes Operator pattern solves. Another way of putting it, we have cloud primitives but not enough of them, maybe - or they aren’t well enough explained - to make the choices or restrictions of different architectures a bit more obvious? I especially look forward to a future when we get “design systems” for the programming we do with business logic in the cloud. I’m over-emphasizing cloud here. I mean code you don’t directly have to maintain and write regardless of where it runs or who wrote it.
    - gizzlon 5y ago

My advice would be to carefully construct an explanations of the scenarios when microservices do apply, and then explain why you are not currently in that situation. the best microservice examples I've ever found were for the addition of features to legacy systems, the ability to write minor additional things in alternate languages, and most critically, when the original code base couldn't be changed or was lost, and yet more functionality was required. There are valid reasons to add a microservice there are probably not good reasons to take a normal code base made by a modern company and completely shift to only microservices.

throwaway6532 5y ago
>My advice would be to carefully construct an explanations of the scenarios when microservices do apply, and then explain why you are not currently in that situation. I tried that once. Didn't work. End result was just pure pain.

bob1029 5y ago

One thing that has periodically worked for me is the application of some fun infographic-tier latency figures to really drive home the argument for why distributed anything generally sucks ass. I.e. Would you rather that customer transaction either be: 1) A direct method invocation resolved within the same L1 cache contents. or 2) One quick network hop just 5 milliseconds away? Assuming worst case processing semantics (global total order), you would be able to process ~10 million times more customer transactions per unit time with option 1 vs option 2. This is seven orders of magnitude. In my experience, not a whole lot is truly worst case, but most complicated & important business systems (banking/finance/inventory/logistics/crm/etc.) are pretty close if you don't want to be chasing temporal rabbits around all day.

willcipriano 5y ago
I worked at a place that had a microservice for validations. You made a request with the item (singular) to be validated and the rule to validate it by. The most common validations were things like "is this value greater than 15" or "are these values equal". Nobody else saw the problem here. Establishing a http connection, serializing a JSON document, deseralizing it on the other side, then doing "14 == 15" anyway before going back the way it came. Lighting up a hundred thousand lines of code vs one. This was done as it iterated over large files, millions of items, millions of requests. They were genuinely confused why it was slow.
- bob1029 5y ago
  I am sure "ValidationService" made perfect sense to everyone the first day it was dreamed up. IIRC we had one named that too for a while back when we were lost in the dark forest.
- lstamour 5y ago
  This is actually why I think we need more cloud and not less. The problem is poorly designed code, not monolith or microservice. For example, ValidationService as described above could be replaced with OpenPolicyAgent and would scale much better. That said, I could see someone pointing at OpenPolicyAgent and asking why they didn’t separate distributed updates from the policy spec as two distinct projects, this way you could re-use parts of OPA to distribute config files or feature flags. You can now too, but it requires the extra hop of compiling a function to answer. Come to think of it, distributed state updating is roughly the same general problem that Kubernetes Operator pattern solves. Another way of putting it, we have cloud primitives but not enough of them, maybe - or they aren’t well enough explained - to make the choices or restrictions of different architectures a bit more obvious? I especially look forward to a future when we get “design systems” for the programming we do with business logic in the cloud. I’m over-emphasizing cloud here. I mean code you don’t directly have to maintain and write regardless of where it runs or who wrote it.
  - gizzlon 5y ago