Refine onboarding and deployment best practices

Updated descriptions and clarified best practices for onboarding and deploying network functions with Azure Operator Service Manager.

Author: msftadam

articles/operator-service-manager/best-practices-onboard-deploy.md

@@ -1,6 +1,6 @@
 ---
 title: Basic Concepts for Azure Operator Service Manager
-description: Understand Azure Operator Service Manager basic concepts to onboard and deploy a network function.
+description: Understand Azure Operator Service Manager basic concepts behind onboarding and deploying a network function.
 author: msftadam
 ms.author: adamdor
 ms.date: 10/06/2025
@@ -9,7 +9,7 @@ ms.service: azure-operator-service-manager
 ---
 
 # Basic concepts for Azure Operator Service Manager
-Microsoft has developed many proven best practices for managing network functions (NFs) using Azure Operator Service Manager. This article provides basic guidelines that NF vendors, telco operators, and their partners can follow to optimize NF deployments. Consider these concepts when beginning the onboard and deployment planning process.
+This article captures best practice recommendations to onboard and deploy network functions (NFs) with Azure Operator Service Manager. Following these basic guidelines, vendors, operators, and their partners can optimize network services deployed to Azure Operator Nexus. Consider these concepts at the beginning of any network function onboarding planning process.
 
 ## General considerations
 We recommend that you first onboard and deploy your simplest NFs (one or two charts) by using the quickstarts to familiarize yourself with the overall flow. You can add necessary configuration details in subsequent iterations. As you go through the quickstarts, consider the following points:
