From 15df5f771ac250b37b7be836fa7a4aae8f33db73 Mon Sep 17 00:00:00 2001 From: Ken Schlobohm Date: Tue, 15 Oct 2024 12:49:07 -0500 Subject: [PATCH 1/6] fix space between character and period --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index e3373e4..4a79027 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ The reference implementation provides a production-grade web application that uses best practices from our guidance and gives developers concrete examples to build their own Modern Web Application in Azure. This repository specifically demonstrates a concert ticketing application for the fictional company Relecloud, embodying the modern web app pattern with a focus on .NET technologies. It guides developers through a simulated migration from an on-premises ASP.NET application to Azure, detailing the architectural changes and enhancements that capitalize on the cloud's strengths during the initial adoption phase. -This project has [a companion article in the Azure Architecture Center](https://aka.ms/eap/mwa/dotnet/doc) that describes design patterns and best practices . Here's an outline of the contents in this readme: +This project has [a companion article in the Azure Architecture Center](https://aka.ms/eap/mwa/dotnet/doc) that describes design patterns and best practices. Here's an outline of the contents in this readme: - [Architecture](#architecture) - [Workflow](#workflow) From f7fbf89ba45de56fe779448f8ed2ae32eafde214 Mon Sep 17 00:00:00 2001 From: Ken Schlobohm Date: Tue, 15 Oct 2024 12:52:18 -0500 Subject: [PATCH 2/6] guide content has moved to AAC --- guide/apply-the-pattern.md | 191 ------------------------------- guide/mwa-overview.md | 11 -- guide/plan-the-implementation.md | 165 -------------------------- 3 files changed, 367 deletions(-) delete mode 100644 guide/apply-the-pattern.md delete mode 100644 guide/mwa-overview.md delete mode 100644 guide/plan-the-implementation.md diff --git a/guide/apply-the-pattern.md b/guide/apply-the-pattern.md deleted file mode 100644 index 5f4d125..0000000 --- a/guide/apply-the-pattern.md +++ /dev/null @@ -1,191 +0,0 @@ -# Modern web app pattern for .NET - Apply the pattern - -The modern web app pattern provides implementation guidance for modernizing web apps (refactor) in the cloud. Modernizing a web in the cloud can be challenging. The number of services and design patterns to choose from is overwhelming. It's hard to know the right ones to choose and how to implement them. The modern web app pattern solves this problem. - -The modern web app pattern is a set of [principles](mwa-overview.md) to guide your web app modernization. The pattern is applicable to almost every web app and provides a roadmap to overcome the obstacles of web app modernization efforts. - -There's a [reference implementation](https://aka.ms/eap/mwa/dotnet) of the modern web app pattern to guide your implementation. The reference implementation is a production-quality web app that you can be easily deploy for learning and experimentation. For context, the guidance follows the journey of a fictional company called Relecloud. - -## Architecture - -The modern web app pattern uses a hub and spoke architecture. Shared resources are the hub virtual network and application endpoints sit in the spoke virtual network. The modern web app pattern is a set of principles, not a specific architecture. The following diagram (*figure 1*) represents the architecture of the reference implementation. It's one example that illustrates the principles of the modern web app pattern. Your business context, existing web app, and desired service level objective (SLO) are factors that shape the specific architecture of your web app. - -![Diagram showing the architecture of the reference implementation.](../assets/images/reliable-web-app-dotnet.svg) -*Figure 1. The architecture of the reference implementation.* - -## Evolutionary design changes - -> ⚠️ Pending task Strangler Fig discussion - (Queue-based ticket rendering experience) covered by #1864681 -> In this section, we describe how the team approached updating the solution without rewriting it as part of the larger conversation for an application that (1) adds new features and (2) is sitting between monolith and microservices. - - -## Reliability - -A modern web application is one that is both resilient and available. Resiliency is the ability of the system to recover from failures and continue to function. The goal of resiliency is to return the application to a fully functioning state after a failure occurs. Availability is a measure of whether your users can access your web application when they need to. You should use the Rate Limiting and Queue-Based Load Leveling patterns as steps toward improving application reliability. These design patterns address high throughput scenarios and help your application maximize the reliability features of the cloud. - -### Queue-Based Load Leveling pattern - -> ⚠️ Pending task Queue-based Load Leveling pattern - (Queue-based ticket rendering experience) covered by #1865952 -> This section will talk about how moving work out of the request processing stream will create more bandwidth for request throughput by reducing long running operations that tie up CPU, RAM, and network connections. Improved request bandwidth provides additional benefits for scaling, and will smooth out edge case scenarios such as a user buying 20 tickets, that can lead to reliability problems as requests become queued during high throughput scenarios. - -### Rate Limiting pattern - -> ⚠️ Pending task Rate Limiting pattern - (Multichannel API Capability experience) covered by #1864671 - - -## Security - -Cloud applications are often composed of multiple Azure services. Communication between those services needs to be secure. Enforcing secure authentication, authorization, and accounting practices in your application is essential to your security posture. At this phase in the cloud journey, you should use managed identities, secrets management, and private endpoints. Here are the security recommendations for the modern web app pattern. - -### Apply Federated Identity pattern for website authentication - -> ⚠️ Pending task Document the way Federated Identity Pattern was applied - (Public facing website experience) covered by #1908023 - -### Secure Azure resources at the identity layer - -> ⚠️ Pending task Document recommended approach for Identity Layer - (Multichannel API Capability experience) covered by #1865959 - -### Secure Azure resources with network isolation - -> ⚠️ Pending task Queue-based Load Leveling Pattern - (Multichannel API Capability experience) covered by #1865959 - - - -## Cost optimization - -> ⚠️ The entire cost optimization section is pending review - (Business reporting experience) covered by #1865960 - -Cost optimization principles balance business goals with budget justification to create a cost-effective web application. Cost optimization is about reducing unnecessary expenses and improving operational efficiency. Here are our recommendations for cost optimization. The code changes optimize for horizontal scale to reduce costs rather than optimizing existing business processes. The latter can lead to higher risks. - -*Reference implementation:* The checkout process in the reference implementation has a hot path of rendering ticket images during request processing. You can isolate the checkout process to improve cost optimization and performance efficiency, but this change is beyond the scope of the modern web app pattern. You should address it in future modernizations. - -### Rightsize resources for each environment - -Production environments need SKUs that meet the service level agreements (SLA), features, and scale needed for production. But non-production environments don't normally need the same capabilities. You can optimize costs in non-production environments by using cheaper SKUs that have lower capacity and SLAs. You should consider Azure Dev/Test pricing and Azure Reservations. How or whether you use these cost-saving methods depends on your environment. - -**Consider Azure Dev/Test pricing.** Azure Dev/Test pricing gives you access to select Azure services for non-production environments at discounted pricing under the Microsoft Customer Agreement. The plan reduces the costs of running and managing applications in development and testing environments, across a range of Microsoft products. For more information, see [Dev/Test pricing options](https://azure.microsoft.com/pricing/dev-test/#overview). - -**Consider Azure Reservations or an Azure savings plan.** You can combine an Azure savings plan with Azure Reservations to optimize compute cost and flexibility. Azure Reservations help you save by committing to one-year or three-year plans for multiple products. The Azure savings plan for compute is the most flexible savings plan. It generates savings on pay-as-you-go prices. Pick a one-year or three-year commitment for compute services, regardless of region, instance size, or operating system. Eligible compute services include virtual machines, dedicated hosts, container instances, Azure Functions Premium, and Azure app services. For more information, see [Azure Reservations](https://learn.microsoft.com/azure/cost-management-billing/reservations/save-compute-costs-reservations) and [Azure savings plans for compute](https://learn.microsoft.com/azure/cost-management-billing/savings-plan/savings-plan-compute-overview). - -*Reference implementation:* The reference implementation uses Bicep parameters to trigger resource deployment configurations. One of these parameters tells Azure Resource Manager which SKUs to select. The following code gives Azure Cache for Redis different SKUs for production and non-production environments: - -> ⚠️ Pending review of code sample - (Business reporting experience) covered by #1865960 -```bicep -var redisCacheSkuName = isProd ? 'Standard' : 'Basic' -var redisCacheFamilyName = isProd ? 'C' : 'C' -var redisCacheCapacity = isProd ? 1 : 0 -``` - -The web app uses the Standard C1 SKU for the production environment and the Basic C0 SKU for the non-production environment. The Basic C0 SKU costs less than the Standard C1 SKU. It provides the behavior needed for testing without the data capacity or availability targets needed for the production environment (see following table). For more information, see [Azure Cache for Redis pricing](https://azure.microsoft.com/pricing/details/cache/). - -*Table 2. Reference implementation SKU differences between the development and production environments.* - -> ⚠️ Pending review of SKU - (Business reporting experience) covered by #1865960 - -| | Standard C1 SKU | Basic C0 SKU| -| --- | --- | --- | -|**SKU Features**| 1-GB cache
Dedicated service
Availability SLA
As many as 1,000 connections |250-MB cache
Shared infrastructure
No SLA
As many as 256 connections - -### Automate scaling the environment - -You should use autoscale to automate horizontal scaling for production environments. Autoscaling adapts to user demand to save you money. Horizontal scaling automatically increases compute capacity to meet user demand and decreases compute capacity when demand drops. Don't increase the size of your application platform (vertical scaling) to meet frequent changes in demand. It's less cost efficient. For more information, see [Scaling in Azure App Service](https://learn.microsoft.com/azure/app-service/manage-scale-up) and [Autoscale in Microsoft Azure](https://learn.microsoft.com/azure/azure-monitor/autoscale/autoscale-overview). - -*Reference implementation:* The reference implementation uses the following configuration in the Bicep template. It creates an autoscale rule for the Azure App Service. The rule scales up to 10 instances and defaults to one instance. - -```csharp -resource webAppScaleRule 'Microsoft.Insights/autoscalesettings@2021-05-01-preview' = if (isProd) { - name: '${resourceToken}-web-plan-autoscale' - location: location - properties: { - targetResourceUri: webAppServicePlan.id - enabled: true - profiles: [ - { - name: 'Auto scale from one to ten' - capacity: { - maximum: '10' - default: '1' - minimum: '1' - } - rules: [ - ... - ] - } - ] - } -} -``` - -### Delete non-production environments - -Infrastructure as Code (IaC) is often considered an operational best practice, but it's also a way to manage costs. IaC can create and delete entire environments. You should delete non-production environments after hours or during holidays to optimize cost. - -### Leverage and reuse resources for shared responsibilities - -> ⚠️Pending documentation associated with - (Multichannel API Capability experience) covered by #1908512 -> In this section of the guide we would discuss the shared resources in the solution. The decision criteria that were considered and the associated cost savings from having consolidated services and the reduced operational costs associated with management and monitoring a single resource. - - -## Operational excellence - -A DevOps methodology provides a greater return on investment for application teams in the cloud. IaC is a key tenet of DevOps. The modern web app pattern requires the use of IaC to deploy application infrastructure, configure services, and set up application telemetry. Monitoring operational health requires telemetry to measure security, cost, reliability, and performance gains. The cloud offers built-in features to capture telemetry. When this telemetry is fed into a DevOps framework, it can help you rapidly improve your application. - -### Gateway Routing pattern - -> ⚠️ Pending implementation and documentation associated with - (Multichannel API Capability experience) covered by #1864679 - -### Distributed tracing and logging - -> ⚠️ Pending implementation and documentation associated with - (Business Reporting experience) covered by #1865961 - -### Load testing - -> ⚠️ Pending implementation and documentation associated with - (Load testing the API experience) covered by #1865967 - - - -## Performance efficiency - -Performance efficiency is the ability of a workload to scale and meet the demands placed on it by users in an efficient manner. In cloud environments, a workload should anticipate increases in demand to meet business requirements. You should use the Cache-Aside pattern to manage application data while improving performance and optimizing costs. - -### Apply the Backends for Frontends pattern - -> ⚠️ Pending documentation of Backends for Frontends pattern - (Public facing website experience) covered by #1865974 - -### Use the Cache-Aside pattern - -> ⚠️ Pending documentation of infrastructure cache replaces code cache - (Multichannel API Capability experience) covered by #1865950 - -### Queue-based Load Leveling pattern - -> ⚠️ Pending task Queue-based Load Leveling pattern - (Queue-based ticket rendering experience) covered by #1865952 -> This section will talk about how applying the Queue-based Load leveling pattern changes our scaling paradigm so that we no longer need to plan for peak workloads. Autoscaling provides alignment with user load and Queue-based Load Leveling provides additional smoothing of the resource demands for our solution. This reduces waste by reducing scaling events and helping us plan for our expected consumption in a more consistent approach. - -![Diagram that shows the abstraction choices and their impacts on system costs.](../assets/images/choice-of-abstraction.png) - -- Learn more by reading about [Consumption and fixed cost models](https://learn.microsoft.com/azure/well-architected/cost/design-price) - -## Next steps - -You can deploy the reference implementation by following the instructions in the [modern web app pattern for .NET repository](https://aka.ms/eap/mwa/dotnet). The repository has everything you need. Follow the deployment guidelines to deploy the code to Azure and local development. The following resources can help you learn cloud best practices, discover migration tools, and learn about .NET. - -**Introduction to web apps on Azure.** For a hands-on introduction to .NET web applications on Azure, see this [guidance for deploying a basic .NET web application](https://github.com/Azure-Samples/app-templates-dotnet-azuresql-appservice). - -**Cloud best practices.** For Azure adoption and architectural guidance, see: - -- [Cloud Adoption Framework](https://learn.microsoft.com/azure/cloud-adoption-framework/overview). Can help your organization prepare and execute a strategy to build solutions on Azure. -- [Well-Architected Framework](https://learn.microsoft.com/azure/architecture/framework/). A set of guiding tenets that can be used to improve the quality of a workload. - -For applications that require a higher SLO than the modern web app pattern, see [mission-critical workloads](https://learn.microsoft.com/azure/architecture/framework/mission-critical/mission-critical-overview). - -**Migration guidance.** The following tools and resources can help you migrate on-premises resources to Azure. - -- [Azure Migrate](https://learn.microsoft.com/azure/migrate/migrate-services-overview) provides a simplified migration, modernization, and optimization service for Azure that handles assessment and migration of web apps, SQL Server, and virtual machines. -- [Azure Database Migration Guides](https://learn.microsoft.com/data-migration/) provides resources for different database types, and different tools designed for your migration scenario. -- [Azure App Service landing zone accelerator](https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/app-platform/app-services/landing-zone-accelerator) provides guidance for hardening and scaling App Service deployments. - -**Upgrading .NET Framework applications.** The reference implementation deploys to an App Service that runs Windows, but it can run on Linux. The App Service Windows platform enables you to move .NET Framework web apps to Azure without upgrading to newer framework versions. For information about Linux App Service plans or new features and performance improvements added to the latest versions of .NET, see the following guidance. - -- [Overview of porting from .NET Framework to .NET](https://learn.microsoft.com/dotnet/core/porting/). Get guidance based on your specific type of .NET app. -- [Overview of the .NET Upgrade Assistant](https://learn.microsoft.com/dotnet/core/porting/upgrade-assistant-overview). Learn about a console tool that can help you automate many of the tasks associated with upgrading .NET Framework projects. -- [Migrating from ASP.NET to ASP.NET Core in Visual Studio](https://devblogs.microsoft.com/dotnet/introducing-project-migrations-visual-studio-extension/). Learn about a Visual Studio extension that can help you with incremental migrations of web apps. diff --git a/guide/mwa-overview.md b/guide/mwa-overview.md deleted file mode 100644 index 7aee4cb..0000000 --- a/guide/mwa-overview.md +++ /dev/null @@ -1,11 +0,0 @@ - -This guide demonstrates how principles from the [Well-Architected Framework](https://docs.microsoft.com/azure/architecture/framework/) -and [Twelve-Factor Applications](https://12factor.net/) can be applied to migrate and modernize a legacy, line-of-business (LOB) web app to the cloud. The following table lists the principles of the modern web app pattern and how to implement those principles in your web app. For more information, see the [Modern web app pattern overview](https://aka.ms/eap/mwa/dotnet/doc). - -The following table lists the principles of the modern web app pattern and how to implement those principles in your web app. For more information, see the [Modern web app pattern overview](https://aka.ms/eap/mwa/dotnet/doc). - -*Table 1. Pattern principles and how to implement them.* - -| Modern web app pattern principles | How to implement the principles | -| --- | --- | -| *Modern web app pattern principles:*
▪ Mature dev team practices for modern development
     ▪ Accelerate feature development with vertical slice development
     ▪ Evolutionary design changes instead of re-write
▪ Managed services
▪ Focused on vertical slice development to support
     ▪ Non-functional requirements
     ▪ Parallel workstream opportunities

*Well Architected Framework principles:*
▪ Cost optimized
▪ Observable
▪ Ingress secure
▪ Infrastructure as code
▪ Identity-centric security|▪ Backends for Frontends pattern
▪ Cache-aside pattern
▪ Federated Identity pattern
▪ Queue-Based Load Leveling pattern
▪ Gateway Routing pattern
▪ Rate Limiting pattern
▪ Strangler Fig pattern
▪ Rightsized resources
▪ Managed identities
▪ Private endpoints
▪ Secrets management
▪ Bicep deployment
▪ Telemetry, logging, monitoring | \ No newline at end of file diff --git a/guide/plan-the-implementation.md b/guide/plan-the-implementation.md deleted file mode 100644 index c0e5f58..0000000 --- a/guide/plan-the-implementation.md +++ /dev/null @@ -1,165 +0,0 @@ -# Modern web app pattern for .NET - Plan the implementation - -The modern web app pattern provides implementation guidance for modernizing web apps (refactor) in the cloud. Modernizing a web in the cloud can be challenging. The number of services and design patterns to choose from can be overwhelming. It's hard to know the right ones to choose and how to implement them. The modern web app pattern solves this problem. - -The modern web app pattern is a set of [principles](mwa-overview.md) to guide your web app modernization. The pattern is applicable to almost every web app and provides a roadmap to overcome the obstacles of web app modernization efforts. - -There's a [reference implementation](https://aka.ms/eap/mwa/dotnet) of the modern web app pattern to guide your implementation. The reference implementation is a production-quality web app that you can be easily deploy for learning and experimentation. For context, the guidance follows the journey of a fictional company called Relecloud. - -## Architecture - -The modern web app pattern uses a hub and spoke architecture. Shared resources are the hub virtual network and application endpoints sit in the spoke virtual network. The modern web app pattern is a set of principles, not a specific architecture. The following diagram (*figure 1*) represents the production architecture of the reference implementation. It's one example that illustrates the principles of the modern web app pattern. Your business context, existing web app, and desired service level objective (SLO) are factors that shape the specific architecture of your web app. - -![Diagram showing the production architecture for the reference implementation.](../assets/images/reliable-web-app-dotnet.svg) - -## Business context - -> ⚠️ The business scenario section is pending review - (Multichannel API Capability experience) covered by #1865953 - -For business context, the guidance follows the cloud journey of a fictional company called Relecloud. Relecloud sells concert tickets. Their website is currently used by call center operators to buy tickets on behalf of their offline (telephone) customers. Relecloud has experienced increased sales volume over the last quarter with continued increases projected, and senior leadership has decided to invest more in direct customer sales online instead of expanding call center capacity. - -*Table 2. Relecloud's short-term and long-term goals.* -|Short-term goals|Long-term goals| -| --- | --- | -|- Open the application directly to online customers
- Have multiple web and mobile experiences
- Improve availability
- Independently scale different components
- Maintain security posture
| - Reduce feature development time - -## Existing web app - -> ⚠️ The existing web app section is pending review - (Multichannel API Capability experience) covered by #1865953 - -The existing web app was an on-premises web app migrated to the cloud with the [Reliable Web App pattern](https://aka.ms/eap/rwa/dotnet/doc). The web app is a monolithic ASP.NET web app. It runs an eCommerce, line-of-business web app on two App Service Plans and has a Azure SQL database. The web app is employee-facing. The only application users are Relecloud's call center employees. Relecloud employees use the application to buy tickets on behalf of Relecloud customers. The on-premises web app suffers from common challenges. These challenges include extended timelines to build and ship new features difficulty scaling different components of the application under a higher load. - -## Service level objective - -> ⚠️ The service level objective section is pending review - (Multichannel API Capability experience) covered by #1865953 - -A service level objective (SLO) for availability defines how available you want a web app to be for users. You need to define an SLO and what *available* means for your web app. For example, Relecloud has a target SLO of 99.9% for availability, about 8.7 hours of downtime per year. The definition of *available* for Relecloud is when its call center employees can purchase tickets 99.9% of the time. When you have a definition of *available* for your web app, the next step is to define the critical path of availability. List any dependency that needs to be running for you to meet the web app's definition of *available*. Dependencies should include Azure services and third-party integrations. - -For each dependency in the critical path, you need to assign an availability goal. Service level agreements (SLAs) from Azure provide a good starting point. However, SLAs don't factor in (1) downtime that's associated with the application code running on the services (2) deployment and operation methodologies, (3) architecture choices to connect the services. The availability metric you assign to a dependency shouldn't exceed the SLA. - -Relecloud used Azure SLAs for Azure services. The following diagram illustrates Relecloud's dependency list with availability goals for each dependency (*see figure 2*). - -## Choose the right services - -> ⚠️ The Choose the right services section, and the addition of new Azure services introduced for MWA, is pending review - (Multichannel API Capability experience) covered by #1865953 - -The Azure services you choose should support your short-term and and long-term goals. To accomplish both, you should pick services that (1) meet your immediate business context, (2) SLO requirements, and (3) support future modernization plans. - -### Application platform - -[Azure App Service](https://learn.microsoft.com/azure/app-service/overview) is an HTTP-based, managed service for hosting web apps, REST APIs, and mobile back ends. Relecloud chose Azure App Service because it meets the following requirements: - -- **High SLA.** It has a high SLA that meets the production environment SLO. -- **Reduced management overhead.** It's a fully managed solution that handles scaling, health checks, and load balancing. -- **.NET support.** It supports the version of .NET that the application is written in. -- **Autoscaling.** The web app can automatically scale up, down, in, and out based on user traffic and settings. - -Requirements | Azure App Service | Azure Container Apps | -| --- | --- | --- | -| High SLA | ✅ | ✅ | -| Fully-managed | ✅ | ✅ | -| .NET support | ✅ | ✅ | -| Container support | ✅ | ✅ | -| Autoscaling | ✅ | ✅ | -| Current platform | ✅ | | - -For more information, see [Azure compute decision tree](https://learn.microsoft.com/azure/architecture/guide/technology-choices/compute-decision-tree). - -### Identity management - -[Microsoft Entra ID](https://learn.microsoft.com/azure/active-directory/fundamentals/active-directory-whatis) is a cloud-based identity and access management service. It authenticates and authorizes users based on roles that integrate with our application. Microsoft Entra ID provides the application with the following abilities: - -- **Authentication and authorization.** The application needs to authenticate and authorize call center employees. -- **Scalable.** It scales to support larger scenarios. -- **User-identity control.** Call center employees can use their existing enterprise identities. -- **Support authorization protocols.** It supports OAuth 2.0 for managed identities and OpenID Connect for future B2C support. - -### Database - -[Azure SQL Database](https://learn.microsoft.com/azure/azure-sql/azure-sql-iaas-vs-paas-what-is-overview?view=azuresql) is a general-purpose relational database and managed service in that supports relational and spatial data, JSON, spatial, and XML. The web app uses Azure SQL Database because it meets the following requirements: - -- **Reliability.** The general-purpose tier provides a high SLA and multi-region redundancy. It can support a high user load. -- **Reduced management overhead.** It provides a managed SQL database instance. -- **Configuration consistency.** It supports the existing stored procedures, functions, and views. -- **Resiliency.** It supports backups and point-in-time restore. -- **Expertise and minimal rework.** SQL Database takes advantage of in-house expertise and requires minimal rework. - -### Application performance monitoring - -[Application Insights](https://learn.microsoft.com/azure/azure-monitor/app/app-insights-overview) is a feature of Azure Monitor that provides extensible application performance management (APM) and monitoring for live web apps. The web app uses Application Insights for the following reasons: - -- **Anomaly detection.** It automatically detects performance anomalies. -- **Troubleshooting.** It helps you diagnose problems in the running app. -- **Telemetry.** It collects information about how users are using the app and allows you to easily track custom events. - -Azure Monitor is a comprehensive suite of monitoring tools that collect data from various Azure services. For more information, see: - -- [Smart detection in Application Insights](https://learn.microsoft.com/azure/azure-monitor/alerts/proactive-diagnostics) -- [Application Map: Triage distributed applications](https://learn.microsoft.com/azure/azure-monitor/app/app-map?tabs=net) -- [Profile live App Service apps with Application Insights](https://learn.microsoft.com/azure/azure-monitor/profiler/profiler) -- [Usage analysis with Application Insights](https://learn.microsoft.com/azure/azure-monitor/app/usage-overview) -- [Get started with metrics explorer](https://learn.microsoft.com/azure/azure-monitor/essentials/metrics-getting-started) -- [Application Insights Overview dashboard](https://learn.microsoft.com/azure/azure-monitor/app/overview-dashboard) -- [Log queries in Azure Monitor](https://learn.microsoft.com/azure/azure-monitor/logs/log-query-overview) - -### Cache - -[Azure Cache for Redis](https://learn.microsoft.com/azure/azure-cache-for-redis/cache-overview) is a managed in-memory data store based on the Redis software. The web app's load is heavily skewed toward viewing concerts and venue details. It needs a cache that provides the following benefits: - -- **Reduced management overhead.** It's a fully-managed service. -- **Speed and volume.** It has high-data throughput and low latency reads for commonly accessed, slow changing data. -- **Diverse supportability.** It's a unified cache location for all instances of the web app to use. -- **Externalized.** The on-premises application servers performed VM-local caching. This setup didn't offload highly frequented data, and it couldn't invalidate data. -- **Non-sticky sessions.** Externalizing session state supports nonsticky sessions. - -### Global load balancer - -[Azure Front Door](https://learn.microsoft.com/azure/frontdoor/front-door-overview) is a layer-7 global load balancer that uses the Azure backbone network to route traffic between regions. Relecloud uses Azure Front Door because it provides the following benefits: - -- **Cross-region routing.** Front Door provides layer-7 routing between regions. Relecloud needed to a multi-region architecture to meet their 99.9% SLO. -- **Content delivery network.** Front Door positions Relecloud to use a content delivery network. The content delivery network provides site acceleration as the traffic to the web app increases. -- **Routing flexibility.** It allows the application team to configure ingress needs to support future changes in the application. -- **Traffic acceleration.** It uses anycast to reach the nearest Azure point of presence and find the fastest route to the web app. -- **Custom domains.** It supports custom domain names with flexible domain validation. -- **Health probes.** The application needs intelligent health probe monitoring. Azure Front Door uses responses from the probe to determine the best origin for routing client requests. -- **Monitoring support.** It supports built-in reports with an all-in-one dashboard for both Front Door and security patterns. You can configure alerts that integrate with Azure Monitor. It lets the application log each request and failed health probes. -- **Web application firewall.** Front Door integrates natively with Azure Web Application Firewall. -- **DDoS protection.** It has built-in layer 3-4 DDoS protection. - -Azure has several load balancers. Evaluate your current system capabilities and the requirements for the new app running on Azure, and then [choose the best load balancer for your app](https://learn.microsoft.com/azure/architecture/guide/technology-choices/load-balancing-overview). - -### Web Application Firewall - -[Azure Web Application Firewall](https://learn.microsoft.com/azure/web-application-firewall/overview) helps provide centralized protection of your web apps from common exploits and vulnerabilities. It's built into Azure Front Door and helps prevent malicious attacks close to the attack sources before they enter your virtual network. Web Application Firewall provides the following benefits: - -- **Global protection.** It provides improved global web app protection without sacrificing performance. -- **Botnet protection.** The team can monitor and configure to address security concerns from botnets. - -### Configuration storage - -[Azure App Configuration](https://learn.microsoft.com/azure/azure-app-configuration/overview) is a service for centrally managing application settings and feature flags. App Config provides the following benefits: - -- **Flexibility.** It supports feature flags. Feature flags allow users to opt in and out of early preview features in a production environment without redeploying the app. -- **Supports Git pipeline.** The source of truth for configuration data needed to be a Git repository. The pipeline needed to update the data in the central configuration store. -- **Supports managed identities.** It supports managed identities to simplify and help secure the connection to the configuration store. - -Review [App Configuration best practices](https://learn.microsoft.com/azure/azure-app-configuration/howto-best-practices#app-configuration-bootstrap) to decide whether this service is a good fit for your app. - -### Secrets manager - -[Azure Key Vault](https://learn.microsoft.com/azure/key-vault/general/overview) provides centralized storage of application secrets to control their distribution. The web app uses Key Vault because it provides the following features: - -- **Encryption.** It supports encryption at rest and in transit. -- **Managed identities.** The application services can use managed identities to access the secret store. -- **Monitoring and logging.** It facilitates audit access and generates alerts when stored secrets change. -- **Certificate support.** It supports importing PFX and PEM certificates. -- **Integration.** It provides native integration with the Azure configuration store (App Configuration) and web hosting platform (App Service). - -You can incorporate Key Vault in .NET apps by using the [ConfigurationBuilder object](https://learn.microsoft.com/azure/azure-app-configuration/quickstart-dotnet-core-app). - -### Endpoint security - -[Azure Private Link](https://learn.microsoft.com/azure/private-link/private-link-overview) provides access to PaaS services (such as Azure Cache for Redis and SQL Database) over a private endpoint in your virtual network. Traffic between your virtual network and the service travels across the Microsoft backbone network. The web app uses Private Link for these reasons: - -- **Enhanced security communication.** It lets the application privately access services on the Azure platform and reduces the network footprint of data stores to help protect against data leakage. -- **Minimal effort.** The private endpoints support the web app platform and database platform the web app uses. From bad05ba0de3b21b75baf4b48338faf4a5367f1c9 Mon Sep 17 00:00:00 2001 From: Ken Schlobohm Date: Tue, 15 Oct 2024 12:53:19 -0500 Subject: [PATCH 3/6] consistent reference to pattern name --- README.md | 4 ++-- infra/main.bicep | 2 +- prod-deployment.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 4a79027..41e0966 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ -# Modern web app pattern for .NET +# Modern Web App pattern for .NET -The reference implementation provides a production-grade web application that uses best practices from our guidance and gives developers concrete examples to build their own Modern Web Application in Azure. This repository specifically demonstrates a concert ticketing application for the fictional company Relecloud, embodying the modern web app pattern with a focus on .NET technologies. It guides developers through a simulated migration from an on-premises ASP.NET application to Azure, detailing the architectural changes and enhancements that capitalize on the cloud's strengths during the initial adoption phase. +The reference implementation provides a production-grade web application that uses best practices from our guidance and gives developers concrete examples to build their own Modern Web App in Azure. This repository specifically demonstrates a concert ticketing application for the fictional company Relecloud, embodying the Modern Web App pattern with a focus on .NET technologies. It guides developers through a simulated migration from an on-premises ASP.NET application to Azure, detailing the architectural changes and enhancements that capitalize on the cloud's strengths during the initial adoption phase. This project has [a companion article in the Azure Architecture Center](https://aka.ms/eap/mwa/dotnet/doc) that describes design patterns and best practices. Here's an outline of the contents in this readme: diff --git a/infra/main.bicep b/infra/main.bicep index 9130bb3..85a58d7 100644 --- a/infra/main.bicep +++ b/infra/main.bicep @@ -2,7 +2,7 @@ targetScope = 'subscription' // ======================================================================== // -// Relecloud Scenario of the Modern Web Application (MWA) +// Relecloud Scenario of the Modern Web App (MWA) // Infrastructure description // Copyright (C) 2023 Microsoft, Inc. // diff --git a/prod-deployment.md b/prod-deployment.md index 69320c6..39a99e0 100644 --- a/prod-deployment.md +++ b/prod-deployment.md @@ -1,5 +1,5 @@ # Steps to deploy the production deployment -This section describes the deployment steps for the reference implementation of a modern web application pattern with .NET on Microsoft Azure. These steps guide you through using the jump box that is deployed when performing a network isolated deployment because access to resources will be restricted from public network access and must be performed from a machine connected to the vnet. +This section describes the deployment steps for the reference implementation of a Modern Web App pattern with .NET on Microsoft Azure. These steps guide you through using the jump box that is deployed when performing a network isolated deployment because access to resources will be restricted from public network access and must be performed from a machine connected to the vnet. ![Diagram showing the network focused architecture of the reference implementation.](./assets/images/mwa-architecture.png) From 82f84ccefc7c827bb2ef196fcdc04289e4a3716b Mon Sep 17 00:00:00 2001 From: Ken Schlobohm Date: Wed, 16 Oct 2024 20:24:18 +0000 Subject: [PATCH 4/6] add troubleshooting step --- troubleshooting.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/troubleshooting.md b/troubleshooting.md index 9b0cf4e..d018b17 100644 --- a/troubleshooting.md +++ b/troubleshooting.md @@ -97,4 +97,20 @@ When the `azd provision` command runs it creates a deployment resource in your s az deployment sub delete -n ``` -1. You should now be able to run the `azd provision` command and resume your deployment. \ No newline at end of file +1. You should now be able to run the `azd provision` command and resume your deployment. + +## ERROR: resolving bicep parameters file: fetching current principal id: getting tenant id for subscription... +This error can happen when you are using an account that has access to multiple subscriptions. The `azd auth` command is not able to retrieve a list of the subscriptions that you can access when that tenant is configured to require a Multi-Factor Auth experience that was not completed. + +### Workaround +You should complete the MFA experience for your default tenant, and the tenant that you wish to access by running both authentication commands: + +1. Authenticate to your default tenant + ```sh + azd auth login --use-device-code + ``` + +1. Authenticate to the tenant that owns the subscription you want to use + ```sh + azd auth login --use-device-code --tenant + ``` \ No newline at end of file From 94bdf23e4ae1933a034db683c5a92b380d47f171 Mon Sep 17 00:00:00 2001 From: Ken Schlobohm Date: Wed, 16 Oct 2024 20:36:24 +0000 Subject: [PATCH 5/6] add troubleshooting steps for mfa auth --- troubleshooting.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/troubleshooting.md b/troubleshooting.md index d018b17..a8d3f3a 100644 --- a/troubleshooting.md +++ b/troubleshooting.md @@ -99,9 +99,17 @@ When the `azd provision` command runs it creates a deployment resource in your s 1. You should now be able to run the `azd provision` command and resume your deployment. -## ERROR: resolving bicep parameters file: fetching current principal id: getting tenant id for subscription... +## ERROR: reauthentication required, run `azd auth login --scope https://management.azure.com//.default` to log in This error can happen when you are using an account that has access to multiple subscriptions. The `azd auth` command is not able to retrieve a list of the subscriptions that you can access when that tenant is configured to require a Multi-Factor Auth experience that was not completed. +**Alternate error message text** + +Depending on your workflow you may get a different error message for the same issue: + +```sh +ERROR: resolving bicep parameters file: fetching current principal id: getting tenant id for subscription... +``` + ### Workaround You should complete the MFA experience for your default tenant, and the tenant that you wish to access by running both authentication commands: From ac36de9fa54d08dec542e7cdaea0f09d6d492715 Mon Sep 17 00:00:00 2001 From: Ken Schlobohm Date: Wed, 16 Oct 2024 21:51:30 +0000 Subject: [PATCH 6/6] replace diagram --- prod-deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/prod-deployment.md b/prod-deployment.md index 39a99e0..f30131e 100644 --- a/prod-deployment.md +++ b/prod-deployment.md @@ -1,7 +1,7 @@ # Steps to deploy the production deployment This section describes the deployment steps for the reference implementation of a Modern Web App pattern with .NET on Microsoft Azure. These steps guide you through using the jump box that is deployed when performing a network isolated deployment because access to resources will be restricted from public network access and must be performed from a machine connected to the vnet. -![Diagram showing the network focused architecture of the reference implementation.](./assets/images/mwa-architecture.png) +![Diagram showing the architecture of the MWA implementation.](./assets/icons/modern-web-app-dotnet.svg) ## Prerequisites