-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Backend Groups #113
Comments
Looking for input from customers on the usability of the workflow, specifically: (1) App Mesh now defaults to a mesh that is connected explicitly with defining the backends, would you like to have a default fully connected mesh within a namespace instead? (2) Is the workflow of defining the backends of each virtual service and keeping it up to date hard? (3) what type of automation/CI-CD workflow do you plan to use with App Mesh? |
We have just started using App Mesh. IMO the feature of backend groups or default connectivity between services would be great. We have a lot of services and defining each backend for each service is a lot of overhead. |
Hi, is there any progress? |
A new experimental Backend Groups feature has been added for App Mesh Kubernetes users as of controller v1.6.0. They can be enabled by deploying the controller with the feature flag More information on Backend Groups can be found here: https://aws.github.io/aws-app-mesh-controller-for-k8s/reference/backend_groups/ |
Thanks for the support, this is a delightful feature, we will try it next. |
Tell us about your request
I propose adding the ability to define decouple dgroups of backends (backend groups!) that can be referenced by a Virtual Node. This would allow for common groupings of backends to be updated in O(1), while still allowing additional fine grained inclusion of more Virtual Services.
Which integration(s) is this request for?
All
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
While the ability to be extremely fine-grained about what services an individual node can connect to is great, it leads to a lot of repetition across nodes. The addition of a new core backend would require churn across every single node in a mesh. This gets worse with orchestrators on top of App Mesh, as any namespace concept they would build on top of App Mesh would require O(N) work to reconcile.
For example, if we were to introduce label-based backends into the k8s controller, such a feature would require linear time work for reconciliation of nodes <-> backends.
Having a decoupled grouping of backends makes this fairly straightforward, as groups could be created for namespaces, and associating/dissociating nodes and services from groups can be done in O(1) operations.
Are you currently working around this issue?
N/A
Additional context
You're all really great.
Attachments
The text was updated successfully, but these errors were encountered: