3 ms·

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 mos

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
  Scaling is not the issue
  - lstamour 5y ago
    Perhaps I didn’t explain myself fully. OpenPolicyAgent distributes the policy so you can integrate[1] it with systems that need to ask for validation such that lookups are constant time and performed on the same machine but distributed - scaled - using code and data shipped to every consumer/integrator of the validation service, instead of making a separate call to validate. So you can have centralized control of your validation logic and data but have it run as part of a decentralized application or on the same host as part of a pod. That is what I meant by a design that “scales”. That said, depending on the type of validation performed, zero trust systems for example are often built using centralized validation endpoints, so it’s not entirely a bad practice. 1: https://www.openpolicyagent.org/docs/latest/integration/ https://www.openpolicyagent.org/docs/latest/integration/
malandrew 5y ago
Your story both makes me want to laugh and cry because I've seen this pattern so many times. These days when I do architecture interviews, I always make sure the problem can be solved distributed or monolithic and when they do distributed, I asked them why and to explain the trade-offs. If they do monolithic, I ask them why not distributed. Etc. For senior engineers, it's such a good indicator of whether or not they've truly worked in distributed systems and understand the human side of the problem. The big O stuff is great, but the human and organizational costs are easily as important to assess as the computational and memory costs.

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
Scaling is not the issue
- lstamour 5y ago
  Perhaps I didn’t explain myself fully. OpenPolicyAgent distributes the policy so you can integrate[1] it with systems that need to ask for validation such that lookups are constant time and performed on the same machine but distributed - scaled - using code and data shipped to every consumer/integrator of the validation service, instead of making a separate call to validate. So you can have centralized control of your validation logic and data but have it run as part of a decentralized application or on the same host as part of a pod. That is what I meant by a design that “scales”. That said, depending on the type of validation performed, zero trust systems for example are often built using centralized validation endpoints, so it’s not entirely a bad practice. 1: https://www.openpolicyagent.org/docs/latest/integration/ https://www.openpolicyagent.org/docs/latest/integration/

malandrew 5y ago

Your story both makes me want to laugh and cry because I've seen this pattern so many times. These days when I do architecture interviews, I always make sure the problem can be solved distributed or monolithic and when they do distributed, I asked them why and to explain the trade-offs. If they do monolithic, I ask them why not distributed. Etc. For senior engineers, it's such a good indicator of whether or not they've truly worked in distributed systems and understand the human side of the problem. The big O stuff is great, but the human and organizational costs are easily as important to assess as the computational and memory costs.