From 5395216ab65e2dd858aceaf1bd0afb8f1e7a492d Mon Sep 17 00:00:00 2001 From: Mike Wasson Date: Wed, 11 Apr 2018 13:34:52 -0700 Subject: [PATCH 1/2] Remove outdated 'preview' label from some GA services --- docs/aws-professional/index.md | 4 ++-- docs/resiliency/index.md | 4 ++-- docs/resiliency/recovery-data-corruption.md | 2 +- docs/service-fabric/migrate-from-cloud-services.md | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/aws-professional/index.md b/docs/aws-professional/index.md index 52b1ab6ca26..90448182da4 100644 --- a/docs/aws-professional/index.md +++ b/docs/aws-professional/index.md @@ -175,7 +175,7 @@ The following table summarizes each option. | Scope of failure | Rack | Datacenter | Region | | Request routing | Load Balancer | Cross-zone Load Balancer | Traffic Manager | | Network latency | Very low | Low | Mid to high | -| Virtual networking | VNet | VNet | Cross-region VNet peering (preview) | +| Virtual networking | VNet | VNet | Cross-region VNet peering | ### Availability sets @@ -188,7 +188,7 @@ for the front-end, application, and data tiers. ![Azure availability sets for each application role](./images/three-tier-example.png "Availability sets for each application role") -### Availability zones (preview) +### Availability zones An [Availability Zone](/azure/availability-zones/az-overview) is a physically separate zone within an Azure region. Each Availability Zone has a distinct power source, network, and cooling. Deploying VMs across availability zones helps to protect an application against datacenter-wide failures. diff --git a/docs/resiliency/index.md b/docs/resiliency/index.md index 027df71a025..ff52842e806 100644 --- a/docs/resiliency/index.md +++ b/docs/resiliency/index.md @@ -149,7 +149,7 @@ Azure has a number of features to make an application redundant at every level o **Availability sets**. To protect against localized hardware failures, such as a disk or network switch failing, deploy two or more VMs in an availability set. An availability set consists of two or more *fault domains* that share a common power source and network switch. VMs in an availability set are distributed across the fault domains, so if a hardware failure affects one fault domain, network traffic can still be routed the VMs in the other fault domains. For more information about Availability Sets, see [Manage the availability of Windows virtual machines in Azure](/azure/virtual-machines/windows/manage-availability). -**Availability zones (preview)**. An Availability Zone is a physically separate zone within an Azure region. Each Availability Zone has a distinct power source, network, and cooling. Deploying VMs across availability zones helps to protect an application against datacenter-wide failures. +**Availability zones**. An Availability Zone is a physically separate zone within an Azure region. Each Availability Zone has a distinct power source, network, and cooling. Deploying VMs across availability zones helps to protect an application against datacenter-wide failures. **Paired regions**. To protect an application against a regional outage, you can deploy the application across multiple regions, using Azure Traffic Manager to distribute internet traffic to the different regions. Each Azure region is paired with another region. Together, these form a [regional pair](/azure/best-practices-availability-paired-regions). With the exception of Brazil South, regional pairs are located within the same geography in order to meet data residency requirements for tax and law enforcement jurisdiction purposes. @@ -160,7 +160,7 @@ When you design a multi-region application, take into account that network laten | Scope of failure | Rack | Datacenter | Region | | Request routing | Load Balancer | Cross-zone Load Balancer | Traffic Manager | | Network latency | Very low | Low | Mid to high | -| Virtual network | VNet | VNet | Cross-region VNet peering (preview) | +| Virtual network | VNet | VNet | Cross-region VNet peering | ## Designing for resiliency During the design phase, you should perform a failure mode analysis (FMA). The goal of an FMA is to identify possible points of failure, and define how the application will respond to those failures. diff --git a/docs/resiliency/recovery-data-corruption.md b/docs/resiliency/recovery-data-corruption.md index 39e8ada69d8..ab47f1da9d8 100644 --- a/docs/resiliency/recovery-data-corruption.md +++ b/docs/resiliency/recovery-data-corruption.md @@ -19,7 +19,7 @@ Azure Storage provides data resiliency through automated replicas. However, this - **Block blobs**. Create a point-in-time snapshot of each block blob. For more information, see [Creating a Snapshot of a Blob](/rest/api/storageservices/creating-a-snapshot-of-a-blob). For each snapshot, you are only charged for the storage required to store the differences within the blob since the last snapshot state. The snapshots are dependent on the existence of the original blob they are based on, so a copy operation to another blob or even another storage account is advisable. This ensures that backup data is properly protected against accidental deletion. You can use [AzCopy](/azure/storage/common/storage-use-azcopy) or [Azure PowerShell](/azure/storage/common/storage-powershell-guide-full) to copy the blobs to another storage account. -- **Files**. Use [share snapshots (preview)](/azure/storage/files/storage-how-to-use-files-snapshots), or use AzCopy or PowerShell to copy your files to another storage account. +- **Files**. Use [share snapshots](/azure/storage/files/storage-snapshots-files), or use AzCopy or PowerShell to copy your files to another storage account. - **Tables**. Use AzCopy to export the table data into another storage account in another region. diff --git a/docs/service-fabric/migrate-from-cloud-services.md b/docs/service-fabric/migrate-from-cloud-services.md index 59ecbe58636..50ca2a28355 100644 --- a/docs/service-fabric/migrate-from-cloud-services.md +++ b/docs/service-fabric/migrate-from-cloud-services.md @@ -136,9 +136,9 @@ The original Surveys application uses ASP.NET MVC. Because ASP.NET MVC cannot be - Port the web roles to ASP.NET Core, which can be self-hosted. - Convert the web site into a single-page application (SPA) that calls a web API implemented using ASP.NET Web API. This would have required a complete redesign of the web front end. -- Keep the existing ASP.NET MVC code and deploy IIS in a Windows Server container to Service Fabric. This approach would require little or no code change. However, [container support][sf-containers] in Service Fabric is currently still in preview. +- Keep the existing ASP.NET MVC code and deploy IIS in a Windows Server container to Service Fabric. This approach would require little or no code change. -Based on these considerations, we selected the first option, porting to ASP.NET Core. To do so, we followed the steps described in [Migrating From ASP.NET MVC to ASP.NET Core MVC][aspnet-migration]. +The first option, porting to ASP.NET Core, allowed us to take advantage of the latest features in ASP.NET Core without doing a complete redesign of the we front end. To do the conversion, we followed the steps described in [Migrating From ASP.NET MVC to ASP.NET Core MVC][aspnet-migration]. > [!NOTE] > When using ASP.NET Core with Kestrel, you should place a reverse proxy in front of Kestrel to handle traffic from the Internet, for security reasons. For more information, see [Kestrel web server implementation in ASP.NET Core][kestrel]. The section [Deploying the application](#deploying-the-application) describes a recommended Azure deployment. From 87ffff901e8c5458c7e829949b5fe963097318ef Mon Sep 17 00:00:00 2001 From: Mike Wasson Date: Wed, 11 Apr 2018 13:38:28 -0700 Subject: [PATCH 2/2] edit --- docs/service-fabric/migrate-from-cloud-services.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/service-fabric/migrate-from-cloud-services.md b/docs/service-fabric/migrate-from-cloud-services.md index 50ca2a28355..8d87253be45 100644 --- a/docs/service-fabric/migrate-from-cloud-services.md +++ b/docs/service-fabric/migrate-from-cloud-services.md @@ -138,7 +138,7 @@ The original Surveys application uses ASP.NET MVC. Because ASP.NET MVC cannot be - Convert the web site into a single-page application (SPA) that calls a web API implemented using ASP.NET Web API. This would have required a complete redesign of the web front end. - Keep the existing ASP.NET MVC code and deploy IIS in a Windows Server container to Service Fabric. This approach would require little or no code change. -The first option, porting to ASP.NET Core, allowed us to take advantage of the latest features in ASP.NET Core without doing a complete redesign of the we front end. To do the conversion, we followed the steps described in [Migrating From ASP.NET MVC to ASP.NET Core MVC][aspnet-migration]. +The first option, porting to ASP.NET Core, allowed us to take advantage of the latest features in ASP.NET Core. To do the conversion, we followed the steps described in [Migrating From ASP.NET MVC to ASP.NET Core MVC][aspnet-migration]. > [!NOTE] > When using ASP.NET Core with Kestrel, you should place a reverse proxy in front of Kestrel to handle traffic from the Internet, for security reasons. For more information, see [Kestrel web server implementation in ASP.NET Core][kestrel]. The section [Deploying the application](#deploying-the-application) describes a recommended Azure deployment.