3 ms·

> swap in a new process Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way th

by mrkeen 4y ago

> swap in a new process Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called.

Joel_Mckay 4y ago
OTP allows multiple versions in concurrent upgrades across a cluster. Additionally: testing, performance profiling, and debugging are natively supported. Recommend reading: "Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" ( James Edward Gray, II, Bruce A. Tate)
- recuter 4y ago
  Fargate allows multiple versions in concurrent upgrades across a cluster. Additionally: testing, performance profiling, and debugging are natively supported. Recommend reading: "Amazon CloudWatch Container Insights for Amazon EKS Fargate using AWS Distro for OpenTelemetry" (https://aws.amazon.com/blogs/containers/introducing-amazon-cloudwatch-container-insights-for-amazon-eks-fargate-using-aws-distro-for-opentelemetry https://aws.amazon.com/blogs/containers/introducing-amazon-c...)
  - Joel_Mckay 4y ago
    One solution does not include metered connections, or Mr. Bezos compliance. Cheers =)
    - recuter 4y ago
      Sure but that is just one example. There are lots of ways to roll your own similar setup on your own hardware. If you don't like Fargate you can go the k8s route, avoiding lock in is the whole point of it.
distcs 4y ago
> Very technologically cool, but I'd much rather inject the new functionality into the source code. Swapping in a new process and injecting the new functionality into the source code are not mutually exclusive. You can do both! Erlang programmers are not idiots who would swap in new processes live without writing the source code for it and testing it. They write the code, the unit tests, the integration tests, deployment, health/readiness checks, and if all that passes then the deployment tools take care of swapping in the new process with zero downtime.
toast0 4y ago
> Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called. Generally, you do make the changes in source code, compile it, do all your pre-flight checks, and then hotload it. Honestly, sometimes the pre-flight check is just 'does it compile', but that's philisophical; you can put whatever process in place you want. But from my experience, it's much nicer to upgrade in place than start new, move traffic, drain old (not always in exactly that order). Sometimes, it's not realistic to avoid starting new and moving traffic, but it's nice when you can. Most people aren't patching the VM bytecode by hand (to my knowledge).
- worthless-trash 4y ago
  There was that.. interview with a witch. I was a little enamoured by her. https://aphyr.com/posts/341-hexing-the-technical-interview https://aphyr.com/posts/341-hexing-the-technical-interview

by mrkeen 4y ago

Joel_Mckay 4y ago

OTP allows multiple versions in concurrent upgrades across a cluster. Additionally: testing, performance profiling, and debugging are natively supported. Recommend reading: "Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" ( James Edward Gray, II, Bruce A. Tate)

recuter 4y ago
Fargate allows multiple versions in concurrent upgrades across a cluster. Additionally: testing, performance profiling, and debugging are natively supported. Recommend reading: "Amazon CloudWatch Container Insights for Amazon EKS Fargate using AWS Distro for OpenTelemetry" (https://aws.amazon.com/blogs/containers/introducing-amazon-cloudwatch-container-insights-for-amazon-eks-fargate-using-aws-distro-for-opentelemetry https://aws.amazon.com/blogs/containers/introducing-amazon-c...)
- Joel_Mckay 4y ago
  One solution does not include metered connections, or Mr. Bezos compliance. Cheers =)
  - recuter 4y ago
    Sure but that is just one example. There are lots of ways to roll your own similar setup on your own hardware. If you don't like Fargate you can go the k8s route, avoiding lock in is the whole point of it.

distcs 4y ago

> Very technologically cool, but I'd much rather inject the new functionality into the source code. Swapping in a new process and injecting the new functionality into the source code are not mutually exclusive. You can do both! Erlang programmers are not idiots who would swap in new processes live without writing the source code for it and testing it. They write the code, the unit tests, the integration tests, deployment, health/readiness checks, and if all that passes then the deployment tools take care of swapping in the new process with zero downtime.

toast0 4y ago

> Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called. Generally, you do make the changes in source code, compile it, do all your pre-flight checks, and then hotload it. Honestly, sometimes the pre-flight check is just 'does it compile', but that's philisophical; you can put whatever process in place you want. But from my experience, it's much nicer to upgrade in place than start new, move traffic, drain old (not always in exactly that order). Sometimes, it's not realistic to avoid starting new and moving traffic, but it's nice when you can. Most people aren't patching the VM bytecode by hand (to my knowledge).

worthless-trash 4y ago
There was that.. interview with a witch. I was a little enamoured by her. https://aphyr.com/posts/341-hexing-the-technical-interview https://aphyr.com/posts/341-hexing-the-technical-interview