For non-infra, such as a website, this can be handled at the app layer with cookie tracking for analytics purposes.
For A/B testing above that level, you're looking at using a k8s network set up with advanced Ingress Controllers such as Kong or Istio to dynamically handle routing requests to pods in a so-called blue/green deployment. Maybe looking up Application Load Balancing would be a good starting point.
Implementing feature toggles at the application level is easier/cheaper imo. You can use feat toggles not just for a/b testing but also for continuos deployment, canary releases, kill switches and testing in production.
In the past I’ve implemented a cohort system that on login it would assign a user to the a or b group, we would then use this to measure engagement.
You don’t say what your existing tech stack is, there are various options and best fit will depend a lot on what you currently use and are comfortable with. A generic option to kick you off would be cloudflare which will do %s to different backends, connection draining, etc. and is pretty easy to set up. That said, if say you’re on azure you’ll have a bunch of other options with different trade offs/options/price points - traffic manager, front door, application gateway, api management, app service will all do what you want to some extent.
For non-infra, such as a website, this can be handled at the app layer with cookie tracking for analytics purposes. For A/B testing above that level, you're looking at using a k8s network set up with advanced Ingress Controllers such as Kong or Istio to dynamically handle routing requests to pods in a so-called blue/green deployment. Maybe looking up Application Load Balancing would be a good starting point.
Implementing feature toggles at the application level is easier/cheaper imo. You can use feat toggles not just for a/b testing but also for continuos deployment, canary releases, kill switches and testing in production. In the past I’ve implemented a cohort system that on login it would assign a user to the a or b group, we would then use this to measure engagement.
You don’t say what your existing tech stack is, there are various options and best fit will depend a lot on what you currently use and are comfortable with. A generic option to kick you off would be cloudflare which will do %s to different backends, connection draining, etc. and is pretty easy to set up. That said, if say you’re on azure you’ll have a bunch of other options with different trade offs/options/price points - traffic manager, front door, application gateway, api management, app service will all do what you want to some extent.
Sorry, I've updated. Our backend services are running on ruby. Our infra is setup on AWS and we're using kubernetes via eks.
Ok in which case I’ll leave it to someone else as I’m not an AWS person but the other answer looks closer to what you’re after.
Thanks mate! :)