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

[request]: Cross Region Routing #97

Closed
lewislabs opened this issue Aug 28, 2019 · 8 comments
Closed

[request]: Cross Region Routing #97

lewislabs opened this issue Aug 28, 2019 · 8 comments
Assignees
Labels
Roadmap: Awaiting Customer Feedback We need to get more information in order understand how we will implement this feature. Roadmap: Proposed We are considering this for inclusion in the roadmap.

Comments

@lewislabs
Copy link

Tell us about your request
Support for cross region routing with AppMesh.

Which integration(s) is this request for?
All ideally but ECS, EC2 and Fargate would be the priority for me.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We have services that run in a number of AWS regions (and accounts) and would like to be able to use AppMesh to connect these services and manage routing through a single control plane.
A service runs in a particular region because it's been latency optimized for a specific set of users but we also run some core shared microservices in another region that are dependencies. We can replicate these core services across regions but there's a significant overhead there (including database replication) that we would like to avoid.

Are you currently working around this issue?
VPC Peering and using custom service discovery routing (not using AppMesh)

Additional context
Anything else we should know?

Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

@lewislabs lewislabs added the Roadmap: Proposed We are considering this for inclusion in the roadmap. label Aug 28, 2019
@lewislabs lewislabs mentioned this issue Aug 29, 2019
27 tasks
@isaac-mj
Copy link

Hello guys,

We currently have the same need for cross-region routing as we have a set of services distributed across the world with a set of core services running only in a single region.

@lewislabs - I've noticed that you mentioned that you worked around this problem with VPC Peering and a custom service discovery? Would you be able to give me more details (either on this thread or privately?)

We are considering Consul as an alternative but I would much rather stick to AWS.

Thx,
Isaac.

@dastbe
Copy link
Contributor

dastbe commented Sep 26, 2019

@lewislabs and @isaac-mj

would a Managed Ingress (#37) get you far enough? This would allow you to have multiple meshes in distinct regions, while still having your core mesh that others could talk to via its ingress.

In my mind, cross-region routing needs to at least get to the point where a single logical service can be deployed in multiple regions and, via Envoy, the shortest-cost (which tends to be both latency and $$$-wise :-p) endpoints are used for routing. This (to me) sounds more powerful than what you actually need to accomplish your goal.

@shubharao
Copy link

@lewislabs Can you please tell us more about the custom service discovery routing - what exactly does it do?
@isaac-mj If you can create a mesh for each region but represent the core service that runs in one region using a DNS name, would that meet your use case? Are you looking for more routing controls for the connection cross region?

@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 26, 2019
@lewislabs
Copy link
Author

@dastbe I think managed ingress could solve the problem, but maybe I need some more clarity on what managed ingress looks like.

The problem we have is can be described by this simple example.

Service A exists in an AppMesh in us-east-1. 
Service B exists in an AppMesh in eu-west-1. 
Service B would like to call Service A. 

I believe we could quite easily achieve the above with inter-region VPC peering + Managed Ingress?

But now if we deployed instances of Service B into the mesh in us-east-1. Would there be a way for traffic to preference sticking within the same region where it can or is this something that's going to require additional custom configuration?

@lewislabs
Copy link
Author

@shubharao

When I say custom service discovery that's probably the wrong term. We run an instance of eureka and have custom libraries built around that to do routing based on the eureka service repository.

@shubharao shubharao self-assigned this Sep 27, 2019
@shubharao
Copy link

shubharao commented Sep 28, 2019

@lewislabs

I believe we could quite easily achieve the above with inter-region VPC peering + Managed Ingress?

Yes, that is our recommended approach. We are researching on how to support the ingress use case (#37). Since both AWS Cloud Map and AWS App Mesh are regional services, the service discovery and app mesh routing will keep traffic within the region. Further, we are investigating how to enable the AZ aware routing use case (#94).

@lewislabs
Copy link
Author

@shubharao sounds like both #37 and #94 could solve the problem. Thanks!

@shubharao
Copy link

Closing this issue as duplicate of the two that we are already tracking - modeling ingress services (#37) and Zone aware routing (#94). If you have other use cases for requiring a mesh that spans across regions or for routing across regions, please open a new one.

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. Roadmap: Proposed We are considering this for inclusion in the roadmap.
Projects
None yet
Development

No branches or pull requests

4 participants