@@ -23,9 +23,9 @@ We recommend that you first onboard and deploy your simplest NFs (one or two cha
 ## Publisher considerations
 - We recommend that you create a single publisher per NF supplier, or per NF type per NF supplier, where the NF supplier may provide more than one NF type. This practice;
   - Provides for the most optimal support, maintenance, and governance experience, by preventing proliferation of publishers. Especially during upgrade activities where the same action is often executed across many NFs. 
-  - Lowers total operating costs by reducing the number of publisher backing resources, like ACR or Storage Accounts.
+  - Lowers total operating costs by reducing the number of publisher backing resources, like Azure Container Registry (ACR) or Storage Accounts.
   - Simplifies the network service design (NSD), where it may consist of multiple NFs from multiple vendors.
-- After you test and approve the desired set of Azure Operator Service Manager publisher resources for production use, we recommend marking the entire set as immutable. Marking the set as immutable helps prevent accidental changes and ensure a consistent deployment experience. Consider relying on immutability capabilities to distinguish between:
+- After you test and approve the desired set of Azure Operator Service Manager publisher resources for production use, we recommend marking the entire set as immutable. Marking the set as immutable helps prevent accidental changes and ensures a consistent deployment experience. Immutability markings help distinguish between:
   - Resources and artifacts used in production
   - Resources and artifacts used for testing and development
 
@@ -49,7 +49,7 @@ The network function definition group (NFDG) represents the smallest component t
 * For CNF NFDVs, the `networkFunctionApplications` list can contain only Helm packages.
   * It's reasonable to include multiple Helm packages if they're always deployed and deleted together.
 * For VNF NFDVs, the `networkFunctionApplications` list must contain at least one `VhdImageFile` value and one ARM template.
-  * To deploy multiple VMs for a single VNF, make sure to use a separate ARM template for each VM.
+  * To deploy multiple virtual machines (VMs) for a single VNF, make sure to use a separate ARM template for each VM.
 
 The ARM template can deploy only Resource Manager resources from the following resource providers:
 - `Microsoft.Compute`
@@ -63,14 +63,14 @@ The ARM template can deploy only Resource Manager resources from the following r
 For ARM templates that contain anything beyond the preceding list, all `PUT` calls on the VNF result in a validation error.
 
 ### NFDV minor or major updates
-The NFDV represents a release of the base NFDG and and is associated to a unique version. As the NF changes overtime, many NFDVs are use to capture capabilities, at any given point in time. Typical changes that trigger a new NFDV may include: 
+The NFDV represents a release of the base NFDG and is associated to a unique version. As the NF changes overtime, many NFDVs are use to capture capabilities, at any given point in time. Typical changes that trigger a new NFDV may include: 
 - Updating NF artifacts, such as new charts or image versions.
 - Updating CGSs or configuration group values (CGVs) that change `deployParametersMappingRuleProfile`.
 - Updating any default values hard-coded into the NFDV.
 - Updating component enablement, to prevent them from being deployed via `applicationEnablement: Disabled`.
 
 > [!NOTE]
-> A minor or major NF release which doesn't expose new CGS parameters requires only updating the artifact manifest, pushing new images and charts, and bumping the NFDV.
+> A NF release which doesn't expose new CGS parameters requires only updating the artifact manifest, pushing new images and charts, and bumping the NFDV.
 
 ## NSDG and NSDV considerations
 A network service design group (NSDG) is a composite of one or more NFDGs and any infrastructure components deployed at the same time. These components might include clusters and VMs in Nexus Kubernetes or Azure Kubernetes Service (AKS). A site network service (SNS) refers to a single NSDV. Such a design provides a consistent and repeatable deployment of the network service to a site from a single SNS `PUT` call.
@@ -85,13 +85,13 @@ An example NSDG might consist of:
 These five components form a single NSDG. A single NSDG can have multiple NSDVs.
 
 ### NSDV minor or major update
-The NSDV represents a release of the base NSD and and is associated to a unique version. NSDV changes are less frequent then NFDV changes, and in some cases, a single NSDV supports the entire lifecycle of a site network service. However, the following service changes do require new a NSDV: 
-- Creating, deleting or adding values in CGSs.
+The NSDV represents a release of the base NSD and is associated to a unique version. NSDV changes are less frequent than NFDV changes, and in some cases, a single NSDV supports the entire lifecycle of a site network service. However, the following service changes do require new a NSDV: 
+- Creating, deleting, or adding values in CGSs.
 - Changing the NF ARM template used by a deployed site network service resource.
 - Changing the infrastructure ARM template used by a deploy site resource.
 
 > [!NOTE]
-> It's recommened to expose the NFDV as a parameter within the CGS, so operators can control what to deploy by using CGVs. This further reduces NSDV change frequency.
+> Expose the NFDV as a parameter within the CGS, so operators can control what to deploy using CGVs, further reducing NSDV change frequency.
 
 ## SNS considerations
 We recommend that you have a single SNS for the entire site, including the infrastructure. The SNS should deploy any required infrastructure (for example, clusters and VMs in Nexus Kubernetes or AKS), and then deploy the required NFs on top. Such a design provides a consistent and repeatable deployment of the network service to a site from a single SNS `PUT` call.
@@ -103,7 +103,7 @@ The following two scenarios illustrate Azure Operator Service Manager resource m
 
 ### Scenario: Single network function
 An NF with one or two application components is deployed to a Nexus Kubernetes cluster. Here's the breakdown of resources:
-- **NFDG**: If components can be used independently, two NFDGs (one per component). If components are always deployed together, then a single NFDG.
+- **NFDG**: If components can be used independently, two NFDGs with one per component. If components are always deployed together, then a single NFDG.
 - **NFDV**: As needed based on use cases that trigger NFDV minor or major version updates.
 - **NSDG**: Single. Combines the NFs and the Kubernetes cluster definitions.
 - **NSDV**: As needed based on the use cases that trigger NSDV minor or major version updates.
@@ -120,7 +120,7 @@ Multiple NFs with some shared and independent components are deployed to a Nexus
 - **NSDG**: Single. Combines all NFs, shared and independent components, and infrastructure (Kubernetes cluster or any supporting VMs).
 - **NSDV**: As needed based on the use cases that trigger NSDV minor or major version updates.
 - **CGS**:
-  - Single. Global for all components that have shared configuration values.
+  - Single. Global for all components.
   - Single per NF, including the version of the NFD.
   - Depending on the total number of parameters, consider combining all the CGSs into a single CGS.
 - **CGV**: Equal to the number of CGSs.
@@ -201,4 +201,4 @@ As the first step toward cleaning up an onboarded environment, delete publisher
 > [!IMPORTANT]
 > Be sure to delete the SNS before you delete the NFDV.
 
-Azure Operator Service Manager does not delete namespaces as part of any deletion operation. As such, after all resources are deleted, some artifacts might remain on the cluster. To remove any remaining artifacts, you should delete any workload namespaces created on the cluster. Including the namespace deletion operation as part of the workflow pipeline is a recommendation to automate the action.
+Azure Operator Service Manager doesn't delete namespaces as part of any deletion operation. As such, after all resources are deleted, some artifacts might remain on the cluster. To remove any remaining artifacts, you should delete any workload namespaces created on the cluster. Including the namespace deletion operation as part of the workflow pipeline is a recommendation to automate the action.