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

Legacy Migration with Yarp and Azure Deployment #544

Open
Wraith2 opened this issue Sep 19, 2024 · 3 comments
Open

Legacy Migration with Yarp and Azure Deployment #544

Wraith2 opened this issue Sep 19, 2024 · 3 comments
Labels
Needs: Attention 👋 Issues and PRs that the maintainers should take a look at

Comments

@Wraith2
Copy link

Wraith2 commented Sep 19, 2024

In the article https://devblogs.microsoft.com/dotnet/incremental-asp-net-to-asp-net-core-migration/ the adapters in this repository and Yarp are used to provide an upgrade path from a monolithic legacy application towards modern runtimes. This is useful but I'm finding it incomplete because it doesn't make any mention of how to deploy the resulting set of applications.

I have a netfx aspnet mvc5 monolithic application which is hosted on azure web app. When I follow the process to start upgrading and breaking it apart I end up with 3 applications. the Proxy (net8), Legacy (netfx) and Modern (net8) applications. I need requests to come in to the Proxy project and then be routed to the Legacy and Modern projects but I can't find a way to do this without needing additional web apps which will increase costs and deployment complexity.

Can you provide some guidance on how to move into the deployment stages of a migrated upgrade using yarp without using containers please.

@dotnet-policy-service dotnet-policy-service bot added the Needs: Triage 🔍 Label added to new issues which need Triage label Sep 19, 2024
@danroth27
Copy link
Member

Hi @Wraith2. Take a look at the related docs for incremental upgrades here: https://learn.microsoft.com/aspnet/core/migration/inc/overview. With this approach, the YARP proxy is typically hosted in the ASP.NET Core process, not a separate one.

@danroth27 danroth27 added Needs: Author Feedback Issues and PRs that are waiting on the author's response and removed Needs: Triage 🔍 Label added to new issues which need Triage labels Sep 25, 2024
@Wraith2
Copy link
Author

Wraith2 commented Sep 25, 2024

An interesting option. Is it possible to host in another process without additional reasources? I haven't managed to find a way yet. If i mix the proxy and web process together I can't monitor performance of the individual parts in a sensible way, i wouldn't know if the proxy or requests were using resources.

@dotnet-policy-service dotnet-policy-service bot added Needs: Attention 👋 Issues and PRs that the maintainers should take a look at and removed Needs: Author Feedback Issues and PRs that are waiting on the author's response labels Sep 25, 2024
@danroth27
Copy link
Member

Is it possible to host in another process without additional resources? I haven't managed to find a way yet.

The incremental migration approach requires running two separate apps while you're doing the migration. Once the migration is complete, you're left with just the one resource for the migrated app.

If i mix the proxy and web process together I can't monitor performance of the individual parts in a sensible way, i wouldn't know if the proxy or requests were using resources.

The way the incremental migration setup works is that the ASP.NET Core process first handles whatever requests it can, and then anything else gets forwarded by YARP to the original ASP.NET process to handle. So, any requests going to the ASP.NET process are proxied requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Attention 👋 Issues and PRs that the maintainers should take a look at
Projects
None yet
Development

No branches or pull requests

2 participants