- Status: Accepted
- Date: 2024-09-03
- Work Item: 8559 - Takeaway: Determine where to deploy updated Launch Pad and what training is needed
The Launch Pad application is an ASP.NET MVC application using .NET Framework 4.8, hosted on-premises. The application is functioning well, but a new requirement is to make the site multilingual. Given the effort required to implement this feature, we are evaluating whether hosting the updated application in Azure or keeping it on-premises makes sense.
The new requirement (8286 - Ability to Translate the Launch Pad involves supporting English and Spanish for the Launch Pad application. This includes:
- All static content (e.g., labels, messages, and navigation links) is translated into multiple languages.
- Implementing language selection functionality, allowing users to switch languages seamlessly.
- Maintaining a consistent user experience across all supported languages.
- Resource Management: Managing resource files for each language, ensuring they are up-to-date and correctly referenced in the application.
- User Interface Adjustments: Adapting the UI to accommodate different text lengths and reading directions (e.g., right-to-left languages, which is currently out of scope).
- Performance Considerations: Ensuring that adding multilingual support does not negatively impact the application's performance.
- Testing and Quality Assurance: Thoroughly testing the application in all supported languages to ensure accuracy and usability.
- Load Times: Ensuring that the application loads quickly and efficiently.
- Caching: Possibly implementing effective caching strategies to reduce server load and improve response times for frequently accessed content.
- Scalability: Choosing a hosting option that can scale to handle increased traffic and data load as more languages are added.
- Monitoring and Optimization: Continuously monitoring performance metrics and optimizing the application to maintain a high level of performance.
- Needed for multilingual support.
- Effort required for redevelopment or migration.
- Cost implications of hosting options.
- Scalability and future-proofing.
- Management and maintenance overhead.
- Host the Launch Pad app as is (ASP.NET MVC on .NET Framework 4.8) on Azure App Service.
- Host the Launch Pad app as an ASP.NET MVC on Azure Container Apps (requires dockerizing the application).
- Convert the Launch Pad app to a Blazor WASM application and host it on Azure Static Web Apps.
- Convert the Launch Pad app to a static website and host it on Azure Static Web Apps.
- Convert to Blazor WASM and host on Azure App Service.
- Convert to Blazor WASM and host on Azure Container Apps.
- Leave the application hosted on-premises.
The chosen option is to convert the Launch Pad app to a static website and host it on Azure Static Web Apps. This is the simplest and most cost-effective option, offering easy global distribution with integrated CDN and minimal management overhead.
- Good: Simplest and most cost-effective option, easy global distribution with integrated CDN, minimal management overhead.
- Bad: Limited to static content (the current site is only static content)
- Convert the existing ASP.NET MVC application to a static website.
- Host the static website on Azure Static Web Apps.
- Implement multilingual support.
- Adapt the UI to accommodate different text lengths and ensure a consistent user experience.
- Thoroughly test the application in all supported languages to ensure accuracy and usability.
- Regular performance monitoring and optimization.
- User feedback and testing to ensure multilingual support is functioning correctly.
- Architecture Team
- Development Team
- Product Owners (Dev02 and MFG)
- Software Development Management
- Projected Monthly Cost: $73.00; assuming S1 Windows App Service (1 Core, 1.75-GB RAM, 50-Gb storage) in the Azure North Central US region.
- Good, because minimal changes to the existing application.
- Good, because easy deployment and management.
- Good, because supports server-side rendering and complex backend logic.
- Bad, because potentially higher costs compared to static hosting options.
- Bad, because requires ongoing management of the app service environment.
- Projected Cost: Free (includes up to 100-Gb of bandwidth per subscription and 0.5-Gb of storage per app). If more than 100-Gb required, need to go to the Standard tier which is $9/per app/month and then $0.20 per GB over 100-Gb.
- Good, because modern, client-side framework,
- Good, because potentially lower costs and global scalability.
- Good, because integrated API support via Azure Functions.
- Bad, because significant redevelopment effort to convert the application to Blazor WASM.
- Bad, because limited to client-side logic, which may not suit all use cases.
- Bad, because daily download delays for users on thin clients connecting to virtual machines that are rebuilt every evening.
- Projected Cost: Free (includes up to 100-Gb of bandwidth per subscription and 0.5-Gb of storage per app). If more than 100-Gb required, need to go to the Standard tier which is $9/per app/month and then $0.20 per GB over 100-Gb.
- Good, because simplest and most cost-effective option.
- Good, because easy global distribution with integrated CDN.
- Good, because minimal management overhead.
- Bad, because limited to static content.
- Bad, because may not support all current functionalities if server-side logic is needed.
- Projected Monthly Cost: $73.00; assuming S1 Windows App Service (1 Core, 1.75-GB RAM, 50-Gb storage) in the Azure North Central US region.
- Good, because combines the benefits of Blazor WASM with the flexibility of App Service.
- Good, because supports server-side APIs and complex backend logic.
- Good, because easy integration with other Azure services.
- Bad, because requires redevelopment effort to convert to Blazor WASM.
- Bad, because higher costs compared to static hosting options.
- Bad, because daily download delays for users on thin clients connecting to virtual machines that are rebuilt every evening.
- Projected Monthly Cost: $1.60; assuming 600,000 requests (5 requests/day/user) with and average 5 seconds per request. Unsure if the included allotment is per subscription or per application.
- Good, because combines the benefits of Blazor WASM with the flexibility of containerization.
- Good, because serverless infrastructure management.
- Good, because scalability and isolation of application dependencies.
- Bad, because requires redevelopment effort to convert to Blazor WASM.
- Bad, because requires effort to containerize the application.
- Bad, because daily download delays for users on thin clients connecting to virtual machines that are rebuilt every evening.
- Projected Cost: Existing infrastructure costs; but usage will go up and new infrastructure might be required.
- Good, because no changes required to the current setup.
- Good, because full control over the hosting environment.
- Good, because no additional cloud hosting costs.
- Bad, because limited scalability compared to cloud options.
- Bad, because potentially higher maintenance and infrastructure costs.
- Bad, because lack of cloud-native features and integrations.
No more information available"
No follow-on information.
- Proposed: 2024-09-03
- Accepted: 2024-09-03
- Last Reviewed: [Date, if appliable]
- Deprecated: [Date, if applicable]
- Superseded by: [Reference to the ADR that supersedes this one, if applicable]
- Date Superseded: [Date, if applicable]
- Archived: [Date, if applicable]