Skip to content
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

Open
dastbe opened this issue Sep 26, 2019 · 5 comments
Open

Feature Request: Backend Groups #113

dastbe opened this issue Sep 26, 2019 · 5 comments
Assignees
Labels
Roadmap: Awaiting Customer Feedback We need to get more information in order understand how we will implement this feature.

Comments

@dastbe
Copy link
Contributor

dastbe commented Sep 26, 2019

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

@dastbe dastbe added the Roadmap: Proposed We are considering this for inclusion in the roadmap. label Sep 26, 2019
@shubharao shubharao self-assigned this Sep 28, 2019
@shubharao shubharao added the Roadmap: Awaiting Customer Feedback We need to get more information in order understand how we will implement this feature. label Sep 28, 2019
@shubharao
Copy link

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?

@shubharao shubharao removed the Roadmap: Proposed We are considering this for inclusion in the roadmap. label Oct 9, 2019
@kiranmeduri kiranmeduri assigned herrhound and unassigned shubharao Apr 12, 2021
@FranzBusch
Copy link

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.

@kevinten10
Copy link

Hi, is there any progress?

@jeremymill
Copy link

jeremymill commented Sep 12, 2022

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 --set enableBackendGroups=true.

More information on Backend Groups can be found here: https://aws.github.io/aws-app-mesh-controller-for-k8s/reference/backend_groups/

@kevinten10
Copy link

Thanks for the support, this is a delightful feature, we will try it next.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Roadmap: Awaiting Customer Feedback We need to get more information in order understand how we will implement this feature.
Projects
None yet
Development

No branches or pull requests

9 participants