3 ms·

Glad to see Dhall (https://dhall-lang.org/ https://dhall-lang.org/) mentioned here. As we seem to be heading towards immutable-'everything' though, sometimes I

by klysm 7y ago

Glad to see Dhall (https://dhall-lang.org/ https://dhall-lang.org/) mentioned here. As we seem to be heading towards immutable-'everything' though, sometimes I wonder how valuable dynamic (in the sense of picked up at start) configuration is for backend services. It seems preferable to build everything, config included, into one single artifact. Potentially this gives more optimization opportunities as a lot branches could be completely eliminated (feature flags, etc.). No doubt the simplest way to build your config directly into your code is to just.. have it be code. A potentially super annoying trade-off is that it's difficult to test minor configuration tweaks, and the annoyingness scales non-linearly with your build time.

q3k 7y ago
And even more annoying if you would rather not restart your services unless absolutely necessary (ie. you're handling long-lived TCP connections that cannot be handed off gracefully). Not to mention that some kind of configuration tweaks (ie. ACL changes, quota changes, etc) might happen at a vastly different cadence than software rollouts.
- jchw 7y ago
  > if you would rather not restart your services unless absolutely necessary (ie. you're handling long-lived TCP connections that cannot be handed off gracefully). If you have no way to hand off your TCP connections gracefully, that is probably not a great position to be in because computers are unreliable and sometimes you need security updates. One approach I tried experimentally for a TCP server (but unfortunately did not have the opportunity to try in production) was to have a small server acting as the frontend that handled sessions and called into the real implementation which was essentially stateless. This small server could theoretically support self updating without dropping connections, if need be. (The main reason I was doing this was so that the rest of the stack could be dynamically-scaling based on Kubernetes, while this part remained relatively static.) I think anytime you have forced statefulness, it’s worth isolating as much as possible so it doesn’t constrain the design of the whole system. (Even better, of course, is to just have a protocol where clients can gracefully handle draining and reconnect without side effects.) > ACL changes, quota changes, etc At a certain level I think these are runtime data and not configs. Aforementioned service also dealt with ACLs and configs and we were serving it through another service that persisted to a database layer. One cool thing about doing it as a service is that you can manage and scale it like any other service.
  - q3k 7y ago
    > At a certain level I think these are runtime data and not configs. I think that's the gist of the issue - sometimes it's difficult to tell which one is which :). And I agree with the 'TCP connection in thin server' approach. Thankfully, I only have to deal with two protocols where this is an issue: IRC and BGP.
    - jchw 7y ago
      >I think that's the gist of the issue - sometimes it's difficult to tell which one is which :). Absolutely... in fact, there's definitely stuff that I've had start as configuration and gradually turn into runtime data, and there are things I would call configuration that need to be dynamic at runtime too... I'm never 100% satisfied with the split.
- klysm 7y ago
  Ideally this isn't how you achieve HA - machines are unreliable and therefore service instances are too. Absolute statelessness is the goal, but of course that's exceptionally hard to achieve in the real world and bopping live connections will always cause annoyances.
dfee 7y ago
Something that really annoys me about that intro: No, I can’t identify what’s wrong with it. Why am I spending what feels like 5 minutes studying a code sample to find a flipped ‘I’ and ‘L’? Every time I read about dahl, I remember this and it sours my patience for the language. It’s a good point, but there’s got to be a better way of communicating the value. Or, maybe just having a button that says “spoilers” and reveals the issue.
- kelnos 7y ago
  I couldn't figure it out either! But now that you tell me what's wrong, it looks completely obvious. And I agree that it turned me off on reading the rest of the page.

by klysm 7y ago

q3k 7y ago

And even more annoying if you would rather not restart your services unless absolutely necessary (ie. you're handling long-lived TCP connections that cannot be handed off gracefully). Not to mention that some kind of configuration tweaks (ie. ACL changes, quota changes, etc) might happen at a vastly different cadence than software rollouts.

jchw 7y ago
> if you would rather not restart your services unless absolutely necessary (ie. you're handling long-lived TCP connections that cannot be handed off gracefully). If you have no way to hand off your TCP connections gracefully, that is probably not a great position to be in because computers are unreliable and sometimes you need security updates. One approach I tried experimentally for a TCP server (but unfortunately did not have the opportunity to try in production) was to have a small server acting as the frontend that handled sessions and called into the real implementation which was essentially stateless. This small server could theoretically support self updating without dropping connections, if need be. (The main reason I was doing this was so that the rest of the stack could be dynamically-scaling based on Kubernetes, while this part remained relatively static.) I think anytime you have forced statefulness, it’s worth isolating as much as possible so it doesn’t constrain the design of the whole system. (Even better, of course, is to just have a protocol where clients can gracefully handle draining and reconnect without side effects.) > ACL changes, quota changes, etc At a certain level I think these are runtime data and not configs. Aforementioned service also dealt with ACLs and configs and we were serving it through another service that persisted to a database layer. One cool thing about doing it as a service is that you can manage and scale it like any other service.
- q3k 7y ago
  > At a certain level I think these are runtime data and not configs. I think that's the gist of the issue - sometimes it's difficult to tell which one is which :). And I agree with the 'TCP connection in thin server' approach. Thankfully, I only have to deal with two protocols where this is an issue: IRC and BGP.
  - jchw 7y ago
    >I think that's the gist of the issue - sometimes it's difficult to tell which one is which :). Absolutely... in fact, there's definitely stuff that I've had start as configuration and gradually turn into runtime data, and there are things I would call configuration that need to be dynamic at runtime too... I'm never 100% satisfied with the split.
klysm 7y ago
Ideally this isn't how you achieve HA - machines are unreliable and therefore service instances are too. Absolute statelessness is the goal, but of course that's exceptionally hard to achieve in the real world and bopping live connections will always cause annoyances.

dfee 7y ago

Something that really annoys me about that intro: No, I can’t identify what’s wrong with it. Why am I spending what feels like 5 minutes studying a code sample to find a flipped ‘I’ and ‘L’? Every time I read about dahl, I remember this and it sours my patience for the language. It’s a good point, but there’s got to be a better way of communicating the value. Or, maybe just having a button that says “spoilers” and reveals the issue.

kelnos 7y ago
I couldn't figure it out either! But now that you tell me what's wrong, it looks completely obvious. And I agree that it turned me off on reading the rest of the page.