Provider-cloud virtualized architecture and orchestration
Identify the virtualized service and its responsibilities
Service-provider cloud infrastructure supplies relevant compute, storage, networking and lifecycle capabilities for its intended services. A virtual network function is a software realization of a network role under its supported environment; it is not simply a physical switch with a different name. Virtual machines and containers provide different execution and isolation arrangements, and orchestration coordinates their deployment and lifecycle. A cloud service model determines which layers are managed by provider and customer, while deployment labels describe ownership and access context. Neither label alone proves isolation, resilience or complete automation.
Separate the NFV management roles
In the conceptual ETSI NFV framework, infrastructure resources and their management have roles distinct from individual function lifecycle and network-service orchestration. A VIM manages relevant virtualized infrastructure resources, a VNFM addresses relevant VNF lifecycle, and an NFVO coordinates network-service/resource orchestration under the architecture. Implementations and functional splits require their exact supported model. A successful instantiation response is not proof that a service chain has correct connectivity, capacity, identity or health.
Use models and APIs deliberately
Cisco NSO provides model-driven orchestration roles under supported device models and workflows. YANG describes relevant structured data models; NETCONF and RESTCONF provide their respective configuration/state interfaces. REST APIs, gRPC and gNMI have different roles and encodings rather than being interchangeable names for JSON. Validate actual schema, permissions, target and operation state before a proposed change. Accepted asynchronous work needs completion and service verification, and retries must respect supported idempotence/concurrency behavior.
Design the execution and trust boundaries
Network segmentation, virtual switches, placement, storage and cloud identity affect the resulting service. VLAN scale and overlay design need the actual scope and underlay assumptions. OpenStack and other supported platforms divide infrastructure control into particular services whose roles must not be replaced with Nexus-only configuration vocabulary. Protect management endpoints and secrets, inventory the intended versions and confirm observability and recovery. These are written provider-cloud concepts, not a complete official practical lab. No VNF, virtual machine, container, API operation or production infrastructure is created, scaled or removed by completing the exercise.